高可用集群的容灾

服务器数量的奇数与偶数

前面我们说过，无论是写操作投票，还是 Leader 选举投票，都必须过半才能通过，也就是说若出现超过半数的主机宕机，则投票永远无法通过。基于该理论，由 5 台主机构成的集群，最多只允许 2 台宕机。而由 6 台构成的集群，其最多也只允许 2 台宕机。即，6 台与5 台的容灾能力是相同的。基于此容灾能力的原因，建议使用奇数台主机构成集群，以避免资源浪费。

但从系统吞吐量上说，6 台主机的性能一定是高于 5 台的。所以使用 6 台主机并不是资源浪费。

容灾设计方案

对于一个高可用的系统，除了要设置多台主机部署为一个集群避免单点问题外，还需要考虑将集群部署在多个机房、多个楼宇。对于多个机房、楼宇中集群也是不能随意部署的，下面就多个机房的部署进行分析。

在多机房部署设计中，要充分考虑“过半原则”，也就是说，尽量要确保 zk 集群中有过半的机器能够正常运行。

（1） 三机房部署

在生产环境下，三机房部署是最常见的、容灾性最好的部署方案。

三机房部署中要求每个机房中的主机数量必须少于集群总数的一半。这样可以保证，三个机房中若有一个机房断电或断网，其它两个机房中的机器总数仍是过半的，集群仍可以正常对外提供服务。当然，若两个机房出现了问题，那么整个集群就瘫痪了。这种情况出现的概率要远低于一个机房出问题的情况。

（2） 双机房部署

zk 官网没有给出较好的双机房部署的容灾方案。只能是让其中一个机房占有超过半数的主机，使其做为主机房，而另一机房少于半数。当然，若主机房出现问题，则整个集群会瘫痪。

CAP 定理

简介

CAP 定理指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

• 一致性（C）：分布式系统中多个主机之间是否能够保持数据一致的特性。即，当系统数据发生更新操作后，各个主机中的数据仍然处于一致的状态。
• 可用性（A）：系统提供的服务必须一直处于可用的状态，即对于用户的每一个请求，系统总是可以在有限的时间内对用户做出响应。
• 分区容错性（P）：分布式系统在遇到任何网络分区故障时，仍能够保证对外提供满足一致性和可用性的服务。

对于分布式系统，网络环境相对是不可控的，出现网络分区是不可避免的，因此系统必须具备分区容错性。但其并不能同时保证一致性与可用性。CAP 原则对于一个分布式系统来说，只可能满足两项，即要么 CP，要么 AP。

集群里面是不存在强一致性（实时一致性、严格一致性），因为数据同步是需要时间的，没办法在A主机改变一个数据后，在B主机，C主机马上得到这个数，这个是做不到的。

可用性的有限时间内：一般搜索引擎，百度0.5秒，谷歌是0.3秒给出千万条数据认为是可用的，HAVEn数据仓库，做海量级别数据查询，检索一般在20到30秒内给出检索结果就认为系统是可用的。不用的系统对优先时间的要求是不一样的。

可用性的响应：响应是用户能够预测到的结果，例如百度搜索，百度告诉我没有结果，或者返回很多相关结果，都是可以预知到的，但是如果返回500错误，404都是不行的，这些都是用户预料不到的，即让用户感觉到困惑的结果是不行的。

分区容错的分区：指的是网络分区

为什么一致性和可用性只能满足一个呢？
因为一致性，如果一个服务器数据更新了，客户端访问其他服务器的相同节点的内容就要是一样的，这就是一致性。但是是做不到的，不能够实时同步。除非牺牲可用性，在数据同步的过程中，不允许对外提供服务，那么牺牲了可用性就保证了一致性。
由于集群中服务器需要做数据同步，需要时间，所以C和A只能保证一个。

BASE 理论

BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写。是 CAP 定理对于一致性与可用性权衡的结果。

BASE 理论的核心思想是：即使无法做到强一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

• （1） 基本可用
  基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
  • 响应时间的损失：例如百度大楼，只剩一栋大楼，其他大楼都停电了，那百度响应给我们的时间就会变慢，原来是0.5秒现在是2秒，损失了响应时间，也能接受。
  • 功能上的损失：例如双11，淘宝支付功能能用，但是修改收货地址、查看历史订单不能用，牺牲了一些不重要的功能，保证了重要的功能，这就是服务降级。
• （2） 软状态
  软状态，是指允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统主机间进行数据同步的过程存在一定延时。软状态，其实就是一种灰度状态，过渡状态。
• （3） 最终一致性
  最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

ZK 与 CP

zk 遵循的是 CP 原则，即保证了一致性，但牺牲了可用性。体现在哪里呢？

当 Leader 宕机后，zk 集群会马上进行新的 Leader 的选举。但选举时长一般在 200 毫秒内，最长不超过 60 秒，整个选举期间 zk 集群是不接受客户端的读写操作的，即 zk 集群是处于瘫痪状态的。所以，其不满足可用性。

不仅是选举，客户端提交事务请求后，并且通过后，首先Leader更新，然后其他Follower要从Leader同步数据，同步过程集群对外也是不提供服务的，只是同步过程比较快，再快也是有时间的，在这时间范围内对外是不提供服务的。就是因为没有同步完成，对外就不提供服务。保证了能读到数据的时候，数据一定是一致的。

zookeeper在Dubbo里面是做注册中心的，Eureka在Spring Cloud里面也是做注册中心的。
Eureka 保证了 AP，牺牲了 CP。即其保证了可用性，但无法保证一致性。

zk 可能会存在脑裂

这里说的 zk 可能会引发脑裂，是指的在多机房部署中，若出现了网络连接问题，形成多个分区，则可能会出现脑裂问题，可能会导致数据不一致。


Leader 的主动出让原则，如果A发现丢失了大部分Follower，状态就由LEADING变为LOOKING，寻找新的Leader
所以脑裂是短暂的，但是脑裂的过程中还是会出现数据不一致的情况。