ETCD跨城容灾与异地多活网络故障的相关表现分析
etcd集群进行分布式设计，并且通过raft协议来进行选leader以及确保数据一致性和高可用能力。本文重点分析在不同网落区之间出现网络中断时，相关的etcd集群的表现，以探究和加强对etcd集群的理解。更多raft协议的理解可以参考 分布式Raft原理详解，从不同角色视角分析相关状态
1. 网络架构
etcd集群一共有7个节点，分别部署在3个IDC，整体架构如下
在该架构下，理论上能够兼容任意网络区域之间的网络中断，能够重新选举出leader，从而保证etcd整体的可用性。但是当区域的集群表现时，我们通过分析相关日志来验证。
2. 单个网络中断-跟leader区中断
架构如下
2.1. 网络中断
上图中BC之间的网络出现了中断，leader节点在C区域，集群整体可用
由于leader在C区，并且能够接受来自AC两个区的节点心跳，因此集群leader不会触发选举，整体可用
B区由于不能跟C区域通信，跟集群的leader失联，会尝试进行投票选举出新的leade
B区的2个节点除了自己投票外，会给A区域的3个节点发送投票申请
A区的节点由于能够感知到C区的leader心跳，因此会拒绝B区的投票请求
B区的节点由于无法获取到足够的选票，因此无法选举出leader，并且持续发送投票，因此投票的周期会持续增大
2.2. 网络恢复
上图中BC之间的网络恢复后，原leader收到了更高选票周期的B的通信，为了保证数据一致性，会重新出发选
- B区的节点选票周期虽然更高，但是由于持续没有从原leader同步数据，因此数据索引index小于AC区节点，因此B区不能被选举出leader
- 重新触发选举后，leader会在AC中的节点选举出新leader，从而集群恢复可用
- 新leader选举出来后，会同步相关数据到其他follower节点，保持数据一致
恢复后，重新触发选举leader的原理，在 分布式Raft原理详解，从不同角色视角分析相关状态有说明
4.3. Leader（主节点）
节点成为Leader节点后，此时可以接受客户端的数据请求，负责日志同步
如果遇到更高任期Term的Candidate的通信请求，这说明Candidate正在竞选Leader，此时之前任期的Leader转化为Follower，且完成投票；
如果遇到更高任期Term的Leader的通信请求，这说明已经选举成功新的Leader，此时之前任期的Leader转化为Follower
3. 单个网络中断-跟非leader区中断
架构如下
如上图AB区连接中断，由于leader在C区，能够跟A\B正常连接，因此这种情形下，整体集群能够正常提供访问，不会导致leader重新触发选举。
4. 两个网络中断-leader区中断
架构如下
在这种情况下，由于AC\AB区网络不通，因此会在AB区重新进行选举leader，从而重新提供服务
5. 两个网络中断-非leader区中断
架构如下
在这种情况下，leader能够跟其他的区正常连接，因此整体集群能够正常提供服务，也不会重新触发leader选举
6. 两个网络中断-非leader区中断
架构如下
在这种情况下，由于各个区域网络中断，不能获取超过半数节点选举出leader，因此集群不能对外提供服务。
7. 总结
在3区域环境，按照这样的架构设计，能够兼容非所有区域网络中断的场景，能够兼容2个区网络中断。因此能够提供比较高的高可用服务能力
