系统设计 -- 分布式理论现代架构基石 拜占庭将军问题 CAP理论 ACID理论 BASE理论 MVCC RAFT协议

分布式理论 - 现代架构基石

1. 概述

1.1 什么是分布式？

​ 分布式系统是计算机程序的集合，这些程序利用跨多个独立计算机节点的计算资源来实现共同的目标，可以分为分布式计算、分布式存储、分布式数据库等。

• 分布式系统定义：跨多个节点的计算机程序的集合
• 使用分布式系统的五大优势：去中心化、低成本、弹性、资源共享、可靠性高
• 分布式系统的挑战：故障、网络、环境、安全

1.2 常见的分布式系统

• 分布式存储：GFS、Ceph、HDFS、Zookeeper

• 分布式数据库：Spanner、TiDB、HBase、MangoDB

• 分布式计算：Hadoop、YARN、Spark

1.3 故障模型

• Byzantine failure：节点可以任意篡改发送给其他节点的数据，是最难处理的故障
• Authentication detectable byzantine failure (ADB)：节点可以篡改数据，但不能伪造其他节点的数据
• Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚**（短时间恢复不了，赶紧做一下降级或者切换）**
• Omission failure：节点收到数据的时间无限晚，即收不到数据
• Crash failure：节点停止响应，持续性的故障
• Fail-stop failure：错误可检测，是最容易处理的故障

1.4 拜占庭将军问题

引入:

​ 两将军问题(Two Generals’Problem):两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识。

方案一: 同时发送N个信使，任何一个达到对方军队，都算成功。

方案二: 设置超时时间，发送后未在一定时间返回，则加派信使。

结论：两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。

共识与消息传递的不同:即使保证了消息传递成功，也不能保证达成共识。

三将军问题：

• 如果不存在叛徒，三将军一定可以达成共识。

• 两个“忠将”A“和”B“，一个“叛徒”C”，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。

• 由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致。

四将军问题：

• 将军D作为消息分发中枢，约定如果没收到消息则执行撤退
• 步骤：
  • 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
  • D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。
• 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致

1.5 共识和一致性

• 最终一致性：

  ​ 客户端A读到x=0，当客户端C正在写入时，客户端A和B可能读到0或者1。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventually consistent。

• 线性一致性：

​ 当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。我们称这样的一致性为 Linearizability。
​ 如果要保证“线性”一致性，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟，系统可用性便会受损。

2. 理论基础

2.1 CAP理论

CAP理论分别表示一致性、可用性、分区容错性，三者无法同时满足。

• CA系统：传统数据库的代表

• AP系统：放弃强一致性，保证高可用，不少nosql存储系统采用

• CP系统：放弃可用性，保证数据一致性

针对故障场景，可以通过故障转移的方式，做一个相对较优的解决方式：

​ 允许一个进程作为Master，其他进程作为Backup，当故障时将请求转移给Backup进行处理（主从复制）

2.2 ACID理论

​ 事务是数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行。
​ 数据库事务拥有四个特性ACID，即分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性( Durability )

• 原子性(A)：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。必须保证
• 一致性©：一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态（与 CAP 理论一致性不同） 必须保证
• 隔离性(I)：隔离性是当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离
• 持久性(D)：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

2.3 BASE 理论

BASE理论是针对AP系统而言的，其来源于对大型互联网分布式实践的总结

• Basically Available(基本可用)：假设系统，出现了不可预知的故障，但还是能用
• Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性
• Eventually consistent（最终一致性）：数据最终一定能够达到一致的状态

3. 分布式事务

3.1 二阶段提交

​ 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设：

• 协调者和参与者进行通信
• 预写式日志被保持在可靠的存储设备上
• 所有节点不会永久性损坏，即使损坏后仍然可以恢复
  

可能出现的情况:
情况1) Coordinator不宕机，Participant宕机。如下图所示，需要进行回滚操作
情况2) Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交

情况3) Coordinator宕机，Participant宕机。

回滚:在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚

两阶段提交需解决的问题：

• 性能问题：需要多次网络通信，资源需要等待并锁定
• 新协调者：如何确定状态选出新协调者
• Commit阶段网络分区带来的数据不一致：非所有节点都收到Commit请求，必须回滚

改进：三阶段提交

• 针对两阶段提交的补充，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制
• CanCommit阶段：询问是否可以执行；PreCommit阶段：重新确认是否可以执行
• DoCommit阶段：向所有人提交事务

3.2 MVCC

为了避免使用锁；乐观锁 & 悲观锁

**MVCC：**多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。

版本的选取：使用物理时钟或逻辑时钟

• 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms。
• 逻辑时钟：中心化授时的方式–时间戳预言机（TSO），好处是无需硬件的支持，但是增加网络开销。

3.3 RAFT 协议

概述

• Raft协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。

三种角色

• Leader - 领导者：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
• Follower - 跟随者：接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志；当 Leader 发生故障时，主动推荐自己为 Leader。
• Candidate - 备选者：Leader选举过程中的临时角色。向其他节点发送请求投票信息

四种定义：

• Log（日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
• Term（任期号）：单调递增，每个Term内最多只有一个Leader
• Committed：日志被复制到多数派节点，即可认为已经被提交
• Applied：日志被应用到本地状态机：执行了log中命令，修改了内存状态

Leader选举过程：

• 初始全部为Follower

• Current Term + 1

• 选举自己

• 向其它参与者发起RequestVote请求，retry直到

  • 收到多数派请求，成为Leader，并发送心跳

  • 收到其它Leader的请求，转为Follower，更新自己的Term

  • 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮

Log Replication过程：

​ 新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志

• Leader收到写请求w

• 将w写入本地log

• 向其它Follower发起AppendEntries RPC

• 等待多数派回复

  • 更新本地状态机，返回给客户端

  -下一个心跳通知Follower上一个Log已经被 Committed了

  -Follower也根据命令应用本地状态机

• Follower有问题，Leader一直retry

切主：当Leader出现问题时，就需要进行重新选举

• Leader发现失去Follower的响应，失去Leader身份

• 两个Follower之间一段时间未收到心跳，重新进行选举，选出新的Leader，此时发生了切主

• Leader自杀重启，以Follower的身份加入进来

Stale读：

老Leader未失去身份，新Leader已经选出，产生了双主，old leader收到了读请求。如果直接响应，可能会有Stale Read。

解决方案：

​ 读操作在lease timeout内，默认自己是leader;不是则发起一次heartbeat。等待Commit Index应用到状态机。
​ Election timeout > lease timeout : 新leader上任，自从上次心跳之后一定超过了Election
timeout，旧leader大概率能够发现自己的Lease过期。

图片均来自字节青训营课程，博客作为自己学习记录，如有侵权，麻烦联系删除。