分布式事务处理：原理、架构与现代扩展方法

### 分布式事务处理：原理、架构与现代扩展方法 #### 1. Paxos 与 2PC 结合的 Paxos 2PC 协议 Paxos 具备 2PC 和 3PC 的多轮决策特性，以及法定人数算法的多数投票方法，它将这些特性整合为一个连贯的协议，用于在分布式进程中达成共识。实际上，2PC 和 3PC （以及其他提交协议）是 Paxos 的特殊情况。 Paxos 2PC 中，事务管理器充当领导者（之前的协调者现在称为领导者）。该协议的主要特点是领导者使用 Paxos 协议达成共识，并将决策记录在复制日志中。一方面，此协议不需要所有参与者都活跃并参与决策，多数参与者同意即可，其他参与者在恢复后可收敛到已决定的值；另一方面，领导者（协调者）故障不再会导致阻塞，若领导者失败，可选举新的领导者，且事务决策状态可在其他站点的复制日志中获取。 #### 2. 分布式数据库管理系统可靠性的架构考量 在抽象层面讨论了原子提交协议后，需要考虑如何在架构模型中实现这些协议，这涉及并发控制算法和可靠性协议之间的接口规范，与 Commit、Abort 和 recover 命令的执行相关。但精确指定这些命令的执行并不容易，原因有二：一是需要更详细的架构模型；二是实现方案依赖于本地恢复管理器的恢复过程。因此，架构讨论主要集中在三个方面： - **协调者和参与者概念的实现**： - 一种实现方式是在每个站点的事务管理器中同时执行协调者和参与者算法，可使分布式提交操作执行更统一，但会导致参与者事务管理器与其调度器之间不必要的通信，因为调度器需决定事务是否可提交或中止。 - 更好的选择可能是将协调者作为事务管理器的一部分，参与者作为调度器的一部分。若调度器实现严格的并发控制算法（不允许级联中止），在收到准备消息时会自动准备提交事务。 - **协调者对数据库日志的访问**：数据库日志由本地恢复管理器（LRM）和缓冲区管理器维护，但提交协议的实现需要事务管理器和调度器也能访问日志。解决方案有两种：一是维护一个单独的提交日志（分布式事务日志）供事务管理器访问；二是将提交协议记录写入同一数据库日志，此方法可简化日志记录保存算法，且单个数据库日志可作为本地恢复管理器和调度器恢复信息的中央存储库。 - **本地恢复管理器操作的更改**：将提交协议记录存储在数据库日志中需要修改 LRM 算法，一般要分别处理 prepare 命令和全局提交（或全局中止）决策。恢复时，LRM 需读取数据库日志并通知调度器每个事务的状态。具体步骤如下： 1. LRM 确定故障站点是协调者还是参与者的主机，此信息可与 Begin_transaction 记录一起存储。 2. LRM 搜索提交协议执行期间写入日志的最后一条记录。 3. 若未找到 begin_commit 记录（协调者站点）或 abort 或 commit 记录（参与者站点），事务未开始提交，LRM 可继续恢复过程。 4. 若提交过程已开始，恢复工作交给协调者，LRM 将最后一条日志记录发送给调度器。 下面是 LRM 恢复操作的 mermaid 流程图： ```mermaid graph TD; A[LRM 启动恢复] --> B[确定故障站点角色]; B --> C{是否找到提交相关记录}; C -- 否 --> D[继续恢复过程]; C -- 是 --> E[将最后日志记录发送给调度器]; E --> F[协调者处理恢复]; ``` #### 3. 传统事务处理算法的瓶颈 上述所有算法在事务处理的不同阶段都会引入瓶颈。实现可串行化的算法由于大型查询读取大量数据项与更新事务之间的冲突，严重限制了潜在的并发性能。例如，不基于主键的全表扫描分析查询会与表上的任何更新产生冲突。而且，所有算法都需要一个集中处理步骤来逐个提交事务，处理速率受限于单个节点，无法处理更高速率的事务。此外，锁定算法需要进行死锁管理，许多使用死锁检测，在分布式环境中实