专栏名称: 分布式实验室

最专业的Docker文章，最权威的Docker新闻。关注容器生态圈的发展。

分布式系统的一些基础理论

分布式实验室 · 公众号 · 后端 · 2021-12-16 07:45

正文

分布式系统与 ZooKeeper 的关系

集中式服务

我们先从服务部署架构的发展历程说起，其实无非就是集中式和分布式，集中式就是说，什么我都是由一台机器搞定的。分布式就是多台服务器联合完成。所以在一开始的时候一般都是从一台服务器开始，将我们的服务部署上去，然后就是一些老套路，Web 应用就部署在 Tomcat 上开放 8080 端口提供服务，然后它需要的一个数据库服务就开放 3306 端口提供。它的优点就在于结构，部署，项目架构都比较简单。

然后再根据业务的发展去扩展，那扩展同样也可以分为两种方式，一种是横向扩展，一种为纵向扩展。既然一台搞不定，那就要不提升这个服务器的性能，要不就整多几台一起上。但是我们想想，也不是个人就会把服务器安排的服服帖帖的呀，这台机子一挂，那就全挂了。而且大型主机的购买，还有研发，维护人才，那都是得花大价钱的。这里给大家扩展一个 “摩尔定律”：

反正简单点来说，就是我花两倍的钱，根本买不到两倍的性能。但是横向扩展就不一样了，一个人打不过，叫多几个人一起打不就行了？

去 IOE 运动

阿里巴巴搞出来的一个口号，具体点就是 IBM 小型机，Oracle 数据库，EMC 的高端存储，有兴趣的也可以了解一下。因为当时面临的问题是，企业如果需要提升单机处理能力，成本会很高且性价比极低。还整天怕这怕那的，一宕机就整个服务停掉。慢慢的国内很多公司跟着一起响应，分布式就起来了。

分布式服务

分布式系统有着它具体的定义：分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅通过消息传递进行通信和协调的系统。所以就是一堆计算机联合起来对外提供服务，但是对于用户来说，像是一台机子在完成这事。

特点很多，大致就是下面5个：

分布：这个就是多台计算机都被放置在了不同的位置
对等：集群中的多个工作节点都是一个货色，干的都一样的活儿。而且存在副本概念
并发：多个机器同时操作一份数据可能会引发的数据不一致问题
全局时钟：多个主机上的事件先后顺序会对结果产生影响，这也是分布式场景中非常复杂的一个问题
各种故障：某节点宕机，网络不好……突发情况

分布式场景中经常遇到的几个问题

通信异常：其实就是网络问题，导致多节点状态下数据不一致
网络孤立：这个其实就是各个子网络内部正常，但是整个系统的网络是不正常的。导致局部数据不一致的问题
节点宕机问题
分布式三态：成功，失败，超时这3种状态引出的各个问题。请求发送和结果响应都有可能丢失，无法确定消息是否发送/处理成功
数据丢失：这个一般通过副本机制，从其它节点读取解决，或者对于有状态的节点来说丢失数据就可以通过恢复状态来解决。

异常处理原则：任何在设计阶段考虑到的异常情况都必须假设一定会在实际运行中发生。

衡量分布式系统的性能标准

性能：主要就是吞吐能力，响应延迟，并发能力。系统某一时间可以处理的数据总量，通常是用系统每秒处理的总数据量衡量，而响应延迟指的是完成某一功能所需要的的时间。并发能力就是同时完成某一功能的能力，通常就是用 QPS 衡量
可用性：在面对各种异常时可以正确提供服务的能力。比如我们常说的 5 个 9 就是指一年内只有 5 分钟的宕机时间。6 个 9 就是 31 秒
可扩展性：指可以通过扩大机器规模达到提高系统性能的效果
一致性：副本管理

但是这些标准都是一个方面要求太高之后会带动另外一方面变差，比如说我们需要做到高可用，可能需要多个副本，但是多个副本的状态下，对于数据的一致性又很难去做到了。然后高吞吐下又很难做到低延迟，所以我们需要针对自己的业务场景去进行考量。

