分布式系统的知识点-理论基础

前言

这一小节将介绍分布式系统中的经典理论，如广为流程的 CAP/BASE 理论，一致性理论基础 paxios,raft，信息交换的 Gossip 协议，两阶段、三阶段等

理论基础

2.1 CAP 定理

CAP 定理指出，分布式系统 不可能 同时提供下面三个要求：

Consistency：一致性

操作更新完成并返回客户端之后，所有节点数据完全一致。

Availability：可用性

服务一直可用。

Partition tolerance：分区容错性

分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

通常来讲 P 很难不保证，当服务部署到多台实例上时，节点异常、网络故障属于常态，根据不同业务场景进行选择。

对于服务有限的应用而言，首选 AP，保证高可用，即使部分机器异常，也不会导致整个服务不可用；如绝大多数的前台应用都是这种。

对于数据一致性要求高的场景，如涉及到钱的支付结算，CP 可能更重要了。

对于 CAP 的三种组合说明如下：

2.2 BASE 理论

base 理论作为 cap 的延伸，其核心特点在于放弃强一致性，追求最终一致性。

Basically Available: 基本可用

指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用

如大促时降级策略。

Soft State：软状态

允许系统存在中间状态，而该中间状态不会影响系统整体可用性。

MySql 异步方式的主从同步，可能导致的主从数据不一致。

Eventual Consistency：最终一致性

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

基于上面的描述，可以看到 BASE 理论适用于大型高可用可扩展的分布式系统。

注意其不同于 ACID 的强一致性模型，而是通过牺牲强一致性 来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

2.3 PACELEC 定理

这个真没听说过，以下内容来自:

Distributed System Design Patterns | by Nishant | Medium

如果有一个分区（‘P’），分布式系统可以在可用性和一致性（即 ‘A’ 和 ‘C’）之间进行权衡；

否则（‘E’），当系统在没有分区的情况下正常运行时，系统可以在延迟（‘L’）和一致性（‘C’）之间进行权衡。

定理（PAC）的第一部分与 CAP 定理相同，ELC 是扩展。整个论点假设我们通过复制来保持高可用性。因此，当失败时，CAP 定理占上风。但如果没有，我们仍然必须考虑复制系统的一致性和延迟之间的权衡。

2.4 Paxos 共识算法

Paxos 算法解决的问题是分布式共识性问题，即一个分布式系统中的各个进程如何就某个值（决议）通过共识达成一致

基于上面这个描述，可以看出它非常适用于选举；其工作流程

一个或多个提议进程 (Proposer) 可以发起提案 (Proposal)，

Paxos 算法使所有提案中的某一个提案，在所有进程中达成一致。

系统中的多数派同时认可该提案，即达成了一致

角色划分:

Proposer: 提出提案 Proposal，包含编号 + value

Acceptor: 参与决策，回应 Proposers 的提案；

当一个提案，被半数以上的 Acceptor 接受，则该提案被批准

每个 acceptor 只能批准一个提案

Learner: 不参与决策，获取最新的提案 value

2.5 Raft 算法

推荐有兴趣的小伙伴，查看

Raft 算法动画演示

Raft 算法详解 - 知乎

为了解决 paxos 的复杂性，raft 算法提供了一套更易理解的算法基础，其核心流程在于：

leader 接受请求，并转发给 follow，当大部分 follow 响应之后，leader 通知所有的 follow 提交请求、同时自己也提交请求并告诉调用方 ok

角色划分：

Leader：

领导者，接受客户端请求，并向 Follower 同步请求，当数据同步到大多数节点上后告诉 Follower 提交日志

Follow: 接受并持久化 Leader 同步的数据，在 Leader 告之日志可以提交之后，提交

Candidate：

Leader 选举过程中的临时角色，向其他节点拉选票，得到多数的晋升为 leader，选举完成之后不存在这个角色

2.6 ZAB 协议

ZAB (Zookeeper Atomic Broadcast) 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的一致性协议，基于该协议，ZooKeeper 实现了一种 主从模式的系统架构来保持集群中各个副本之间的数据一致性。

zookeeper 核心之 ZAB 协议就这么简单！

主要用于 zk 的数据一致性场景，其核心思想是 Leader 再接受到事务请求之后，通过给 Follower，当半数以上的 Follower 返回 ACK 之后，Leader 提交提案，并向 Follower 发送 commit 信息

角色划分

Leader: 负责整个 Zookeeper 集群工作机制中的核心

事务请求的唯一调度和处理者，保证集群事务处理的顺序性。

集群内部各服务器的调度者。

Follower：Leader 的追随者

