ZooKeeper理论基础(二)容灾、CAP定理、脑裂
高可用集群的容灾
服务器数量的奇数与偶数
前面我们说过,无论是写操作投票,还是 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 是 B
asically A
vailable(基本可用)、S
oft state(软状态)和 E
ventually 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
所以脑裂是短暂的,但是脑裂的过程中还是会出现数据不一致的情况。