分布式事务分享一点相关经验

在传统的单体应用（包含单体应用的多份部署，比如使用反向代理等方式），业务code集中在一起，可以轻松保证事务的ACID；然而到了现在的微服务时代或者服务网格时代，单体应用被按照业务进行水平拆分，以前在一个事务内的业务代码被分散到了多个进程之中，随之带来了令人烦恼的分布式事务问题，如何保证进程之间事务完整性成为了微服务带来的难题，此篇将分享之前对分布式事务的研究，包含对几个业界知名框架的研究。

知名的CAP理论

file

CAP理论：指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP理论的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

基于CAP理论，分布式事务必须在AP和CP模式之间进行选择，而A（可靠性）对于在线业务来说又是不可或缺的，所以最后对于分布式事务的处理则演变为现在的AP加数据最终一致性方案。

最终一致性

异于事务的强一致性，强调的是结果，能够在较短的时间内完成数据的一致性，并不适用于对数据要求强一致性的场景，比如部分金融场景；实现最终一致性的方式也有很多，比如两段式提交，TCC（try confirm cancel），最大努力通知等。

开源实现

file

• 其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。

• 资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软件都可以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。

• 事务管理器(Transaction Manager ，简称TM)：负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。

开源实现大部分都是2PC（两段式提交），方案提供一个高可用的TM，并提供对应的Client（相当于RM），利用注解切面的方式和远程调用是传递事务唯一标识，通过TM的协调进行监控，事务的提交回滚等。

• TX-LCN：本人使用过的分布式开源解决方案，现最新版本为5.0.2，但是基本已经停止更新，bug不少，LCN模式的实现原理则是代理数据库连接connection，代理commit方法与TM进行通讯，TM进行协调；本人使用的4.1.0版本依赖Redis，新版本尝试过，因为bug过多放弃，避可能指南：如果你使用的是spring cloud且使用了hystrix，注意不要使用线程池隔离模式。

• SEATA：现阶段最火的开源实现方案，阿里背书，借助与Spring Cloud Alibaba社区非常活跃，如果你真的无法躲过分布式事务的雷，可以尝试。其原理也是代理连接，在业务数据库中侵入一张表，来保存数据改变前或者后的image，回滚则使用侵入表的数据进行恢复，存在部分select for update操作，所以你使用时候可以需要关注性能下降，锁表等情况；当然它同时也支持SAGA模式等。

• RocketMQ：如果场景不是很多且不复杂，个人建议使用RocketMQ进行自己实现，利用RocketMQ的半消息完成事务的最终一致性。（由于最近也在使用RocketMQ，也发现了一些bug（比如Docker部署应用的时候client name会出现全部一样的情况，导致负载均衡失败），阿里的开源有点让本人担心）

最后，对于分布式事务的问题，个人强烈建议能避开还是避开，不论使用那种方式都存在需要人工介入处理的情况，正所谓天下无难事，只要肯放弃！哈哈哈！

本文由博客群发一文多发等运营工具平台 OpenWrite 发布