本文共 1107 字，大约阅读时间需要 3 分钟。

目前采用的三种解决方案: 1、定期校队 2、TCC Try: 尝试执行业务 完成所有业务检查（一致性） 预留必须业务资源（准隔离性） Confirm: 确认执行业务 真正执行业务 不作任何业务检查 只使用Try阶段预留的业务资源 Confirm操作满足幂等性 Cancel: 取消执行业务 释放Try阶段预留的业务资源 Cancel操作满足幂等生 3、基于可靠消息 可靠消息 实现： 业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据 业务处理事务提交后、通过实时消息通知业务被动方，实时通知成功后删除消息数据 消息恢复系统定期找到未成功发送的消息，交给实时消息服务补发送 约束： 被动方的处理结果不影响主动方的处理 被动方的消息处理操作是幂等操作 成本： 可靠消息系统建设成本 消息数据CRUD成本 适用范围 对最终一致性时间敏感度较高 降低业务被动方实现成本 实现方式2： 业务处理在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送 业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息 业务处理在业务事务回滚后，向实时消息服务取消发送 消息状态确认系统定期找到未确认发送或回溯的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。 成本 一次消息发送需要两次请求 业务处理服务需实现消息状态回查接口 优点： 消息数据独立存储、独立伸缩 降低业务系统与消息系统间的耦合 CAP定理 对于共享数据系统，只能同时拥有以下三项中的两个： Consistency(一致性): 所有 用户看到一致的数据 Availability(可用性): 对数据更新具备高可用性 Tolerance to Network Partition(分区容忍性): 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择 分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力！

转载地址：https://blog.csdn.net/iteye_10343/article/details/82672967 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！