处理客户端的非实物请求，转发事务请求给 Leader 服务器

参与事务请求 Proposal 的投票

参与 Leader 选举投票

Observer：

是 zookeeper 自 3.3.0 开始引入的一个角色，

它不参与事务请求 Proposal 的投票，

也不参与 Leader 选举投票

只提供非事务的服务（查询），通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

2.7 2PC 协议

two-phase commit protocol，两阶段提交协议，主要是为了解决强一致性，中心化的强一致性协议。

角色划分

协调节点 (coordinator)：

中心化

参与者节点 (partcipant)：

多个

执行流程

协调节点接收请求，然后向参与者节点提交 precommit，当所有的参与者都回复 ok 之后，协调节点再给所有的参与者节点提交 commit，所有的都返回 ok 之后，才表明这个数据确认提交。

当第一个阶段，有一个参与者失败，则所有的参与者节点都回滚

特点

优点在于实现简单。

缺点也很明显

协调节点的单点故障。

第一阶段全部 ack 正常，第二阶段存在部分参与者节点异常时，可能出现不一致问题。

2.8 3PC 协议

分布式事务：两阶段提交与三阶段提交 - SegmentFault 思否

在两阶段的基础上进行扩展，将第一阶段划分两部，cancommit + precommit，第三阶段则为 docommit。

第一阶段 cancommit

该阶段协调者会去询问各个参与者是否能够正常执行事务，参与者根据自身情况回复一个预估值，相对于真正的执行事务，这个过程是轻量的。

第二阶段 precommit

本阶段协调者会根据第一阶段的询盘结果采取相应操作，若所有参与者都返回 ok，则协调者向参与者提交事务执行 (单不提交) 通知；否则通知参与者 abort 回滚。

第三阶段 docommit

如果第二阶段事务未中断，那么本阶段协调者将会依据事务执行返回的结果来决定提交或回滚事务，若所有参与者正常执行，则提交；否则协调者 + 参与者回滚。

在本阶段如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 commit 或 rollback 请求，那么参与者将不会如两阶段提交中那样陷入阻塞，而是等待超时后继续 commit，相对于两阶段提交虽然降低了同步阻塞，但仍然无法完全避免数据的不一致。

特点

降低了阻塞与单点故障：

参与者返回 CanCommit 请求的响应后，等待第二阶段指令，若等待超时 / 协调者宕机，则自动 abort，降低了阻塞；

参与者返回 PreCommit 请求的响应后，等待第三阶段指令，若等待超时 / 协调者宕机，则自动 commit 事务，也降低了阻塞；

数据不一致问题依然存在

比如第三阶段协调者发出了 abort 请求，然后有些参与者没有收到 abort，那么就会自动 commit，造成数据不一致。

2.9 Gossip 协议

Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。Gossip 协议通过上面的特性，可以保证系统能在极端情况下（比如集群中只有一个节点在运行）也能运行

P2P 网络核心技术：

Gossip 协议 - 知乎

主要用在分布式数据库系统中各个副本节点同步数据之用，这种场景的一个最大特点就是组成的网络的节点都是对等节点，是非结构化网络。

工作流程

周期性的传播消息，通常周期时间为 1s。

被感染的节点，随机选择 n 个相邻节点，传播消息。

每次传播消息都选择还没有发送过的节点进行传播。

收单消息的节点，不会传播给向它发送消息的节点。

特点

扩展性：

允许节点动态增加、减少，新增的节点状态最终会与其他节点一致。

容错：

网络中任意一个节点宕机重启都不会影响消息传播。

去中心化：

不要求中心节点，所有节点对等，任何一个节点无需知道整个网络状况，只要网络连通，则一个节点的消息最终会散播到整个网络。

一致性收敛：

协议中的消息会以一传十、十传百一样的指数级速度在网络中快速传播，因此系统状态的不一致可以在很快的时间内收敛到一致。

消息传播速度达到了 logN。

简单：

Gossip 协议的过程极其简单，实现起来几乎没有太多复杂性。

缺点

消息延迟：

节点只会随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网的，因此使用 Gossip 协议会造成不可避免的消息延迟。

消息冗余：

节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，导致消息的冗余。

总结

本节主要介绍的是分布式系统设计中的一些常见的理论基石，如分布式中如何保障一致性，如何对一个提案达成共识

BASE，CAP，PACELEC 理论：

构建稳定的分布式系统应该考虑的方向

paxos,raft 共识算法

zab 一致性协议

gossip 消息同步协议

现在我邀请你进入我们的软件测试学习交流群：【746506216】，备注“入群”， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路。

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！