本地消息表模式保障分布式最终一致性

1.先看问题

这里使用订单系统和库存系统协同作业，就要涉及到数据的一致性了。

作为订单系统肯定是要创建订单，作为库存系统，肯定是要在库存表中进行库存的扣减，以及在出库记录表中进行出库记录的登记。在这个过程中，因为中间跨进程和跨数据，所以数据一致性是无法直接保障的。那我们该怎么办呢？

这时由eaby提出的 本地消息表模式 就派上用场了

所谓本地消息表，最核心的一个变化，就是在我们生产者，也就是发送方创建一个消息表。这个消息表登记了要向库存系统发送的消息，以及消息的内容和相关的数据状态。

1、原有的订单系统要在数据库中增加消息表，消息表有5个字段，功能如下：

2、订单系统再往订单表创建数据的时候，也会往消息表创建消息数据，这时候订单表和消息表都有了各自的数据

3、在订单系统中，需要额外的增加一个定时任务，比如每一分钟定时任务执行一次，他自动的会去扫描消息状态为正在处理的消息，这个时候就会把消息编号为3的数据提取出来。

4、增加一个消息队列，将编号为3的消息内容通过MQ进行消息的传递，作为MQ的Broker他有两个消息队列：

这个时候会将编号3的消息传递到处理队列

5、与之对应的这个库存系统订阅了MQ的处理队列，通过MQ获取到了订单系统发送过来的完整数据，然后在自己的数据库中进行对应业务操作

6、库存系统完成自己的业务逻辑后，向MQ的返回队列发送一个消息，通知订单系统，已经处理完成对应的订单。

7、订单系统接收到MQ return队列的数据后，将消息内容中对应的消息编号提取出来，更新为处理完毕。

这时候我们整个业务流程就处理完了，数据也保证了最终的一致性。

总结业务调整需要三个点：

1、业务系统数据库增加消息表，存储业务状态

2、业务增加定时任务，定期扫描消息表，获取等待处理的业务数据，具体时间间隔，根据业务需求来定

3、增加一个MQ，通过MQ进行高可靠的数据传输，并对发送和返回分别设计队列，通过MQ的一去一会来表示处理的状态。

本地消息表模式下，不同的业务处理流程以及分支都会有不同的注意事项，我们来看下图

核心思想：将分布式事务拆分成本地事务进行处理，不同事务之间通过消息表和MQ通信。

优点：相对很好的解决了分布式事务问题，实现了最终一致性。

缺点：消息表耦合到业务系统中。