对于一致性的扩展

强一致性：写操作完成之后，读操作一定能读到最新数据，在分布式场景中这样是非常难实现的，比如 Paxos 算法，Quorum 机制，ZAB 协议都是干这个事的。
弱一致性：不承诺可以立即读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能的保证到某个时间级别（比如 XX 时，XX 分，XX 秒后），数据可达到一致性状态。

它还有一个特例叫做最终一致性，就是尽可能快的保证数据的一致。但是这个快到底是多快，就没有准确定义了。好比女票想要吃到炸鸡，你给点了份外卖，可是美团骑手，饿了吗骑手也说不准什么时候送到，他只能说保证尽快送到。就这么个意思。

因为最终一致性实在是太弱了所以我们还有一些特例情况会出现读写一致性，它是指用户读取自己写入的结果永远可以第一时间看到自己更新的内容，这个就像微信朋友圈一样的，我们发出来的东西，微信是一定会让我们看到的，可是朋友们是不是你发了立刻就能看到，那可就说不准。

还有一些单调读一致性，因果一致性就不展开说明了，有兴趣的小伙伴可以自行搜索。

总而言之，为了保证系统的高可用，防止单点故障引发的问题，并能够让分布在不同节点上的副本都能正常为用户提供服务，这时，我们的 ZooKeeper 就应运而生了。它就能帮助我们解决这个分布式系统中数据一致性的问题。

需要解决这个问题我们需要了解分布式事务，分布式一致性算法，Quorum 机制，CAP 和 BASE 理论，接下来我们慢慢去展开。

分布式事务

事务：单机存储系统中用来保证存储系统的数据状态一致性，这是不是读起来有点拗口，没事，我们换个说法，广义上的事务，就是指一个事情的所有操作，要不全部成功，要不全部失败，没有中间状态。狭义一点，那就是数据库做的那些操作。特征也很简单，就是耳熟能详的 ACID 。

分布式系统中每个节点都仅仅知道自己的操作是否成功，但是不知道其它节点是个啥情况，这就有可能导致各节点的状态可能是不一致的，所以为了实现跨越多节点且保证事务的 ACID 时，需要引入一个协调者，然后参与事务的各个节点都叫做参与者。

典型的套路就是 2PC 和 3PC，接下来我们慢慢展开。

2PC 是个什么东西

在事务的参与过程中会产生多个角色，暂时我们先这么理解，协调者负责事务的发起，而参与者负责执行事务。

假定存在上面的 3 个角色，分别是一个协调和两个参与，此时我们需要 A，B 执行一个事务，并且要求这个事务，要么同时成功，要么同时失败。

2PC 阶段一：执行事务

此时协调者会先发出一个命令，要求参与者 A，参与者 B 都去执行这个事务，但是不提交。

说的再详细一点，就会产生写 redo，undo 的日志，锁定资源，执行事务。但是执行完了之后，直接向协调者打报告，询问一下，大哥我能提交吗？

这个在日常写 Java 的过程中应该经常遇到，就是前面写了一大堆操作，但是等到最后一定会写一个 conn.commit() 这样的东西，这就是所谓的执行但不提交。

2PC 阶段二：提交事务

当协调者收到第一阶段中的所有事务参与者（图中的 A，B）的反馈（这个反馈简单理解为，告诉协调者前面的第一阶段执行成功了）时，就发送命令让所有参与者提交事务。

如果要说的再细一点，那就是协调者收到反馈，且所有参与者均响应可以提交，则通知参与者进行 commit，否则 rollback。

所以 2PC 也叫做二阶段提交，其实就是这么简单分成了两步，一步执行，一步提交。

2PC 的4个缺点：性能

整个流程看下来就知道这明显产生了同步阻塞，各个需要操作数据库的节点都占用了数据库的资源。只有当协调者收到所有节点都准备完毕的反馈，事务协调者才会通知 commit or rollback，而参与者执行完这个 commit or rollback 的操作后，才会去释放资源。

