14 | 分布式事务之可靠消息队列
CAP 与 ACID 之间的矛盾
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
分布式事务的复杂性和挑战是当前分布式计算领域的热点问题。CAP理论和ACID原则的矛盾为分布式事务带来了挑战，强调了在分布式服务环境下事务处理机制的重要性。文章通过具体案例分析了放弃分区容错性、可用性和一致性分别会带来的问题，以及在实际应用中如何权衡取舍CAP。此外，还介绍了弱一致性和最终一致性的概念，以及柔性事务的实现方式之一——可靠消息队列。这些内容为读者提供了对分布式事务挑战和解决方案的深入了解。文章通过具体案例和技术概念的讲解，使读者能够更好地理解分布式事务的复杂性和挑战，以及在实际应用中的应对策略。文章还介绍了可靠事件队列的实现方式，通过对具体操作时序的解读，展示了如何通过持续重试来保证可靠性，同时指出了这种方式可能带来的代价。最后，鼓励读者思考XA事务在分布式环境中少应用的原因以及可靠事件队列的实现方式可能带来的代价，为读者提供了进一步思考和探讨的空间。
请先领取课程
全部留言(28)
- 最新
- 精选
蓝蓝用为什么 XA 事务很少在分布式环境下直接应用，会有什么代价？而这节课介绍的“可靠事件队列”的事务实现方式又会有什么代价？ 请老师指教，如果有错误请帮忙指正，谢谢 xa事务是全局事务，表示一个服务多个数据源，追求强一致性，复杂度高，吞吐量低。 可靠事件队列，代价是无法实时的一致性，即强一致性，而是实现了最终一致性，如果因为异常，而延迟了一致性的实现，可能会导致事物的隔离无法实现作者回复: 对的
2021-01-0425
Jxin
1.性能和一致性问题。普适性这个倒不是问题，毕竟考虑db切换大部分时候都是一种过度设计。 2.增加了复杂性（引入中间件，要考虑幂等）。失去强一致性（个别场景不适用）。 3.对于分布式事务，在真实工作中，有一个很恶心的现象。在业务逻辑中完全不考虑事务，然后通过外挂或对账系统来调整数据保最终一致。我个人比较讨厌这种做法，因为它让业务逻辑变得残缺（缺失一致性的语意），让功能分散（外挂系统逻辑代码找不到，找到了有时都不是一种语言）。 4.大佬后面完了可以加餐谈谈cdc和流程编排不。这两个我觉得跟分布式事务也是相关性很强的。作者回复: 关于问题3，在企业系统中很常见，譬如对账、冲销。这类功能在需求角度很可能是合理的，应该有相应的业务架构去满足，因为系统中的错误不仅仅来源于技术失误，由业务失误导致的错误同样是不可忽视的。 “感到讨厌”一般是源于采用业务架构层面的手段去处理技术架构层面的问题，说白了就是不去正视问题产生的真正根源，而是想些法子去补救，将就着用，这点就不太符合程序员的天生洁癖。 关于流程编排，以前SOA盛行的时候，我曾经做过挺长一段时间的BPMN，协同与编排在微服务时代中不会消失，但无可否认，近年来软件业界的主要关注点不在这个方向，这部文档中并没有涉及。
2020-12-18315- tjxcoding把枯燥乏味的知识讲的如此津津有味
作者回复: 感谢认可。
2020-12-183 - bigben以前的知识都是零散的，不知道这些知识点的联系，周老师的串讲，真是醍醐灌顶
作者回复: 感谢认可
2020-12-192 - Helios目前觉得消息队列挺好的，真的说不出什么缺点。 这个课为啥免费～
作者回复: 课程免费是因为本来就来源于我写的一部开源文档。
2021-02-02 
尹恒老师的课真的很好，不仅条理清晰，而且娓娓道来，很多概念，在老师这里才算真正理解透彻作者回复: 感谢认可
2021-01-14- 努力呼吸请问周老师，当采用本地消息表处理分布式事务时。是否需要消费者确认消费完毕了再调用一个回调接口通知生产者，此时本地消息从处理中变为终态；还是说发送消息，broker返回SUCCESS即可将状态改为终态呢？
作者回复: 是要在消费者成功完成操作后再回调通知的。 MQ的ACK消息只能代表可以开始进行最大努力交付了，不能代表事务被成功完成了。如果发送消息后，Broker返回了SUCCESS，此时可以提交本地事务，如果不是SUCCESS，应该直接回滚掉本地事务才对。
2020-12-223 
zhanydCAP理论听起来很高大上，其实很简单。 一致性（Consistency）： 保证数据一定是一致的，对的 可用性（Availability）：保证系统能用 分区容错性（Partition Tolerance）：就算网络出了问题（分区），我也能忍 在分布式系统中，网络是肯定会出问题的，不可避免的，比如服务器挂了，程序挂了，网线被踢掉了，网络超时等等。 各个服务器原来通过网络连接，连成一片，在一个大的区域中，互相之间要同步数据，现在网络出了问题，各个服务器之间就断了联系，相互之间被隔离了，数据同步不了了，这就形成了分区。 出现了分区，我们也认了，这是网络错误，是无法避免的，所以分区容错性即P，在分布式系统中是一直存在的。 那在P存在的前提下，我们到底是选择保证：数据是对的比较重要呢（CP），还是保证系统能用比较重要呢（AP）？ CP：比如A服务器的数据是要同步给B服务器的，现在网断了，A的数据传不过去了，我觉得保证数据对比较重要，如果A和B的数据对不上，后果很严重，为了保证A和B服务器的数据一致，干脆让A停止服务好了，直接给客户端返回错误信息，等网络恢复了，再上线，免得A和B的数据不一致。 AP：比如A服务器的数据是要同步给B服务器的，现在网断了，A的数据传不过去了，我觉得暂时的数据不一致没什么大关系，系统能用最重要，那我就继续让A提供服务，等网络恢复了，再同步数据到B。 CAP的问题就是网络不通的情况下，我们优先保证数据一致，还是优先保证系统可用的问题。2020-12-19197
葱味黑咖啡老师的课每一节都能给我新的感悟，这样质量上乘的课还是免费的实在太良心了2020-12-28224- walle斌业务使用rocketmq 相比 kafka 更合适。。就在于 延迟消费 重试消费 并发消费 传统意义的分布式事物支持。。这些都是kafka无法原生支持的。。2021-11-029