概述

• 我们的业务场景是可以允许我们一段时间有不一致的消息的状态的，并没有说必须特别高的这个消息的一致性
• 比如说在TCC这个架构中，如果采用了消息的最终一致性，整体架构设计要轻松好多
• 即便我们库存服务挂了，或者我们积分服务挂了也没有关系，只要我们有中间的这个消息，那就是没有问题的
• 因为你在消息消费中，如果你你没有消费成功，那么消息就会一直存在在这个消息队列里

场景

• 看看这个我们的这个具体的案例的场景是什么样的？还是以这个订单服务和库存服务，还有积分服务为例
• 比如说，现在要下个订单，直接就在订单服务里，把它搞定了，我们就正常下订单
• 建立我们的订单表和我们的订单产品表，然后，这时候发送一条消息到这个消息队列里
• 那么我们说这个如果我们发送失败了，我们本地这个订单服务也能感知到，它就进行回滚就可以了
• 但是我们说突然的这个停电，这个我们就没办法感知到了
• 另一种情况，说你发送这个成功了，比如说我们建这个订单单服务，然后订单生成了订单产品表，也生成了, 消息发送也成功了
• 但是消息队列给我回消息的时候，由于网络的拥塞或者是抖动，这都很正常
• 然后，我们这个订单服务，肯定是要有超时机制的，它就超时了，订单就要回滚
• 但是这个这个消息队列是消息，可是真的到消息队列里存在了
• 那我下游的就库存，还有积分服务就拿着这个消息去做自己的业务了，该扣减库存就扣减库存，该增加积分就增加积分
• 但是，这个时候订单已经回滚了，那老板或者业务就会问了，这订单都没有了，你这个库存的积分增加是个什么意思
• 那我们要怎么解决这个问题呢？

• 那我们就是在我们这个订单服务增加订单的时候，我们不先去给他发这个消息
• 我们是先在本地表里头建立一个消息发送这个各种情况的一张表
• 比如说, 我这个订单服务，我建立了一条消息，但是这个消息没有返回来
• 有没有返回来也没有关系，这个表里已经记录了，说可以定一种状态，说就是未发送成功
• 我们这里这个本地消息表，就以发送成功的这个状态为准
• 只要是你能记录到这个表里的，没有发送成功的，我们就把它这个状态记录上
• 我们下次启动的时候，在这个订单服务里增加一个循环的这种定时任务
• 我们一般是做成异步的，因为你要是同步的话，相当于本地的这个数据库也是也有造成一定的压力的
• 我们就扫描这个之前没有发送成功的这个消息，那就是说直到我们这个定时任务，一直发送这个消息队列发送成功为止
• 所以他一定是能达到最终一致性的，我们这个里面就有一个问题，说你没发送成功，我记录一条可以没问题
• 那我下次一发送这个消息队列就成功了, 我回写消息本地这个表就记录了这条消息成功
• 如果，遇到我们的这个库存服务了，或者积分服务挂了都没有问题
• 因为你不消费消息队列里的这个消息，你就不会确认，你不会确认的这个消息就永远在消息队列里，这个就没有问题
• 但是还有一种情况，比如我这个消息，可能发很多次都有问题，可能是消息队列问题或者网络等问题
• 这样，重复发送就带来一个风险，比如下游如果重复消费怎么办？这个就是我们下游服务要解决的问题
• 本地消息的最终一致性，比TCC要简单很多，但是在某些高并发的场景，它也是有自己的问题的
• 如果一切正常，就发送，让消息队列让消费者去消费就可以了
• 如果有问题，就建立一张本地的这个消息发送表，记录各种情况，它最后能保证我们消息的最终一致性，但是要解决重复消费消息的这种情况