TX-LCN分布式事务框架应用与解析-1实际生产事故

公司最近正在做微服务拆分，有一个需求是这样的，要单独开发一个服务，所有公司用到的用户部分，都由其负责创建、修改；比如原来有A,B两个系统，每个系统都有用户注册与修改，现在要新开发一个系统C，把A,B两个系统的用户注册与修改内容都单独出来放到C中，C有用户表，C也可以登录。但是A,B两个系统的用户表还是存在的，只是创建与修改都由C系统去调用A，B的接口，以到达数据的同步。这其中涉及到分布式事务的问题，即调用接口修改库和本地修改库要在同一个事务中。就比如我们项目中的流程，先是A系统去是本地修改库，然后调用B系统去同步数据，最后把操作日志调用日志服务存起来。最后日志服务调用失败，本地回滚但是B系统已经改了。造成数据不一致的问题。

呵呵哒，上面的问题确实在生产产生了，用户也投诉了。开始开发的时候我就考虑到这些但是和领导谈了以后，领导说没关系，直接干就好，最后就这样了。

接下来我说下我当初提出的建议：

1、上面这种接口调用肯定要加事物，要不然一旦服务、网络出问题就会有数据不一致的问题。

2、当时参与的系统是两个，考虑到以后可能存在更多的系统参与到用户环节，建议用MQ去做，这样参与系统直接在MQ中取数据就行，新系统不用改造，而且MQ也可以做一致性。

出问题后，按照第一条建议改，第二条因为要引入新的中间件，暂时不考虑。

本着对代码改动小，与本身系统业务的问题，选择了TX-LCN分布式事务框架。

TX-LCN最新版本支持三种类型的事物，

1、LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。

特点：

• 该模式对代码的嵌入性为低。
• 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。
• 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。
• 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。

2、TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。

特点：

• 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。
• 该模式对有无本地事务控制都可以支持使用面广。
• 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高

3、 TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据，然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库，目前锁实现依赖redis分布式锁控制。

特点：

• 该模式同样对代码的嵌入性低。
• 该模式仅限于对支持SQL方式的模块支持。
• 该模式由于每次执行SQL之前需要先查询影响数据，因此相比LCN模式消耗资源与时间要多。
• 该模式不会占用数据库的连接资源。

上面是官网的表述，我们选择了LCN模式

原因：

1、我们本地都有连接对象，因为都是操作数据库。

2、对原有代码改变不大

3、修改和创建密码本来就很少操作，即使占用连接也不会太多。对性能影响比较小

如果想看例子请参照https://www.txlcn.org