企业架构笔记4 应用架构-存储层2：分布式事务算法-+2PC

Posted 2021-08-04 Lora青蛙

分布式数据库系统

分布式事务
■ 某些业务场景需要事务来保证数据一致性，如果采用了数据集群的方案，那么这些数据可能分布在不同的集群节点上
■ 分布式事务是指会涉及到操作多个数据库的事务，将对同一库事务的概念扩大到了对多个库的事务，目的是为了保证分布式系统中的数据一致性
■ 分布式事务处理的关键是必须有一种方法可以获悉事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）
■ 由于节点间只能通过消息进行通信，因此分布式事务实现起来只能依赖消息通知；但消息本身并不是可靠的，消息有可能丢失，这就给分布式事务的实现带来了复杂性

CAP原理
对于一个分布式计算系统来说，最多只能同时满足以下两点，不可能同时满足三点
■ 一致性(Consistency)：对于某个指定的客户端来说，读操作保证能返回最新的写操作结果
■ 可用性(Availability)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)
■ 分区容忍性(Partition tolerance)：当出现网络分区后，系统能够继续履行职能
网络的“不100%可靠”这一特点，决定了分布式系统不可能选择CA，只能选择CP或AP

CAP理论的延伸：BASE(基本可用，最终一致)理论(Basic Available, Soft-state, Eventual consistency)
■ 核心思想：即使无法做到强一致性，可以采用适合的方式达到最终一致性

最终一致性
■ 在分布式系统中，一致性指多个节点中数据的值是一致的

■ 最终一致性不保证在任意时刻任意节点上的同一份数据都是相同的

CAP的应用
■ CAP关注的粒度是分布式系统中数据的读写，而不是整个系统
♦ 满足CA：典型的是关系数据库，包括其单点集群
♦ 满足CP：典型的是Redis、MongoDB
♦ 满足AP：典型的是Cassandra
■ BASE是CAP理论中AP方案的补充，即：AP方案中牺牲一致性只是分区期间，而不是永远放弃一致性
♦ 仅在很短的时间内(分区期间)，需要在CP和AP之间做选择大部分时间里 (正常运行情况下) ，不需要在CP和AP之间做选择，可以同时满足CA
♦ 在分区期间，CAP中的“放弃某个要素(C或A)”并不意味束手无策，而是需要为分区恢复后做准备，例如在分区期间记录日志
■ CAP忽略了网络延迟

CAP理论的更广泛形式： PACELC定理
■ “忽略复制系统的一致性/延迟权衡”是CAP的一个主要疏忽，因为它在系统运行期间始终存在，而CAP仅在可以说是罕见的网络分区情况下才相关
■ 在分布式计算机系统中，在网络分区（P）的情况下，必须在可用性（A）和一致性（C）之间进行选择（根据CAP定理）；否则（E [stands for else]），即使系统在没有分区的情况下正常运行，也必须在延迟（L）和一致性（C）之间进行选择

两阶段提交 (Two-phase commit protocol, 2PC)
■ 2PC是分布式握手协议
■ 目标：分布在n个节点上的、协同执行的n个子事务的原子提交
■ 是 X / Open中的标准化事务模型，叫 XA Transactions
2PC基于以下假设：
■ 在分布式系统中，存在一个节点作为协调者（Coordinator)，其他节点作为参与者(Participant)，且节点之间可以进行网络通信
■ 所有节点都采用预写式日志，且日志被写入后即保持在可靠的存储设备上
♦ 即使节点损坏，也不会导致日志数据的消失
♦ 所有节点不会永久性损坏，即使损坏，仍然可以恢复

两阶段提交算法的组成
■ 2PC有三个参与者：
♦ 应用程序：向协调者提交 commit() 或者 rollback() 请求
♦ 协调者：接收「应用程序」的请求，并协调「多个参与者」进行事务提交或者回滚
♦ 参与者：管理单个资源(数据库、JMS 等)的事务
■ 2PC算法由两个阶段组成：
♦ preCommit 阶段
♦ commit 阶段

第一阶段（投票）：各参与者投票是否要继续接下来的提交操作
■ (1)协调者向所有参与者发送「提交请求」消息，询问是否可以执行提交事务，并开始等待各参与者的响应
■ (2)参与者执行询问发起的事务操作，并将Undo信息和Redo信息写入日志，返回Yes消息给协调者；如果参与者执行失败，则返回No消息给协调者
第二阶段（执行）
■ 如果收到的所有消息都是yes，则
1)协调者向所有参与者发出“提交事务”的请求
2)参与者完成提交操作，释放整个事务期间占用的资源
3)参与者向协调者发送“确认”消息
4)协调者收到所有参与者反馈的“确认”消息后，完成事务
■ 如果协调者收到任何一个no或参与者超时，则事务终止，同时通知参与者终止事务

算法复杂在哪里？
■ 在无故障情况下，不难达成原子性/一致性共识
■ 复杂在于：在故障情况下，仍然保证原子提交
♦ 故障的类型
● 某个节点宕机
● 某个节点无应答：通信问题?? 宕机??
● 某个节点上的操作未成功（例如，事务中止）
● 多次收到同一消息
♦ 故障的本质
● 分布式系统中的部分可操作性：部分故障与全面瘫痪
● 无法确定是节点故障还是通信故障
● 部分故障很难处理，可能需要阻塞其他正常运行的节点

故障原因与节点恢复
■ 系统故障：重启方案
■ 消息/通信故障：网络延迟导致的消息超时，如何处理
■ 恢复：
♦ 第一步：节点日志、状态转换日志可用于恢复至故障前状态
♦ 第二步：各类节点在故障恢复后的行为，取决于故障发生时所处的阶段

两阶段提交的过程
■ 当应用想要启动一个分布式事务时，它向协调者请求一个事务ID，由协调者向所有参与者发送一个准备请求，然后等待回复
■ 当参与者收到准备请求时，各自检查是否在任意情况下都确实可以提交事务。参与者尝试执行事务，无论成功与否都不提交。到目前为止，协调者以及任何参与者都可以单方面中止事务
■ 如果一个参与者回复了“可以提交”，相当于它做出了一个承诺：即将来宕机、电源故障、硬盘空间不足以及任何冲突都不能作为反悔的理由。换言之，参与者放弃单方面中止事务的权利，尽管此时还没有实际提交
■ 如果有任何参与者回复“否”或超时，协调者就向所有参与者发送针对该事务ID的中止请求
■ 协调者收到所有准备请求的答复后，就对提交或中止作出决定。协调者必须先把这个决定写到硬盘上，这样哪怕它随后就崩溃，在恢复后也能知道自己之前做的决定。这一步被称为提交点
■ 提交点写入后，协调者把决定发送给所有参与者。如果发送失败，协调者必须永远保持重试，直到成功为止，没有回头路。哪怕有参与者突然崩溃，事务也将在其恢复后提交

协调者失效
■ 参与者回复“可以提交”后，协调者突然故障怎么办？
■ 此时参与者已经不能单方面中止事务了，但是协调者永远不做最终决定。这种事务状态称为存疑或不确定的
■ 协调者失联，原则上参与者可以相互沟通，搞清楚每个节点是如何投票的，最后达成一致，但这不是两阶段提交协议的一部分
■ 唯一的办法是等待协调者恢复，这也是为什么协调者在向参与者发送提交或中止的决定前，必须先将这个决定持久化