标签：事务 事物 SERVER MQ 消息 本地 一致性 分布式
分布式事务就是要保证不同节点之间的数据一致性。
常见的分布式事务解决方案
1、2PC(二阶段提交)方案 - 强一致性
2、3PC(三阶段提交)方案
3、TCC （Try-Confirm-Cancel）事务 - 最终一致性
4、Saga事务 - 最终一致性
5、本地消息表 - 最终一致性
6、MQ事务 - 最终一致性
《=====》
基于 MQ 实现的分布式事务
本地消息表-最终一致性
消息的生产方，除了维护自己的业务逻辑之外，同时需要维护一个消息表。这个消息表里面记录的就是需要同步到别的服务的信息，当然这个消息表，每个消息都有一个状态值，来标识这个消息有没有被成功处理。
1、消息的生产方也就是订单服务，完成了自己的逻辑(对商品进行下单操作)然后把这个消息通过 mq 发送到需要进行数据同步的其他服务中，也就是我们栗子中的购物车服务。
2、其他服务(购物车服务)会监听这个队列；
1、如果收到这个消息，并且数据同步执行成功了，当然这也是一个本地事务，就通过 mq 回复消息的生产方(订单服务)消息已经处理了，然后生产方就能标识本次事务已经结束。如果是一个业务上的错误,就回复消息的生产方，需要进行数据回滚了。
3、消息的生产方(订单服务)如果收到消息回执；
1、成功的话就修改本次消息已经处理完，也就是本次分布式事务的同步已经完成；
2、如果消息的结果是执行失败，同时在本地回滚本次事务，标识消息已经处理完成；
MQ事务-最终一致性
下面分析下几种消息队列对事务的支持
RocketMQ中如何处理事务
RocketMQ 中的事务，它解决的问题是，确保执行本地事务和发消息这两个操作，要么都成功，要么都失败。并且，RocketMQ 增加了一个事务反查的机制，来尽量提高事务执行的成功率和数据一致性。
常的事务提交
1、发送消息（half消息），这个 half 消息和普通消息的区别，在事务提交 之前，对于消费者来说，这个消息是不可见的。
2、MQ SERVER写入信息，并且返回响应的结果；
3、根据MQ SERVER响应的结果，决定是否执行本地事务,如果MQ SERVER写入信息成功执行本地事务，否则不执行；
4、根据本地事务执行的状态，决定是否对事务进行 Commit 或者 Rollback。MQ SERVER收到 Commit，之后就会投递该消息到下游的订阅服务，下游的订阅服务就能进行数据同步，如果是 Rollback 则该消息就会被丢失；
如果MQ SERVER没有收到 Commit 或者 Rollback 的消息，这种情况就需要进行补偿流程了
补偿流程
1、MQ SERVER如果没有收到来自消息发送方的 Commit 或者 Rollback 消息，就会向消息发送端也就是我们的服务器发起一次查询，查询当前消息的状态；
2、消息发送方收到对应的查询请求，查询事务的状态，然后把状态重新推送给MQ SERVER，MQ SERVER就能之后后续的流程了。
相比于本地消息表来处理分布式事务，MQ 事务是把原本应该在本地消息表中处理的逻辑放到了 MQ 中来完成。
Kafka中如何处理事务
Kafka 中的事务解决问题，确保在一个事务中发送的多条信息，要么都成功，要么都失败。也就是保证对多个分区写入操作的原子性。
通过配合 Kafka 的幂等机制来实现 Kafka 的 Exactly Once，满足了读取-处理-写入这种模式的应用程序。、
RabbitMQ中的事务
RabbitMQ 中事务解决的问题是确保生产者的消息到达MQ SERVER
生产阶段：生产者产生消息，通过网络发送到 Broker 端。
存储阶段：Broker 拿到消息，需要进行落盘，如果是集群版的 MQ 还需要同步数据到其他节点。
消费阶段：消费者在 Broker 端拉数据，通过网络传输到达消费者端。
标签：事务,事物,SERVER,MQ,消息,本地,一致性,分布式 来源： https://www.cnblogs.com/KL2016/p/16444694.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。