事务、分布式事务、Base、CAP不赘述。
业内场景的分布式事务解决方案有，
2PC、3PC
TCC(alipay)
增加状态信息，由定时任务去补（这种业务规模上来了太复杂，且不优雅，未做深入研究）
基于消息(下面二者的区别：如何保证主事务的提交与消息发送这两个操作的原子性)
本地消息表(ebay)
事务消息
适用场景：
基于消息的分布式事务，适用于 “业务弱耦合” 的业务，例如交易明细消息等；它更适用于参与者的提交失败只可能是由于故障，而不可能是逻辑错误，因为这种模式下事务回滚会非常不便；其可用性非常高。
TCC 更适用于 “业务强耦合” 的业务，例如借呗放款时，占额度、打款、更新单据这种；TCC 在保证一致性的同时，最大限度提高系统的可伸缩性与可用性。
xts 两个值得注意的问题：
一、xts 一阶段成功，发起者就认为成功了，然后 xts 框架去负责推进二阶段。但是翻了 xts 源码，没看到里面有配置定时任务。
xts 框架会负责推进二阶段，如果框架推进失败，会有定时任务继续推进。定时任务在 xts 的 server 端（业务上的 xts 只是它的 client 端）。
二、如果 xts 二阶段的 commit 或者 rollback 失败了怎么办？
失败了，就靠恢复任务继续去调用，不断重试，保证一定要成功。
总结：
分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。
不控制就是不引入分布式事务；部分控制就是各种变种的两阶段提交，包括上面提到的消息事务、TCC模式；完全控制就是完全实现两阶段提交。
部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了；完全控制则是牺牲了性能，保障了更强的一致性。
具体用哪种方式，最终还是取决于业务场景。
自我的脑洞大开，不知是否可行。
是否可以利用 MVCC 实现分布式事务。
基于 MVCC的 分布式方法为：
为每个事务分配一个递增的事务编号，这个编号表示数据的版本号；
当事务在各个节点上面执行的时候，各个节点只需要记录更新操作及事务编号，当事务在各个节点完成的时候，在全局元信息中记录本次事务的编号；
在读取数据时，先读取元信息中已经成功的最大事务编号，再于各个节点上读取数据，只读更新操作编号小于等于最后最大已成功提交事务编号的操作，并将这些操作应用到基础数据形成读取结果。
此想法先记录，还没想好。
网友评论