2PC 的4个缺点：单点故障

那我们刚刚也知道了，协调者才是这个事务的核心。假如此时协调者故障宕机，会导致通知无法传达到参与者的问题，比如收不到那个 commit or rollback，整一个事务便会停滞。

2PC 的4个缺点：数据不一致

协调者在第二阶段会发送 commit or rollback。可是这并不能保证每一个节点都正常收到这个命令，所以会可能窜在，参与者 A 收到了命令，提交了事务，但是参与者 B 没有。所以网络波动是永恒的病因，你永远无法躲开这个因素。

2PC 的4个缺点：不存在容错机制

这个协调者需要收到所有的节点反馈准备完成才会下达 commit 的指示，任意一个参与者的响应没有收到，协调者就会进行等待，而且只要存在一个宕机的节点，都会使得整个事务失败回滚。

3PC 是个啥东西

在 2PC 的前提下进行了一个改良，将 2PC 中的准备阶段进行拆分，形成 can commit，pre commit，do commit 三个阶段。

并且引入超时机制，一旦事务参与者在指定时间内没有收到协调者的 commit or rollback 指令，就会自动进行本地 commit，解决协调者的单点故障问题。

3PC 第一阶段 cancommit

协调者先询问：哎你们这帮人到底能不能行？参与者就根据自身的实际情况回答 yes or no。

3PC 第二阶段 precommit

如果参与者都是返回同意，协调者则向所有参与者发送预提交请求，并进入准备阶段，这里的准备阶段其实就是让参与者锁定资源，等待指令的意思，然后就是事务的执行，此时也像 2PC 一样，执行但不提交。然后等待协调者的指令，此时如果迟迟等不到指令，一段时间后就会自行本地提交。

但是这样也会存在弊端，比如协调者成功给 1，2 参与者都发送回滚，然后 3 刚好就没收到，那么 3 就自动提交了，所以超时机制其实并不能完全保证数据的一致性。

分布式一致性算法

Paxos 算法

Paxos 算法是一个名字叫 Lesile Lamport 提出的一种基于消息传递且具有高度容错特性的一致性算法。

是不是觉得绕口？没事，我们只需要知道，分布式系统中不可避免的会发生进程被 kill，消息延迟，重复，丢失……一系列问题，Paxos 算法就是在这些异常情况下的仍然保证数据一致性的东西。那这东西和 ZooKeeper 有啥关系呢？ZooKeeper 是存在一个 ZAB 协议的，但是这个 ZAB 协议底层就是封装了 Paxos 算法的。

Paxos 中存在的角色及与 ZooKeeper 集群的关系

Proposer 提议者：顾名思义就是发起提案的人。

Acceptor 接受者：它们是可以表决的，可以接受或者否决提案。

Learner 学习者：提案被超过半数的 Acceptor 接受的话，就学习这个提案。

映射到 ZooKeeper 集群中，就分别是 leader，follower，observer，它们有点像是主席，人大代表，和全国老百姓的关系，主席提出一个提案，人大代表参与投票，全国老百姓被动接受，大概就是这么个感觉。相比于之前的 2PC，3PC，它只需要半数通过即可提交。所以这种属于弱一致性，2PC，3PC 这些就属于强一致性。

Raft 算法

请点击这个链接：http://thesecretlivesofdata.com/raft/，相信你一定能够很快掌握。我这里还是小小的说明一下吧，这个是一个 PPT 的形式，告诉你，Raft 到底是个什么东西，非常好懂，我这里跳过前面的一些东西，直奔主题。

这里说到了，Raft 是实现分布式共识算法的一个协议：

这里假设一个节点有 3 种不同的状态：

第一种，Follower state（无线条）：

第二种，Candidate state（虚线）：

第三种，Leader state（实线），记住 Leader 是从 Candidate 候选人那里选出来的：

