双十一时，百哥的朋友圈被一条抖音截图刷屏了



这条抖音是阿里官方号发的，大概意思是随便剪网线，拉闸断电，都不影响我们买买买，让我们放心，发生故障也不影响我们花钱。

那么，从网络技术层面，有哪些可以实现这样高可靠性的技术呢？

小贴士：

网络高可靠性：是指当设备或网络出现故障时，网络提供服务的不间断性。

互联网公司的可靠性都会做到5个9以上

–可靠性99.999%意味着每年故障时间不超过5分钟

–可靠性99.9999%意味着每年故障时间不超过30秒

为了实现更多的9，从网络技术、云计算技术、数据存储技术、甚至能源技术经过多年发展，产生了很多技术，本文分享几个常用的网络高可靠性技术。

MSTP，多生成树技术



可以通过连接多条线路，实现冗余，当一条线故障，数据会走备用线路。

但是因此会产生环路，环路会导致广播风暴，广播风暴又会导致网络崩溃。

所以必须有个技术来解决环路，这个技术就是生成树，简称STP。

STP随着技术发展，又进化成了RSTP和MSTP，RSTP是加快了线路切换的速度，MSTP则可以部署多实例，实现数据更合理的分流。

什么？你说生成树过时了，有更好的技术了，那这个技术是什么呢？

VRRP，虚拟路由冗余协议

前面实现了线路的冗余，一条线被剪断了，被老鼠咬了，被队友不小心踢掉了，都没有关系，因为有备用线路。

但是如果网关设备坏了怎么办，有备用线路，没网关也不行啊。

这时可以使用VRRP技术，实现网关设备的冗余。

简单点来说就是让多个设备来充当网关，一台坏了，其他的立即顶上，网络不断。

Linux服务器上的keepalived技术，也是基于VRRP协议。

什么？你说VRRP也过时了，还有更好的技术了，行！

链路聚合

看到那个小圈圈了吧，这个就是拓扑图中用来表示链路聚合的。

链路聚合就是把多条线捆绑起来，变成逻辑上的一根线来用，这样不仅线路冗余了，可靠性高了，两个设备间的带宽还变大了。

而且，没有环路，因为这本来就变成1根线了。

链路聚合，不同厂商有不同的名字，但其实是一个意思，也遵循相同的协议，可以互相兼容。

华为叫E-trunk，思科叫以太网通道，锐捷叫AP（aggregate port）等

堆叠技术

堆叠技术，也叫设备虚拟化技术，可以把多台设备，虚拟成一台。

然后通过多条线路，连到多台成员设备上，再把线路捆绑成一条。

这样，就相当于把高可靠性网络，变成了逻辑上的单核心单线路网络。

不但拓扑简单，整体性能还更高，故障发现和切换还更快，足以代替传统的mstp+vrrp解决方案。

但是传统技术依然在广泛应用，因为要使用设备虚拟化技术，首先得产品支持，包括硬件和软件都得支持，很多中低端设备没这功能，或者高端设备的老版本软件支持不佳，升个级又提心吊胆怕变砖。

本文列举几个网络方面的高可靠性技术，其实为了实现数据中心的高可靠性，还远远不够，欢迎关注百哥，更多技术干货会持续更新。

作者：disksing

对 Raft 有所了解的同学都知道，Raft 一般会使用奇数个节点，比如 3、5、7 等等。这是因为 Raft 是 一种基于多节点投票选举机制的共识算法，通俗地说，只有超过半数节点在线才能提供服务。这里超过半数的意思是 N/2+1（而不是N/2）。举例来说，3 节点集群需要 2 个以上节点在线，5 节点集群需要 3 个以上节点在线，等等。对于偶数节点的集群，2 节点集群需要 2 节点同时在线，4 节点集群需要 3 节点在线，以此类推。实际上不只是 Raft，所有基于 Quorum 的共识算法大体上都是这么个情况，例如 Paxos，ZooKeeper 什么的，本文仅以 Raft 为例讨论。
先考察一下为什么 Raft 通常推荐使用奇数节点而不是偶数节点。
共识算法要解决的核心问题是什么呢？是分布式系统中单个节点的不可靠造成的不可用或者数据丢失。Raft 保存数据冗余副本来解决这两个问题，当少数节点发生故障时，剩余的节点会自动重新进行 leader 选举（如果需要）并继续提供服务，而且 log replication 流程也保证了剩下的节点（构成 Quorum）总是包含了故障前成功写入的最新数据，因此也不会发生数据丢失。
我们对比一下 3 节点的集群和 4 节点的集群，Quorum 分别是 2 和 3，它们能容忍的故障节点数都是 1。如果深究的话，从概率上来说 4 节点集群发生 2 节点同时故障的可能性要更高一些。于是我们发现，相对于 3 节点集群，4 节点集群消耗更多的硬件资源，却换来了更差的可用性，显然不是个好选择。
但是！！！
上面说了，Raft 解决的核心问题有两个，分别是高可用和数据容灾。跟奇数节点相比，偶数节点的方案从可用性上看很不划算，但是数据容灾方面却是有优势的。还是以 4 节点为例，因为 Quorum 是 3，写入数据的时候需要复制到至少 3 个节点才算写入成功，假如此时有 2 个节点同时故障，这种情况下虽然不可用了，但是剩余的两个节点一定包含有最新的数据，因此没有发生数据丢失。这一点很容易被忽视，在常见的奇数节点配置下，保证可用和保证数据不丢所容忍的故障节点数是重合的，但是在偶数节点配置下是不一样的。
根据上面的分析，偶数节点集群的适用场景是“能容忍一定时间的不可用，但不能容忍数据丢失”，应该有不少严肃的金融场景是符合这个描述的，毕竟一段时间不服务也比丢掉数据要强呀。
下面以两数据中心环境为例来对比一下。限制条件是任意一个数据中心故障时（比如发生严重自然灾害），能容忍一定时间的不可用，但不允许发生数据丢失。
如果使用奇数节点集群配置，两个数据中心的节点数一定是不对等的，一旦节点数更多的那个数据中心故障，就可能发生数据丢失了。而如果使用偶数节点配置，两个数据中心的节点数是一样的，任意一个数据中心故障后，另一个数据中心一定包含有最新数据，我们只需要使用工具改写 Raft 元信息，让剩余数据中心的所有节点组成新的 Raft Group 并使得 Quorum 恰好等于剩余节点数，Raft 选举机制将会自动选择包含有最新数据的节点当 leader 并恢复服务。
题外话：本来想在 etcd 上实践下这套方案，可惜最后一步 etcd 恢复数据的时候只支持从单一节点恢复，所以无法做到“自动选择包含有最新数据的节点当 leader 并恢复服务”。我给 etcd 提了个 issue 不过貌似并没有成功让他们了解到我想干啥，如果有人看到这里觉得这事情有搞头的话，可以帮忙去 issue 下支持一下（https://github.com/etcd-io/etcd/issues/11486 ）。

