- 1【可解释性机器学习】详解Python的可解释机器学习库：SHAP_shap python
- 2halcon应用范围-表面检测1一塑料制品表面缺陷检测_halcon塑料网1,2,3
- 3Redis的快速入门【全方位进攻】
- 4【STM32】读写BKP备份寄存器&RTC实时时钟
- 5JAVA在线考试系统_java考试系统
- 6java代码手动添加hosts中没有的hostname和ip, 添加DNS缓存_使用 java 中添加临时的hosts映射
- 7clickhouse的SQL参考——（二）create_create settings profile sgs_muser_profile settings
- 8HarmonyOS/OpenHarmony原生应用-ArkTS万能卡片组件Stack_arkts stack()
- 9立体匹配算法概述_立体匹配原理
- 102022-2023 ICCV、ECCV、CVPR关于有感自动驾驶的论文_eccv近三年最佳论文
etcd raft cap 理解_cap etcd
赞
踩
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
- 1
- 2
- 3
- 4
- 5
详细见
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应用场景
