2020年2月10日
消息队列基础
为什么用消息队列
随着业务的复杂，需要不同的工能共同完成一个事情，比如下单，有日志，优惠券，积分等的步骤。
需要使用异步，解耦的方式实现，于是有了消息队列
异步，很好理解，下单成功，只要发送消息即可，不同的事情，不同系统来处理。后面会引入分布式事务。
解耦，也可以用多线程，但是程序的耦合程度上升，维护不容易。
当然，使用消息队列，必要引入其他问题。数据的一致性，消息的丢失，重复消费，顺序消费等。
重复消费的例子
下游业务系统，如增加销售总额的接口，调用失败，要求重新发送消息。重发之后，其他业务系统，比如加积分可能会出现重复增加。
此时要做好幂等
强校验的例子：
比如，加销售总额的操作和写流水放到一个事务中，根据订单号和业务标示查询流水，查到了的话，直接返回。没有查到的话，写流水、增加销售总额。
流水表方便对账，方便定位问题。
弱校验的话：
比如使用redis，做个唯一标示放到redis，处理成功了，去掉缓存，下次消息再来，有缓存的处理下，没有缓存的场景就是处理过了。
或者用token等校验，消息带上token，同一个消息要保证token一样，处理前先检查这个请求是否处理了。
顺序消费的问题，一般由消息队列的FIFO机制来保证。后续探讨。
分布式事务
2pc
引入一个中间件，分布式系统上的两个操作，都准备好之后，通知中间件，然后再提交。提交过程无法保证都成功。
最终一致性
允许中间状态，下单之后，显示在已发送下单请求，但是还没真正下单，最终看下单结果，成功了之后会修改状态为下单成功，触发其他操作。这里是个人理解，不严谨，后面在学习分析一下。