etcd raft cap 理解

etcd raft cap 理解

label: cap、raft、etcd

写这篇文章，主要是在smartx面试时，被CTO问到了一些顶层设计的问题，这让我感觉到自己对raft理解太浅了，或者说根本没理解清楚。

首先raft的协议是做什么的？

分布式共识算法，通过raft协议让各个节点保持状态一致；

etcd基于raft来做的分布式kv数据库的目的是什么？

etcd收zk的启发，基于raft协议开发的。分布式etcd能够带来什么优势呢？HA,etcd的HA表现在多节点能够对外提供数据一致的服务，同时在发生节点宕机、网络分区等，etcd集群整体仍能对外提供服务。

通过etcd的HA，我们明白raft协议的目的是，提供HA的环境下的一致性数据。而不是，之前乱向的提高读性能。

从其设计出发点，应该明白etcd提供的kv不适合对读写性能要求特别高的场景，它比较适合量小，但需要可靠的一致性数据存储服务，比如存储配置数据，在k8s中etcd用来存储集群的元数据。

网络分区对etcd的影响，以及节点数量对于服务的影响？

以5（ABCDE,A:leader）节点的etcd集群为例，发生网络分区AB|CDE：
AB部分，leader A向followers发送心跳，但无法获得大多数节点的响应，timeout后，进入选举阶段，AB都无法获得大多数的节点投票（因为和CDE分区，5节点下大多数要求包括自己在内的至少3个节点的投票确认）；
CDE部分，超时后，也进入选举阶段，因为CDE的个数为5节点中的多数，所以可以选出leader对外提供服务；

以上是从集群角度看网络分区，接下来看客户端收网络分区的影响：
因为raft是强leader型算法，客户端使用etcd服务只能通过leader进行，AB分区后，不存在leader，所以无法对外提供服务，之前连接AB节点的客户端将无法获取服务；
客户端无法感知leader发生变换，它将请求交给AB时，因为AB知道自己不是leader，但同时也不知道leader是谁，所以会向客户端响应轮询节点更换，找到新的leader。
因为分区后AB服务对外提供读写服务，之前连接AB的客户端会受此影响，所以会增加请求读时间，这里就体现了raft协议满足了CAP中的CP，而没有满足A。

节点数量对于服务的影响？

在对raft协议的设计目标、网络分区等理解后，就能明白节点数量的影响：
节点数量越多，就能够容忍越多不能提供服务的节点，比如3节点只能允许一个节点失效，而5节点可以允许2节点失效。

那节点数量是不是越多越好？
不是的，etcd leader是需要向follower发送日志的，节点越多，发送的日志也就越多，同样leader的连接数也就越多；leader确认时，也就需要收到更多的follower的投票才能成为leader。所以数量较多可靠性较高，但性能会下降。

etcd可以手动增加、删除节点，也就是说节点数量对于各节点来说是相对静止的，在手动删除/增加后，节点数量变化，并通知到各节点
可以通过 member list查看节点数量

./etcdctl --endpoints=$ENDPOINTS member list 
98f0c6bf64240842, started, cd2, http://127.0.0.1:2580, http://127.0.0.1:2579
b9057cfdc8ff17ce, unstarted, , http://127.0.0.1:2180, 
bf9071f4639c75cc, started, cd0, http://127.0.0.1:2380, http://127.0.0.1:2379
e3ba87c3b4858ef1, started, cd1, http://127.0.0.1:2480, http://127.0.0.1:2479

详细见
etcd-集群节点的增加、删除操作
将有问题的etcd节点重新加入集群

再回顾一下面试中问的对CAP的理解？

raft协议牺牲了A保留了CP，那如果牺牲其他C、P会怎么样？
首先对于P，在分布式环境下P一定存在，这时再考虑CA;在单机下，P不会存在，CA则必定存在。

P存在，要求C，则在网络分区后，要求数据一致，就需要放弃一部分服务的可用性。
P存在，要求A，则在网络分区后，要求所以节点仍能提供服务，这必定会带来分区间的数据不一致。
P不存在，就是单机环境了，单机下CA是一定存在。

为什么选择大多数节点？因为分区后，我们要尽可能多的对外提供服务，所以在网络分区时当然要选择大多数节点。

CAP各种使用场景

leader选举、日志同步等待更新

参考：
分布式一致性协议Raft的简单理解
etcd 中线性一致性读的具体实现
分布式系统的CAP理论
etcd应用场景