什么是分布式事务，以及有哪些解决方案？

TCC(Try-Confirm-Cancel)又称补偿事务。它实际上与2PC、3PC一样，都是分布式事务的一种实现方案而已。它分为三个操作：

• Try阶段：主要是对业务系统做检测及资源预留。
• Confirm阶段：确认执行业务操作。
• Cancel阶段：取消执行业务操作。

TCC事务的处理流程与2PC两阶段提交类似，不过2PC通常都是在DB层面，而TCC本质上就是应用层面的2PC，需要通过业务逻辑来实现。它的优势在于，可以让应用自己定义数据库操作的粒度，使得降低锁冲突、提交吞吐量。

不过对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。

TCC原理图如下：

4、消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是中间件的一种特殊利用，他是将本地事务和发消息放在一个分布式事务里，保证要么本地操作成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：

步骤如下：

1. 服务A向消息中间件发送一条预备消息。
2. 消息中间件保存预备消息并返回成功。
3. 服务A执行本地事务。
4. 服务A发送提交消息给消息中间件，服务B接收到消息之后执行本地事务。

基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务(服务A的本地操作+发消息)+服务B的本地操作，其中服务B的操作由消息驱动，只要消息事务成功，那么服务A一定成功，消息也一定发出来了，这时候服务B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到服务B操作成功，这样就变相地实现了A与B的分布式事务。

以上几个步骤可能存在异常情况，现在对其进行分析：

• 步骤一出错：则整个事务失败，不会执行服务A的本地操作。
• 步骤二出错：则整个事务失败，不会执行服务A的本地操作。
• 步骤三出错：需要做回滚预备消息，由服务A实现一个消息中间件的回调接口，消息中间件会不断执行回调接口，检查服务A事务执行是否执行成功，如果失败则回滚预备消息。
• 步骤四出错：这个时候服务A的本地事务是成功的，但是消息中间件不需要回滚，其实通过回调接口，消息中间件能够检查到服务A执行成功了，这个时候其实不需要服务发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务。

【编辑推荐】

1. 9月数据库排行：Microsoft SQL Server 分数罕见下滑
2. 分享一次生产MySQL数据库主备切换演练
3. 详解MySQL数据库常见的索引问题：无索引，隐式转换，附实例说明
4. 闲聊数据库高可用容灾规划设计
5. 记一次生产数据库log file sync 等待事件异常及处理过程

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!