彻底搞透分布式一致性( 二 ) _分布式

负载的挑战：随着业务的快速增长，数据库中的数据量或负载也会达到单一实例的上线，此时，我们：

垂直拆分：将不同的表放到不同的数据库实例，比如拆分出 User 实例， Order 实例；

文章插图
图片
水平拆分：数据量超过单表最大容量时，将数据分拆到不同的数据库，比如 Order-1 实例、Order-2 实例；

文章插图
图片
垂直+水平拆分：先进行垂直拆分，在进行水平拆分；

文章插图
图片

微服务的挑战：微服务已经成为系统的事实架构，特别是 Spring Boot 和 Spring Cloud 的流行：

微服务的“自治”要求每个微服务都应该有自己的独立数据存储，避免与其他服务共享数据存储，从而降低服务之间的耦合性；
微服务间通过服务发现、负载均衡等方式，将服务之间的关系解耦，从而使得每个服务都具备独立的自治性；

文章插图
图片
不管触发哪一种条件，都会产生跨数据库事务，从而增加系统设计的难度。
2. 常见一致性保障机制针对该问题前人已经提出来多种应对方案，特别是关系型数据库。
2.1. MySQL事务一致性熟悉 MySQL 实现的伙伴知道， MySQL 是通过 Redo log 和 Undo log 来实现事务一致性的：

Redo Log：Redo Log 记录了事务对数据库所作的修改，包括插入、更新、删除等操作，它在事务提交前就被写入磁盘。如果出现故障导致系统崩溃，MySQL 会从 Redo Log 中恢复数据；
Undo Log：Undo Log 记录了事务对数据库所作的修改的「前置操作」，并且在事务回滚时用来撤销事务所做的修改。当事务执行更新时，MySQL 会先将修改前的数据存储到 Undo Log 中，当事务需要回滚时，MySQL 会根据 Undo Log 中的记录将数据还原为修改前的状态。

具体的如下图所示：

文章插图
图片
从图中可知：

每一个 DML 语句都会为其生成对应的 Redo log 和 Undo log 。

Redo log 记录正向修改；
Undo log 记录逆向恢复；

事务提交应用全部 Redolog 以持久化正向修改；
事务回滚应用全部 Undolog 以逆向恢复；

其中，可以看出存在两个核心流程：

向前补偿：redo log 记录了事务执行的过程，以及事务提交前的数据修改，可以通过重做日志来恢复数据，实现向前补偿；
向后补偿：undo log 记录了事务执行过程中对数据的修改，可以用于回滚事务，实现向后补偿；

除了两种补偿机制外，还涉及一个重要的组件“补偿管理器”，用于对补偿机制进行统一协调。

2.2. 2PC 和 XA2PC（Two-Phase Commit）和XA是分布式事务中常用的协议和接口：

2PC是分布式事务协议，用于在分布式系统中协调多个参与者的事务提交或回滚。它包括两个阶段：准备阶段和提交阶段，参与者在准备阶段告知协调者它们是否可以正常提交，如果都能正常提交，则在提交阶段所有参与者都提交事务。如果有一个参与者无法正常提交，则所有参与者都需要回滚；
XA是一组应用程序接口（API），它使应用程序能够参与分布式事务，并与事务管理器协同工作，以保证事务的一致性。XA接口包括三个接口：XA Transactions、XA Resource、XA Resource Manager，用于实现分布式事务的协调和管理。

MySQL 采用了两阶段提交（Two-Phase Commit ，简称 2PC）协议，保证 Redolog 和 Binlog 间的数据一致性，确保事务在所有相关节点（包括 Redolog 和 Binlog）执行的情况下，要么全部提交成功，要么全部回滚失败。