zookeeper-笔记-一致性算法

一、Paxos协议

Paxos算法是一种《一致性算法》，作用是让 Asynchronous non-Byzantine Model的分布式环境中的各个agent达成一致，Chubby的一致性算法就是Paxos,Zookeeper的一致性算法是Zab

我打一个比方，7 个朋友要决定晚上去哪里吃饭。一致性算法就是保证要么这 7 个朋友达成一致选定一个地方去吃饭，要么因为各种异常情况达不成一致，但是不能出现一些朋友选定一个地方，另外一些朋友选定另外一个地方的情况。

一、在分布式环境中由若干个agent组成，agent之间通过传递消息进行通讯：

1、agent 以任意的速度速度运行，agent 可能失败和重启。
2、消息需要任意长的时间进行传递，消息可能丢失，消息可能会重复。但是消息不会被拦截，或者被篡改

Paxos算法中的agent角色有哪几种：

1、client: 发送请求给Paxos算法服务
2、learner: 获取一个Paxos算法实例决定的结果
3、proposer: 发送 prepare请求和accept 请求
4、acceptor: 处理 prepare请求和accept请求。

下面介绍下四种消息之间的交互

Paxos协议的应用：复制状态机

什么是复制状态机?

看下Paxos 算法如何实现复制状态机的一致性算法模块

这里面的状态机是一个 KV 系统。通过复制状态机可以把它变成一个容错为3节点分布式KV系统。上图每个服务端节点都有2个模块，一致性算法模块和状态机模块

下面是处理z=6这个写操作的过程：

1.客户端3发送一个z=6请求给节点3的一致性算法模块
2.节点3的一致性算法发起一个算法实例到其他节点上
3.如果各个节点的一致性算法模块能一起达成一致，节点3把z=6应用到它的状态机，并把结果返回给客户端3。这里的达成一致是说多数机器，也就是大于n/2,n表示服务器节点数

二、Chubby

Chubby是一个分布式锁系统，广泛应用于Google的基础架构中

例如知名的GFS和Bigtable都用Chubby来做协同服务。ZooKeeper借鉴了很多Chubby的设计思想，所以它们之间有很多相似之处。

一个Chubby的集群叫作一个cell，由多个replica实例组成，其中有一个replica是整个cell的master。所有的读写请求只能通过master来处理。读写都给master那么其他的replica做用是什么？防止master宕机?

1、应用通过引入Chubby客户端库来使用Chubby服务。Chubby客户端在和master建立session之后，通过发RPC给master来访问Chubby数据。
2、每个客户端维护一个保证数据一致性的cache。

注意：所有的读请求和写请求只能通过master来处理

Chubby和zookeeper的区别

1、相同之处

1、Chubby的文件相当于ZooKeeper的znode。Chubby的文件和znode都是用来存储少量数据
2、都只提供文件的全部读取和全部写入
3、都提供类似UNIX文件系统的API
4、都提供接收数据更新的通知，Chubby提供event机制，ZooKeeper提供watch机制
5、它们的客户端都通过一个session和服务器端进行交互
6、写操作都是通过leader/master来进行
7、都支持持久性和临时性数据
8、都使用复制状态机来做容错

不同点

1、Chubby内置对分布式锁的支持。ZooKeeper本事不提供锁，但是可以基于ZooKeeper的基本操作来实现锁。
2、Chubby读操作也必须通过master节点来执行。相应的，Chubby保证的数据一致性强一些，不会有读到旧数据的问题。zookeeper读操作可以通过任意节点来执行。相应的，ZooKeeper保证的数据一致性弱一些，有读到旧数据的问题
3、Chubby提供一个保证数据一致性的cache。有文件句柄的概念。ZooKeeper不支持文件句柄，也不支持cache，但是可以通过watch机制来实现cache。但是这样实现的cache还是有返回旧数据的问题。
4、Chubby基本操作不如ZooKeeper的强大。ZooKeeper提供更强大的基本操作，例如对顺序性节点的支持，可以用来实现更多的协同服务。
5、Chubby使用Paxos数据一致性协议。ZooKeeper使用Zab数据一致性协议。

三、Raft算法

Raft是目前使用最为广泛的一致性算法，和Paxos很类似都是解决一致性算法

例如新的协同服务平台etcd和Consul都是使用的Raft算法。在Raft出现之前，广泛使用的一致性算法是Paxos。Paxos的基本算法解决的是如何保证单一客户端操作的一致性，完成每个操作需要至少两轮的消息交换。和Paxos不同，Raft有leader的概念。Raft在处理任何客户端操作之前必须选举一个leader，选举一个leader需要至少一轮的消息交换。但是在选取了leader之后，处理每个客户端操作只需要一轮消息交换。

Raft论文描述了一个基于Raft的复制状态机的整体方案，例如Raft论文描述了日志复制、选举机制和成员变更等这些复制状态机的各个方面。相反Paxos论文只是给了一个一致性算法，基于Paxos的系统都要自己实现这些机制。

Raft集群

1、一个Raft集群包括若干服务器。服务器可以处于以下三种状态：leader、follower和candidate。
2、只有leader处理来自客户端的请求。
3、follower不会主动发起任何操作，只会被动的接收来自leader和candidate的请求。
4、在正常情况下，Raft集群中有一个leader，其他的都是follower。

Raft选举算法原理

