Zookeeper 一致性和多数据中心部署

一致性的定义

最终一致性

最终一致性,是BASE理论提出来的,好多系统分布式系统为了强调可用性,从而弱化一致性,通过最终一致性来满足,那多长时间能达到最终一致呢,这就有一个不一致的时间窗口(Inconsistency Window)。

顺序一致性

顺序一致性是保证下次读到的值,肯定不会比本次读到的版本要旧,即,肯定读到新的值。

Zookeeper 一致性的精确定义

zookeeper 是一个顺序一致性的实现,zookeeper 保证不会读到比上次更老的版本,因为zookeeper client 会携带一个事物id,如果链接断开,连上了没有同步的那台机器,这台server 会比较客户端当前携带的事物id,如果大于,则会和leader 同步。顺序一致性的解释和原理,请看饿了么的团队写的文章:https://mp.weixin.qq.com/s/4NtdY6nEBi173Ya4yHWy2g

Zookeeper 多数据中心部署

现在满多互联网公司说实现多活,多活面临的一个基本问题是,服务协调和通信而且是在跨地域跨数据中心的情况下,解决网络延迟和数据一致的问题,下面我们看下zookeeper 跨多Data Center 部署方案

单个zookeeper 集群

单个集群即zookeeper的acceptor节点部署在多个区域,保证数据一致性。

则种部署方式能完全保证可用性,不回出现单点,但是在commit 投票时,都需要跨地域操作,不可避免的要面对网络延迟和带宽的开销,即更新操作就比较慢了,想想假如在北京和上海两个数据中心,更新操作commit 投票时一个请求就要30ms的延迟。

Acceptors 和 learner 分开部署

这种部署方式是acceptor 部署在一个集群负责投票和选举。learner 分别部署在其他的数据中心,负责同步数据,这样能减少更新操作时的网络延迟,因为都在一个数据中心通信,网络和带宽没有问题,但是写吞吐量受到了单个Acceptors集群的限制,在远程数据中心的更新回有很大的延迟,以及还有单点问题。

多个zookeeper 集群

这种模式是一个地区一个zookeeper集群,learner分别部署在异地, 比如上海和北京都部署一个,上海的zookeeper 集群的learner 部署在北京,北京的learner部署在上海,这种部署的方式的好处是多个数据中心可以并行处理请求,吞吐量高,而且一个数据中心出现故障,其他的不回受影响,单是这种方案有一个一致性的问题,在并发更新而且从异地数据中心读另外一个更新的数据时,

多zookeeper 集群 而且保证一致性的方案

Modular composition

基于上面三种方案的优缺点,Modular Composition of Coordination Services 这篇论文提供了一个解决方案,他们对zookeeper 的server 端的一个组件commit processor做了修改,并提供了一个waper的client ,并且提供了batch for zookeeper,zookeeper社区在3.6版本回合并进来,主要实现如下两个关键改进:

服务端

服务端通过隔离每个客户端的请求,来增加吞吐量,目前zookeeper的commit processor 实现是为所有的客户端请求维持一个队列,这样不同的客户端更新也有等前面的请求完成2PC后才能进入后面的处理。

客户端

客户端通过对zk client的包装,可以链接多个zookeeper 集群,具体请参考相关的论文。

总结

zookeeper 多数据中心部署方案的比较

方案写性能读性能一致性语义可用性写可用性读
单个zookeeper集群非常慢正确大多数所有节点
Learners 方案正确Acceptors所有节点
多个zookeeper集群回出现不一致Local所有节点
改造方案正确LocalLocal
    原文作者:绝尘驹
    原文地址: https://www.jianshu.com/p/43c17bb12b62
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