分布式理论

代码小郭...大约 11 分钟

分布式理论

一、分布式事务

分布式事务产生的情景有以下三种：

跨JVM进程产生分布式事务
跨数据库实例产生分布式事务
多服务访问同一个数据库实例

基于这三种情形产生了CAP、BASE等理论。下面以商品服务的业务场景来介绍相关理论的概念。

1、CAP理论

CAP 是 Consistency、Availability、Partition tolerance 三个单词的缩写，分别表示一致性、可用性、分区容忍性。

下面为了方便对CAP理论的理解，我结合电商系统中的一些业务场景来理解CAP。

整体执行流程如下：

a. 商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）
b. 主数据库向商品服务响应写入成功
c. 商品服务请求从数据库读取商品信息

1.1、C - Consistency

上图中，商品信息的读写要满足一致性就是要实现如下目标：

商品服务写入主数据库成功，则向从数据库查询新数据也成功。
商品服务写入主数据库失败，则向从数据库查询新数据也失败。

如何实现一致性？

写入主数据库后要将数据同步到从数据库。
写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据。

1.2、A - Availability

上图中，商品信息读取满足可用性就是要实现如下目标：

从数据库接收到数据查询的请求则立即能够响应数据查询结果。
从数据库不允许出现响应超时或响应错误。

如何实现可用性：

写入主数据库后要将数据同步到从数据库。
由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有可以按照约定返回一个默认信息，但不能返回错误或响应超时。

1.3、P - Partition tolerance

分区容忍性分是布式系统具备的基本能力

上图中，商品信息读写满足分区容忍性就是要实现如下目标：

主数据库向从数据库同步数据失败不影响读写操作。
其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性？

尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现松耦合。
添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

1.4、CAP组合方式

通过分析发现在满足P的前提下 C 和 A 存在矛盾性：

如果要实现 C 则必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据则需要将从数据库数据锁定，待同步完成后解锁，如果同步失败从数据库要返回错误信息或超时信息。

如果要实现 A 则必须保证数据可用性，不管任何时候都可以向从数据查询数据，则不会响应超时或返回错误信息。

所以在生产中对分布式事务处理时要根据需求来确定满足 CAP 的哪两个方面。

AP组合：
放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。例如：上边的商品管理，完全可以实现 AP，前提是只要用户可以接受所查询到的数据在一定时间内不是最新的即可。通常实现 AP 都会保证最终一致性，后面要总结的 BASE 理论就是根据 AP 来扩展的，一些业务场景比如：订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定的时间内到账即可。
CP组合：放弃可用性，追求一致性和分区容错性，zookeeper 其实就是追求的强一致，又比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。
CA组合：
放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统，最常用的关系型数据就满足了 CA。

CAP 是一个已经被证实的理论，一个分布式系统最多只能同时满足：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证 P 和 A ，舍弃 C 强一致，保证最终一致性。

2、BASE理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。

基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。
软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

3、常见解决方案

前面学习了分布式事务的基础理论，以理论为基础，针对不同的分布式场景业界常见的解决方案有 2PC、3PC、TCC、可靠消息最终一致性、最大努力通知这几种。

3.1、2PC

2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。

在计算机中部分关系数据库如 Oracle、MySQL 支持两阶段提交协议：

准备阶段（Prepare phase）：事务管理器给每个参与者发送 Prepare 消息，每个数据库参与者在本地执行事务，并写本地的 Undo/Redo 日志，此时事务没有提交。（Undo 日志是记录修改前的数据，用于数据库回滚，Redo 日志是记录修改后的数据，用于提交事务后写入数据文件）
提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚（Rollback）消息；否则，发送提交（Commit）消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。

3.2、3PC

三阶段提交又称3PC，相对于2PC来说增加了CanCommit阶段和超时机制。如果段时间内没有收到协调者的commit请求，那么就会自动进行commit，解决了2PC单点故障的问题。

3.3、TCC

TCC 是 Try、Conﬁrm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Conﬁrm、撤销 Cancel。

TCC其实就是采用的补偿机制，其核心思想是：「针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作」

TCC 的三个阶段：

Try 阶段是做完业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的 Conﬁrm 一起才能真正构成一个完整的业务逻辑。
Confirm 阶段是做确认提交，Try 阶段所有分支事务执行成功后开始执行 Conﬁrm。通常情况下，采用 TCC 则认为 Conﬁrm 阶段是不会出错的。即：只要 Try 成功，Conﬁrm 一定成功。若 Conﬁrm 阶段真的出错了，需引入重试机制或人工处理。
Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定成功的。若 Cancel 阶段真的出错了，需引入重试机制或人工处理。

TCC的每个阶段要做好幂等，如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

如果拿 TCC 事务的处理流程与 2PC 两阶段提交做比较，2PC 通常都是在跨库的 DB 层面，而 TCC 则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现 Try、Conﬁrm、Cancel 三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略