1、Raft使用心跳机制来触发leader选取。
2、一个follower只要能收到来自leader或者candidate的有效RPC，就会一直处于follower状态。
3、leader在每一个election time out向所有follower发送心跳消息来保持自己的leader状态。如果follower在一个election time out周期内没有收到心跳信息，就认为目前集群中没有leader。此时follower会对自己的current Term进行加一操作，并进入candidate状态，发起一轮投票。
4、它会给自己投票并向其他所有的服务器发送Request Vote RPC，然后会一直处于candidate状态，直到下列三种情形之一发生：

1.这个candidate赢得了选举。
2.另外一台服务器成为了leader。
3.一段时间之内没有服务器赢得选举。在这种情况下，candidate会再次发起选举。

Raft 的选举对应的就是 Paxos 的 prepare 阶段，它们是很相似的

Raft的复制状态机系统架构

上图是一个Raft集群，每个Raft节点都有 1、一致性算法模块 2、状态机模块 3、日志模块

三者之间的流程是，收到写请求，把更新的数据写入日志，然后通过一致性算法模块通知其他节点，其他节点的《一致性算法模块》收到请求，写入自己的日志模块，更行状态机里面的值。

上图展示了执行一条客户端写命令的过程（z←6表示把6写入z）下面很重要

1、客户端3发送一个状态机命令z←6给服务器C的一致性算法模块。C此时是leader节点
2、一致性算法模块把状态机命令写入服务器C的日志，同时发送日志复制请求给服务器A和服务器B的一致性算法模块。服务器A和服务器B的一致性算法模块在接收到日志复制请求之后，分别在给子的服务器上写入日志，然后回复服务器C的一致性算法模块。
3.服务器C的一致性算法模块在收到服务器A和B对日志复制请求的回复，然后让C的状态机执行来自客户端的命令。为什么服务器C为什么最后执行状态机，因为服务器是leader节点，所以他的执行表示客户端请求的执行结果。
4.服务器C的状态机把执行结果返回给客户端3。

Raft日志复制

leader在接受到一个写命令之后，为这个命令生成一个日志条目，然后进行日志复制。leader通过发送AppendEntries RPC把日志条目发送给follower，让follower把接收到的日志条目写入自己的日志文件。另外leader也会把日志条目写入自己的日志文件。日志复制保证Raft集群中所有的服务器的日志最终都处于同样的状态。

Raft 的日志复制对应的就是 Paxos 的 accept 阶段，它们是很相似的。

日志条目的提交

leader只有在多数节点提交以后，才可以在状态机里面执行客户端请求。提交意味着集群中多数服务器完成了客户端请求的日志写入，这样做是为了保证以下两点：

1、容错：在数量少于Raft服务器总数一半的follower失败的情况下，Raft集群仍然可以正常处理来自客户端的请求。
2、确保重叠:一旦Raftleader响应了一个客户端请求，即使出现Raft集群中少数服务器的失败，也会有一个服务器包含所有以前提交的日志条目。

Raft日志复制示例

上图表示的是一个包括5个服务器的Raft集群的日志格式，S1处于leader状态，其他的服务器处于follower状态

每个日志条目由一条状态机命令和创建这条日志条目的leader的term。每个日志条目有对应的日志索引，日志索引表示这条日志在日志中的位置。假设S5全程都是正常状态，但是由于S5是follower节点，所以Raft集群中提交的日志条目是S5上面的所有日志条目，因为这些日志条目被复制到了集群中的大多数服务器。

日志匹配

Raft日志条目具备以下日志匹配属性：

1、如果两个服务器上的日志条目有的相同索引和term，那么这两个日志条目存储的状态机命令是一样的。

在一个新的leader出来之后，follower的日志可能和leader的日志一致，也可能处于以下三种不一致状态：

1.follower与leader相比少一些日志条目。
2.follower与leader相比多一些日志条目。
3.包含（1）和（2）两种不一致情况。

例如在图中，follower(a)和follower(b)属于不一致情况1，follower©和follower(d)属于不一致情况2，follower(e)和follower(f)属于不一致情况3。

如何保证一个新term的leader保存了所有提交的日志条目，以下两点保证新 term 的 leader 保存了所有提交的日志条目：

1. 日志条目只有复制到了多个多个服务器上，才能提交。
2. 一个 candidate 只有赢得了多个服务器的 vote ，才能成为 leader 。并且要求只有 candidate 的日志比自己的新的时候才能 vote 。

四、Zab协议

zab协议是Zookeeper中的一个原子广播协协议，实现数据的一致性；
集群中的所有事务都是由Leader节点处理，然后又leader节点同步到其他节点follower;

Zab协议中角色：
1.Leader角色：负责处理集群中的所有事务
2.follower角色：参数事务请求投票和leader选举投票
3.observer角色：不参与事务请求投票和leader选举投票；只能处理非事务请求

Zab中的角色：
1.Looking:进入Leader选举状态
2.Following:Follower和leader服务器保持同步时的状态
3.Leading：Leader服务器的状态

Zxid事务编号 & sid
zxid是一个64位的数字，低32位表示的是一个单调递增的计数器
高32位表示坐在的周期，共同确定分布式事务的唯一性；

sid:表示zookeeper集群中id，人为指定，主要用来leader选举；

选举规则：
1.先比较zxid，在比较sid，
2.先投自己 选票内容(zxid,sid)
3.遇强改投