04 | 如何利用事务消息实现分布式事务？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
消息队列的事务功能在分布式系统中的实现方式是如何的呢？本文通过介绍了分布式事务的概念和消息队列在实现分布式事务中的作用，以及RocketMQ中的分布式事务实现机制。在分布式系统中，数据一致性的保障是非常困难的，因此出现了各种不完整的一致性解决方案。消息队列的事务功能主要解决消息生产者和消费者数据一致性的问题，适用于需要异步更新数据且对数据实时性要求不高的场景。在RocketMQ中，实现了事务反查机制来解决事务消息提交失败的问题，通过定期反查本地事务状态，确保事务的完整性。整体来看，消息队列的事务功能为分布式系统提供了一种相对简单且可靠的分布式事务解决方案。 通过一个订单购物车的例子，我们学习了事务的ACID四个特性，以及如何使用消息队列来实现分布式事务。现有的几种分布式事务的解决方案都不能解决分布式系统中的所有问题，每一种方案都有局限性和特定的适用场景。最后，我们一起学习了RocketMQ的事务反查机制，这种机制通过定期反查事务状态，来补偿提交事务消息可能出现的通信失败。在Kafka的事务功能中，并没有类似的反查机制，需要用户自行去解决这个问题。但是，这不代表RocketMQ的事务功能比Kafka更好，只能说在我们这个例子的场景下，更适合使用RocketMQ。Kafka对于事务的定义、实现和适用场景，和RocketMQ有比较大的差异。 总的来说，本文通过介绍消息队列的事务功能在分布式系统中的实现方式，以及RocketMQ中的分布式事务实现机制，为读者提供了对分布式事务解决方案的全面了解。同时，通过具体案例和比较分析，帮助读者更好地理解了不同分布式事务解决方案的特点和适用场景。
《消息队列高手课》，新⼈⾸单¥59
全部留言(185)
- 最新
- 精选
奕对于上面订单的例子，为什么不等待订单创建成功再向消息队列发送订单数据呢？这样串行的话，对性能影响应该也不大，也不用考虑订单创建失败而发送消息的情况了。作者回复: 考虑这样一种情况：订单创建成功了，还没来得及发消息，这个节点突然断电了。
2019-07-3044208
微微一笑老师您好，下面是我对思考题的一些看法： A:本地事物的操作1，与往消息队列中生产消息的操作2，是两个分离的操作，不符合对原子性的定义； C:由于操作消息队列属于异步操作，在数据一致性上，只能保证数据的最终一致性。若对于时效性要求很高的系统来说，事物消息不是数据一致的；但对于时效性要求不高的系统来说，他就是数据一致的。我认为，用不同的业务视角来看问题，会有不同的答案； I：隔离性上，由于事物消息是分两步操作的，本地事物提交后，别的事物消息就已经可以看到提交的消息了。所以，不符合隔离性的定义； D：持久性上，rocketMq上支持事物的反查机制，但我不太清楚“半消息”是存储在磁盘中，还是内存里。若存储在磁盘中，那就支持持久性，即使事物消息提交后，发生服务突然宕机也不受影响；若存储在内存中，则无法保证持久性。 以上是我的理解，望老师指点~作者回复: 这个总结非常到位，给你点赞！
2019-07-3011140
ly实现订单下单场景： 1. 首先通过producer.sendMessageInTransaction()方法发送一个半消息给MQ. 2. 此时会在TransactionListener中的executeLocalTransaction()方法阻塞，然后在这个方法里面进行订单创建并提交本地事务，如果commit成功，则返回COMMIT状态，否则是ROLLBACK状态，如果正常返回COMMIT或者ROLLBACK的话，不会存在第3步的反查情况。 3. 如果上面的本地事务提交成功以后，此节点突然断电，那么checkLocalTransaction()反查方法就会在某个时候被MQ调用，此方法会根据消息中的订单号去数据库确认订单是否存在，存在就返回COMMIT状态，否则是ROLLBACK状态。 4. 购物车在另外一个项目中，反正只要收到MQ的消息就将本次订单的商品从购物车中删除即可。 以上是通过代码的进行步骤写的，老师看有没有什么问题。作者回复: 非常好，完全正确！
2019-07-301380
Calix这个半消息，和生活中的“交定金”有点类似。作者回复: 其实是交全款，不发货。
2019-08-06449
君莫笑老师，我回头重新看的时候看到这一章有一点疑问，消息队列的手动确认模式是可以保证分布式事务的最终一致性，那么如果生产者在处理完自己的业务之后将消息放入消息队列中（通过生产者确认方式可以确保消息送达Broker），然后消费者消费这个消息的时候出了问题，假设是消息体本身的原因导致消费该消息一定会抛出异常，这种情况下怎么通知生产者回滚该消息所处理的业务数据呢？作者回复: 这种情况下是没有办法回滚的，也不应该回滚。 因为对于消息队列来说，它的一个重要功能就是解耦。 消费者的任何行为，不应该影响生产者。 对于你说的“坏消息”，反复消费都不能成功，有的MQ会把这种消息放到一个单独的特殊队列中，等着后续人工处理，避免卡死队列。
2019-08-26937
oscarwin先开启本地事务，然后创建订单，订单创建成功后再发消息，根据发消息是否成功来决定提交还是回滚本地事务。这样不需要事务消息也能解决这个场景的问题了？还是说我考虑的不够全面。作者回复: 如果本地事务提交失败，已经发出去的消息是无法撤回的，会导致数据不一致。
2019-07-311635
Geek老师，有几个问题没有太理解，可以解答一下么？ 1.kafka在commit/rollback的时候如果发送失败了就会抛出异常，会不会存在已经发送成功了但是超时了的情况呢，这个时候broker已经收到数据了。但是上游业务却回滚了 2.RocketMq反查时有没有可能本地事务还没提交呢，导致broker取消了事务造成了不一致 3.RocketMq在反查时如果订单服务异常了，导致broker取消了会不会导致事务造成了不一致 谢谢老师作者回复: 第一个问题，我们后面还有专门的一节课来讲事务是如何实现的，这里面会有你想要的答案。 第二第三个问题，RocketMQ给出的解决方案是，反查的结果返回的状态中，不仅有成功和失败，还有一个“不确定”的状态，意思就是“我现在不知道本地事务是不是成功了，将来它可能会成功，也可能会失败”，像你提的这两种情况，在实现反查接口的时候，都应该返回不确定的状态，RocketMQ在收到这个状态后，会定时多次进行反查，直到得到成功、失败的状态或者事务超时才结束。
2019-08-21232
linqw使用rocketmq实现分布式事务的理解和疑问，老师有空帮忙解答下哦 1、rocketmq实现分布式事务，使用的是两阶段提交，和mysql写redo log和binlog日志的两阶段提交类似，以上面订单的为例，提交订单消息到mq中，等待mq回复ack，消息提交成功，但是此时的消息对消费组不可见，即half消息，此阶段像mysql的引擎层写redo log的prepare阶段，执行本地事务，执行本地事务成功，此阶段像mysql的service层写binlog的阶段，写binlog成功，最后提交或者回滚队列事务，rocketmq为了防止commit和rollback超时或者失败，采取回查的补偿机制，回查次数默认15次（感觉这个会不会导致服务超时了），超过会rollback，有点像mysql宕机重启根据redo log中的xid找binlog的xid事务，如果binlog日志也已经写成功，mysql这个事务也会提交，因为redo log和binlog这个事务都写完整。 2、消息对消费者不可见，将其消息的主题topic和队列id修改为half topic，原先的主题和队列id也做为消息的属性，如果事务提交或者回滚会将其消息的队列改为原先的队列。rocketMq开启任务，从half topic中获取消息，调用其中的生产者的监听进行回查是否提交回滚。 3、rocketmq采用commitlog存放消息，消费者使用consumeQueue二级索引从commitlog获取消息实体内容，不太理解Index File：索引文件？回查借助OP topic进行获取到Half消息进行后续的回查操作，感觉整体流程还是没有串通，老师能否帮忙解答下么？作者回复: indexFile的作用就是给commitlog做的索引，提升读取消息时的查询效率。 另外，关于事务的实现流程，总结的很到位，你还有哪些具体的问题不清楚，可以继续留言提出来。
2019-07-30928
Yize Li看了之前的一个留言 认为本地数据库和消息系统是两个系统所以违反了原子性 我是有些疑惑的。 我认为 原子性破坏与否取决于是否存在数据库中订单成功但是在购物车中商品没有取消的情况 通过rocketmq的半消息模式是可以保证该情况不出现。所以原子性没有破坏 但是由于消息系统的异步性 导致我们可以观察到事物执行过程中或回滚中的中间状态 这意味着强一致性被破坏 只剩下了最终一致性作者回复: 是这样的。
2019-09-22527
yan如果订单ID是要创建完订单才会有的，那消息中就没有订单ID，那反查本地事务要根据什么查？作者回复: 所以几乎所有的类似系统都会事先生成订单ID，而不是在插入数据库的时候才生成。
2019-09-26319