以上内容转载自 disksing 个人博客：原文地址 。

讨论话题：

Raft 通常需要三数据中心来解决高可用问题，但一些场景下面，用户只有两个数据中心，那么使用 Raft 协议还有意义吗？
欢迎大家在本篇文章下面踊跃留言，分享你遇到过的“偶数节点 Raft”的案例或者各种“奇葩”问题  以及你的思考～

 作者：disksing
对 Raft 有所了解的同学都知道，Raft 一般会使用奇数个节点，比如 3、5、7 等等。这是因为 Raft 是 一种基于多节点投票选举机制的共识算法，通俗地说，只有超过半数节点在线才能提供服务。这里超过半数的意思是 N/2+1（而不是N/2）。举例来说，3 节点集群需要 2 个以上节点在线，5 节点集群需要 3 个以上节点在线，等等。对于偶数节点的集群，2 节点集群需要 2 节点同时在线，4 节点集群需要 3 节点在线，以此类推。实际上不只是 Raft，所有基于 Quorum 的共识算法大体上都是这么个情况，例如 Paxos，ZooKeeper 什么的，本文仅以 Raft 为例讨论。  
先考察一下为什么 Raft 通常推荐使用奇数节点而不是偶数节点。
共识算法要解决的核心问题是什么呢？是分布式系统中单个节点的不可靠造成的不可用或者数据丢失。Raft 保存数据冗余副本来解决这两个问题，当少数节点发生故障时，剩余的节点会自动重新进行 leader 选举（如果需要）并继续提供服务，而且 log replication 流程也保证了剩下的节点（构成 Quorum）总是包含了故障前成功写入的最新数据，因此也不会发生数据丢失。  
我们对比一下 3 节点的集群和 4 节点的集群，Quorum 分别是 2 和 3，它们能容忍的故障节点数都是 1。如果深究的话，从概率上来说 4 节点集群发生 2 节点同时故障的可能性要更高一些。于是我们发现，相对于 3 节点集群，4 节点集群消耗更多的硬件资源，却换来了更差的可用性，显然不是个好选择。
但是！！！
上面说了，Raft 解决的核心问题有两个，分别是高可用和数据容灾。跟奇数节点相比，偶数节点的方案从可用性上看很不划算，但是数据容灾方面却是有优势的。还是以 4 节点为例，因为 Quorum 是 3，写入数据的时候需要复制到至少 3 个节点才算写入成功，假如此时有 2 个节点同时故障，这种情况下虽然不可用了，但是剩余的两个节点一定包含有最新的数据，因此没有发生数据丢失。这一点很容易被忽视，在常见的奇数节点配置下，保证可用和保证数据不丢所容忍的故障节点数是重合的，但是在偶数节点配置下是不一样的。
根据上面的分析，偶数节点集群的适用场景是“能容忍一定时间的不可用，但不能容忍数据丢失”，应该有不少严肃的金融场景是符合这个描述的，毕竟一段时间不服务也比丢掉数据要强呀。
下面以两数据中心环境为例来对比一下。限制条件是任意一个数据中心故障时（比如发生严重自然灾害），能容忍一定时间的不可用，但不允许发生数据丢失。
如果使用奇数节点集群配置，两个数据中心的节点数一定是不对等的，一旦节点数更多的那个数据中心故障，就可能发生数据丢失了。而如果使用偶数节点配置，两个数据中心的节点数是一样的，任意一个数据中心故障后，另一个数据中心一定包含有最新数据，我们只需要使用工具改写 Raft 元信息，让剩余数据中心的所有节点组成新的 Raft Group 并使得 Quorum 恰好等于剩余节点数，Raft 选举机制将会自动选择包含有最新数据的节点当 leader 并恢复服务。
题外话：本来想在 etcd 上实践下这套方案，可惜最后一步 etcd 恢复数据的时候只支持从单一节点恢复，所以无法做到“自动选择包含有最新数据的节点当 leader 并恢复服务”。我给 etcd 提了个 issue 不过貌似并没有成功让他们了解到我想干啥，如果有人看到这里觉得这事情有搞头的话，可以帮忙去 issue 下支持一下（https://github.com/etcd-io/etcd/issues/11486）。
 以上内容转载自 disksing 个人博客：原文地址 。
讨论话题：
Raft 通常需要三数据中心来解决高可用问题，但一些场景下面，用户只有两个数据中心，那么使用 Raft 协议还有意义吗？
 欢迎大家在本篇文章下面踊跃留言，分享你遇到过的“偶数节点 Raft”的案例或者各种“奇葩”问题  以及你的思考～