首先我们一上来，所有的节点都是 Follower state：

接下来，所有的 Follower 节点都寻找 Leader，当他们找不到的时候，就会自发成为候选人发起投票（问其它人是否赞成我成为 Leader），什么情况才会找不到呢？那肯定就是 Leader 挂了嘛。

此时它就发送给其它节点投票的提案，然后其它节点也会给予它反馈，当它接收到超过半数的节点的反馈的时候，它就可以顺理成章的成为 Leader 了。

之后写数据的请求就会直接发给 Leader，由 Leader 广播给其它的 Follower，此时也是只要超过半数节点返回正反馈，那这个写数据的事务就会被执行，然后 Leader 再给它们发送提交命令，事务就算执行成功了。

ZAB 协议

所有事务转发给 Leader（当我们的 Follower 接收到事务请求）
Leader 分配全局单调递增事务 id（zxid，也就是类似于 Paxos 算法的编号 n），广播协议提议
Follower 处理提议，作出反馈（也就是承诺只接受比现在的 n 编号大的）
Leader 收到过半数的反馈，广播 commit，把数据彻底持久化（和 2PC 不同的是，2PC 是要等待所有小弟反馈同意）
Leader 对原来转发事务的 Followe 进行响应，Followe也顺带把响应返回给客户端

ZooKeeper 的底层实现就是 ZAB 协议，它实现了崩溃恢复（Leader崩溃）和消息广播（客户端写数据 ZooKeeper 要保证多节点都成功写入）功能。主要就是保证在 Leader 服务器上提交的事务最终让所有服务器都提交，并确保丢弃掉只在 Leader 服务器上所提出的事务。

Quorum NWR 机制

Quorum NWR：Quorum 机制是分布式场景中常用的，用来保证数据安全，并且在分布式环境中实现最终一致性的投票算法。这种算法的主要原理来源于鸽巢原理。它最大的优势，既能实现强一致性，而且还能自定义一致性级别。

鸽巢原理，又名狄利克雷抽屉原理、鸽笼原理。

其中一种简单的表述法为：若有 n 个笼子和 n+1 只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少 2 只鸽子。

另一种为：若有 n 个笼子和 kn+1 只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少 k+1 只鸽子。

为什么从抽屉原理说起？一来大家对这个比较熟悉，也容易理解，二来它与 Quorum 机制有异曲同工的地方。抽屉原理，2 个抽屉每个抽屉最多容纳 2 个苹果，现在有 3 个苹果无论怎么放，其中的一个抽屉里面肯定会有 2 个苹果。那么我们把抽屉原理变变型，2 个抽屉一个放了 2 个红苹果，另一个放了 2 个青苹果，我们取出 3 个苹果，无论怎么取至少有 1 个是红苹果，这个理解起来也很简单。我们把红苹果看成更新了的有效数据，青苹果看成未更新的无效数据。便可以看出来，不需要更新全部数据（并非全部是红苹果）我们就可以得到有效数据，当然我们需要读取多个副本（取出多个苹果）。

回到 Quorum NWR 机制的 NWR 到底指什么？

N：复制的节点数，即一份数据被保存的副本数。
W：写操作成功的节点数，即每次数据写入写成功的副本数。W 肯定是小于等于 N 的。
R：读操作获取最新版本数据所需的最小节点数，即每次读取成功至少需要读取的副本数。

总结：这三个因素决定了可用性，一致性和分区容错性。只要保证（W + R > N）就一定能读取到最新的数据，数据一致性级别完全可以根据读写副本数的约束来达到强一致性！

分以下三种情况讨论：前提，当 N 已经固定了。

W = 1，R = N，Write Once Read All

在分布式环境中，写一份，那么如果要读取到最新数据，就必须要读取所有节点，然后取最新版本的值了。写操作高效，但是读操作效率低。一致性高，分区容错性差，可用性低。

R = 1，W = N，Read Only Write All

分布式系统的一些基础理论

正文

请到「今天看啥」查看全文