cockroach官方文档翻译---2.5复制层

2.5 复制层

 CockroachDB的复制层在节点间复制副本集，实现我们自己的一致性算法保证副本的一致性。

**概要

--与其他层进行交互

**组件

--raft

--快照(snapshots)

--租约(leases)

--成员改变(membership changes):重定向和修复

**与其他层交互

--复制层与分布层

--复制层与存储层

2.5.1 概要

高可用要求数据库容忍部分节点离线，不中断应用服务。这意味着节点的复制数据需要确保是可达的。

在部分节点离线的情况下，确保一致性，是一个很多数据库没完成的挑战。为了解决这个问题，cockroachDB使用一致性算法，要求更改提交之前，副本的规定数目节点同意这个更改。3是最小的数量可以达到规定数目（3个中的2个），cockroachDB高可用(多数节点活跃高可用)需要3个节点。

可以容忍失败数=(副本集因子-1)/2，例如，有3x个副本，1个副本失败可以被容忍;如果有5x个副本，2个失败可以容忍;你可以控制集群/数据库/表中的副本集因子使用副本集区域

https://www.cockroachlabs.com/docs/stable/configure-replication-zones.html

 

当失败发生时，cockroachDB自动检测到节点停止响应和工作，重新分配你的数据保证最大的耐受性。进程触发：新的节点加入集群，数据自动重分配，保证负载均匀的分布。

**与其他层的交互

复制层：

--接收来自分布式层的请求，并向分布式层发送请求

--向存储层发送写请求

2.5.2 组件

** raft

Raft是一个一致性协议，是一个算法保证数据在多机器上安全存储。即使部分节点当前无法连接，这些机器可以同意当前状态。

Raft管理包含一个组中的一个range的一个副本的所有节点，叫做raft组。raft组的每个副本不是领导者（leader）就是跟随者(follower)。领导者是被raft和长期活跃的节点选举出来的，负责协调raft组的所有写。领导者向跟随者周期性发送心跳，保证他们的日志被复制。如果心跳缺失，跟随者变为随机的选举的候选者，选举新的领导者。

一旦一个节点接收到对它包含一个的range的BatchRequest，将这些KV操作转化为Raft指令。这些指令提给raft组的领导者，raft组的领导者将其理想化为租获得者，raft组的领导者也是其中一个，并写入raft日志。

对于raft的更多细节，请查看。

http://thesecretlivesofdata.com/raft/

 

>> 如何理解raft一致性

如果有一个单节点，存储单个值，并作为数据库服务器，客户端发送一个值到服务器，单节点很容易保证一致性。

如果有多节点，如何保证一致性，这就是分布式一致性问题。Raft是一个协议实现分布式一致性。

>> 协议概要

高可用是如何工作的，一个节点可以是三种状态中的一种，follower(跟随者)状态，candidate(参与者)状态，leader(领导者)状态，所有的节点都是从follower状态开始，如果followers没听到leader，follower转化为candidate(参与者)，这个参与者向其他节点发送投票请求，其他节点将回复他们的投票，参与者变成领导者如果他获取到多数节点的投票。这叫做领导者选举。系统中所有的改变需要通过领导者。每个更改作为一个实体被添加到节点日志中，这个日志实体没有提交，所以并不会更新到节点的值中。为了提交这个实体，节点首先将他复制到跟随节点，然后领导者等待直到大多数的节点实体被写入，实体在leader节点提交。然后leader告知跟随者实体已经提交。集群现在处于系统状态的一致性状态。这个过程叫做日志复制。

>> leader 选举

在raft中有两个超时设置，去控制选举，第一个是选举超时，选举超时是follower等待直到变成一个candidate。选举超时是随机的，在150ms和300ms之间，在选举超时以后，follower变成一个参与者，开始一个新的选举阶段。投票给他自己，向其他节点发送投票请求。如果接受到请求的节点尚未投票，它将投票给candidate，然后节点重置选举超时。一旦一个节点获取到多数节点的投票，它变成leader。Leader向他的跟随者发送Append Entries消息，这些消息被发送的间隔时间为心跳超时。Follower回复每个Append Entries消息。这个选举阶段会一直持续直到Follower停止接受心跳，变为candidate者。

让我们停止leader，看看再次选举是如何发生的，

节点A现在是阶段2的leader，需要多数节点的投票，保证在每个阶段只有一个leader，如果两个节点同时变成candidate，将发生一个投票分裂。我们查看一个投票分裂的例子。

两个节点在同一个阶段开始投票，每个在另一个之前或者一个follower，

现在每个candidate有两票，无法在这个阶段接受其他的投票。节点等待新一轮的投票。

在第五阶段，节点D获得了多数投票，变成leader。

>> 日志复制

一旦我们选举出一个leader，我们需要向系统中的所有节点复制所有的更改。通过使用与被用于心跳的相同的Append Entries消息完成。现在我们来看看这个进程。

