分布式事务解决方案总结

分布式事务在分布式架构的项目中是不可避免的一个问题。这个知识点在面试中也是经常会被问到。下面是我的学习总结。没有很详细，但是可以作为总结性的笔记。

典型方案

关于分布式事务，工程领域讨论的是强一致性和最终一致性的解决方案。典型方案包括：

• 两段式提交（2PC）方案
• eBay事件队列方案
• TCC补偿模式
• 缓存数据最终一致性

理论支撑

分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可的问题。所以需要分布式事务解决方案来保证数据一致性。而著名的CAP理论决定了，在解决一致性问题时，其实和系统可用性，分区容忍性也是需要一起考量的关键。

CAP理论

在分布式系统中：

• 一致性（Consistency）
• 可用性（Availability）
• 分区容忍性（Partition Tolerance）
  3个要素只能同时满足2个，不可兼得，其中分区容忍性是大家都不会放弃的。

一致性模型

一致性模型，有3类：

• 强一致性 (任意时刻，所有分区中的数据都是一致的)
• 弱一致性 (更新数据后，不保证所有系统都能读取到最新的值，也不保证多久后可以读到)
• 最终一致性 (更新数据后，系统不承诺立即返回最新写入的值，但是保证是可以全部分区都可以更新到该值)

分布式解决方案

1、2PC方案-强一致性

实现原理：通过提交分阶段和记日志的方式。等到所有阶段的事务都准备好可以成功提交后，再全部下发提交。在准备过程中会记录日志，假如没有成功的阶段，可以通过日志返回处理。
缺点：同步阻塞，适用于数据库层面
3PC做了一些改进，增加了超时机制。但实现者不多

2、eBay事件队列方案-最终一致性

eBay架构师首先提出的。核心思想是将分布式需要处理的任务使用消息或者日志的方式异步执行，将消息和日志缓存到本地文件、数据库或者消息队列，再根据业务规则进行失败重试，或者撤销。要求接口是支持幂等的。
实现方案：本地消息表、mq

3、TCC（Try-Confirm-Cancel）补偿模式–最终一致性

TCC模型有一个事务管理者，会记录TCC全局事务状态。而在每个服务中，需要服务的业务方记录调用链路，自己去做好失败后，回滚的操作。

4、缓存数据-最终一致性

在业务系统中，缓存作为数据库的缓冲，会将数据库的数据同步到缓存中。这个过程就会出现不一致的现象。
1、为缓存数据设置过期时间。这个过期时间就是系统可以达到的最终一致的容忍时间。
2、更新数据库数据后同时清除缓存数据。

本文由博客一文多发平台 OpenWrite 发布！