欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

etcd raft cap 理解

程序员文章站 2024-03-19 21:35:58
...

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各种使用场景

CAP 适用场景 解释
CA 几乎不存在 在分布式系统中,P必然存在,除非适用单机,要提升分区可靠性,需要通过提升基础设施的可靠性实现
CP 分布式数据库(Redis、HBase、zk、etcd) 分布式数据库极端情况下优先保证数据一致性
AP 12306购票、淘宝购物 保证服务可用,购票下单后,一段时候后系统提示余票不足

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

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

相关标签: etcd raft cap