首先一个客户端向leader发送一个更改，这个更改记录在leader的log中，这个更改发送给Follower在下一个心跳中。实体提交一但大多数Follower获得它，将相应发送给客户端。

现在发送一个命令增加2，我们的系统被更新到7.

Raft可以保持一致，面对网络墙。我们添加一个墙隔离AB和CDE。

因为我们的墙，在不同的阶段具有两个leader。

再添加一个客户端，试图去更新两个leader，一个客户端试图将节点B设置为3.节点B不能复制到多数节点，它的日志实体不能提交。客户端试图将节点C的值设置为8，将会成功，因为可以复制到大多数节点。现在我们恢复网络，节点B看到更高的选举阶段，自己转化为follower。

节点AB将回滚他们的未提交实体，匹配新的leader日志。日志在整个集群保持一致性。

**Raft日志

当写接受到规定数据，raft组领导者提交，他们将写入raft log。它提供了一个有序的指令集，是得到副本同意的，并且是一致副本的真实源。

因为日志是序列化的，可以被重放，使一个节点从过去的一个状态达到当前的状态。这个日志使节点当前离线可以被捕获，并恢复到当前状态，不需要对当前已存在数据进行快照，获得数据副本。

**快照

每个副本可以被快照，快照是所有数据的副本有一个精确的时间戳(因为MVCC)，在重新平衡(rebalance)中，快照可以发送给其他节点加快复制。

在加载快照之后，节点需要从raft组日志中，重放所有的快照时间点后的动作。

**租约

一个单独的节点作为租约获得者(leaseholder)，对于raft组leader（所有来自于DistSender的动作，将接受到BatchRequests），只有一个节点可以提供读或者写服务。

在读服务中，通过raft的租约获得者，对于租约获得者的写在一个地方提交时，必须已经达到一致状态，所以对于相同数据的第二次一致是没必要的。这样是有益处的raft不受网络情况影响，可以提高读的速度(不需要牺牲一致性)。

CockroachDB试图去选举一个租约获得者，这也是raft组的领导者，可以优化写的速度。

如果没有租约获得者(leaseholder)，接收请求的任何节点试图成为租约获得者。为了防止两个节点都需要租约，请求方包含一个最新的有效的租约副本，如果另一个节点变成租约获得者，这个请求忽略。

--raft leadership重定向

Range租约与raftleadership完全分离。所以没有未来的努力，相同的副本不会同时持有raftleadership与range租约。不过我们可以优化query的表现，相同的节点成为raftleader和 leaseholder(租约获得者)，可以减少了网络往返，如果leaseholder收到请求可以简单的给他自己发送raft的命令，不需要与其他节点交流。

为了达到这个，每个租约重建或者转移试图搭配他们，在实验中，错配是极少的，可以被快速自我修正。

--Epoch-Based Leases，基于代际的租约(表数据)

为了管理表数据的租约，cockroachDB实现了”epoch”(代)的概念，代是一个节点加入集群到与集群失连的一段时间。当一个节点失连，epoch改变，节点失去了它的所有租约。

这个机制使我们没必要跟踪每个range的租约，消除了大量的交易，我们可以视为一个租约不会过期，直到节点失连。

--基于期限的租约(元或者系统range)

表的元range和系统range(具体查看分发层)被视为正常的KV数据，因此租约也是。与使用epochs(代)不同，他们有一个基于期限的租约。这些租约过期有一个具体的时间戳（一般是几秒），不过只要节点继续发送raft指令，就继续续期租约。否则，包含副本的另一个节点试图读或者写range变成租约获得者。

**成员改变: 重新平衡或者修复

无论何时集群中的节点数目改变，raft 组改变，为了保证最优的耐受性和性能，副本需要重新平衡。节点数目即节点添加或者下线。

节点添加：一个新节点与自己及其他节点交流，表明有空余的空间。集群重新平衡一些副本到新的节点。

节点下线：如果raft group的一个节点停止响应，5分钟后，接线会自动下线，集群开始复制数据，重新平衡。

**重新平衡副本集

当cockroachDB检测到一个成员改变，副本将在节点之间移动。使用leaseholder的副本快照，当通过gRpc发送数据到其他节点，在转换完成之后，节点拥有新的副本加入到range的raft组中，检查range的raft组的最近实体最新的时间戳，在节点上重放raft log中所有的事件。

1.5.3 与其他节点交互

**复制层与分布式层

复制层接收来自自己或其他节点的DistSender发送的请求，如果节点是这个range的租约获得者，接受这个请求，如果不是，返回错误，并返回指针，指向租约获得者，这些KV请求转化为raft命令。

复制层发送BatchResponses 返回给分布式层的DistSender。

**复制层与存储层

提交raft命令被写入raft日志中，最终通过存储层存储在磁盘上。

租约获得者通过RocksDB实例处理读，在存储层。