对于分布式事务，我“开门见山”讲了这些理解，面试官一头雾水。的。写后的读必须能读到之前写的内容，而且所有的读写请求好像都是全局排序的。A：任何非故障节点都应该在限定时间内响应请求。（请求的终止）P：允许任意数量的消息在节点之间丢失。当发生网络分区时，节点之间的消息可能会完全丢失。个人理解：对于C来说，就是保证某个时间点各个节点的状态是一致的，A代表从用户的角度来看各个节点是正常的，P代表从用户的角度各个节点连接正常节点。但是在分布式环境下，多实例部署是基本条件，因为网络不同。可靠性使P成为硬条件，所以分布式系统基本都是cp和ap的基础，基本可用（BasicallyAvailable），软状态（SoftState），最终一致（EventuallyConsistent）个人理解：基础理论基本实现是AP系统。分布式事务和业务有很强的耦合关系，因为基本上业务层面必须维护一个中间状态，这样事务才能有回滚的余地而不破坏数据。其次，因为有一个中间状态，所以在交易的过程中，基本上都是最终一致的。xa如图所示，基本分为以下三个角色。资源的修改不是直接通知资源管理器，而是提前准备好，然后由三方事务管理器修改。使用该协议的系统基本上是一个cp类型的系统2pc/3pc2pc：个人理解：在事务的prepare阶段执行完，提交事务的其余部分。只要一次执行出现问题，就会触发事务回滚。在commit阶段，可能会因为网络问题出现不一致的情况。各事务相互依赖成功，加锁资源时间过长（阻塞时间过长）事务协调器有超时重选，但各服务没有超时机制。3pc：个人理解：在2pc之上加了一层。个人理解这一层是辅助超时阶段，因为在preCommit阶段，事务只剩下待提交，其他服务也确认成功。最后每个服务都会启动一个超时计划，然后直接提交，而不是等待协调器docommit，而docommit就是提交一个命令，但是每个服务都可能有超时机制，因为网络接收不到。是为了弥补2pc中的长时间阻塞和服务端没有超时机制的不足。个人对tcc的理解：tcc的本质是base中的业务提供了一个中间状态，通过准备提交和回滚来完成整体的事务。添加了整体事务管理器以自动化管理事务的过程，例如停机后事务管理器会定期执行日志记录中事务的处理过程，以保证最终的一致性。一般分布式事务都会通过全局事务id来标识事务，解决幂等性。sega个人理解sega和2pc很像，但是sega的事务是自己提交的，对于中心化的问题，主业务会回滚或者重试，对于分布式但是递归的形式，回滚上面提到的问题。总的来说，我理解sega是最终一致的，但是它不存在base的中间状态，所以会出现隔离问题，容易出现幻读重复，读变化等各种问题。解决方案一般是Sega对应的框架提供一个全局的读写锁来提供隔离，对于sagas框架，实现一个事务协调器来简化事务的回滚和重试，并为sagas实现一套自生成的回滚SQL机制.sagas的设计还有很多。目前，我没有时间研究后续研究。相关sagasissues我会重写（sagas的历史，好像阿里收费项目gks是第一个，当时有人反汇编代码说实现可能是自动生成回滚代码的tcc，现在它了好像是saga加全局锁的模式)Sega2回滚方案backwardrecovery,backwardrecovery,compensationforallcompletedtransaction,ifanysub-transactionfailed,itisthemodeofsagaplusgloballock）其中发生了错误，这种做法的作用是撤销之前所有成功的子事务，从而撤销整个Saga的执行结果。前向恢复，前向恢复，重试失败的事务，假设每个子事务最终都会成功。适用于必须成功的场景，执行顺序类似这样：T1，T2，...，Tj（失败），Tj（重试），...，Tn，其中j是其中一个子事务发生了错误。这种情况下就不需要Ci中心化分布式消息交易/本地消息交易个人理解：对于消息交易，本质是保证消息能进入mq，同时也要保证消息不丢失不持久化，然后其他服务通过消息订阅完成业务对应，主要问题是保证幂等性和重复投递。本地消息事务的本质是将事务数据和本地事务持久化在一起，服务通过监控数据表来执行业务。当然我的也可以直接通知双方本质就是把事务持久化，然后有一个中间系统（宕机后继续事务）保证事务能够完成整个过程。有日志记录，然后定时主动通知外部系统（类似微信和支付宝支付回调）。当通知超时后，不会再有后续通知，但是外部系统会调用接口查询作者：kakj链接：https://juejin.im/post/5efd9d9df265da22c966f8ce来源：掘金
