ZooKeeper的实践(一):ZooKeeper仲裁机制

ZooKeeper仲裁机制

  • 概述
    • 仲裁
      • 深入分析节点的数量问题
  • 总结

概述

zk服务器运行模式分成两种:

  • 独立模式
  • 仲裁模式
    如果是用独立模式(standalone),则zk的状态是无法进行复制的,这才生产环境中,会造成一定的风险,事实上,我们确实有这种情况存在,这源于初期架构的思考和公司经济的问题。而在仲裁(quorun)模式下,则是我们当前流行的分布式集群,我们称之为集合。是用仲裁,不仅可以进行状态的复制,也可以同时服务于客户端的请求。

仲裁

采用仲裁方式的复制集群中,由于具备高可用的镜像复写功能,如果客户端需要等待每个服务器完成数据的螺钉后在继续,则延时的问题会变得比较突出,要知道,延时,在大流量的访问中,是不可接收的,但不代表能消灭延时。
此时,在ZK的设计思路中,为了规避这个问题,则衍生除了法定人数的思想,即我们只需要保证我们的集群中,由若干算法模式下实现的人数能完成对应的信息落地之后,则认为客户端可以继续下一波的操作,而不是等到所有集群完全落实才继续下去。例如,我们由5个zk服务器,而法定人数为3人,则我们只需要确保其中的3台服务器保存了对应的数据,客户端就可以继续,而其他两个服务器在正常的中状态下,最终也是能获取到数据,并保存下来

这就是为什么我们要求zk的部署,起码是奇数台的其中一个原因。
请注意,假设我们由f个服务器,则允许其崩溃的数据必须小于服务器数量的一半,即5台,只能允许2台崩溃。

深入分析节点的数量问题

查阅了一些书籍和文档,其实并没有过多的阐述为什么,服务器的数量必须在奇数台或者在偶数台的情况下,为什么不行,事实上并不是认为偶数台不允许部署,而是,作为偶数台的部署,风险性会更大而已
为了避免脑裂,我们在上述的例子中,规定法定人数为3,实际上是至少为3,即集合中的5个服务器的多数原则,为了正常工作,集合中则必须至少有3台服务器是能正常运营的。为了能确保一个请求对状态的更新是否成功,则必须保证以上的3台能确认已经完成了数据复制操作。一次,如果要保证集合可以正常工作,对任何更新操作的完成,我们只好要有1个有效的服务器来保存更新的副本(至少在一个节点上合理的法定人数存在交集)。
假设集合中只有4台服务器,那么多数原则对应的的数量为3个服务器,但是,这集群中只允许1个服务器崩溃,因为两个服务器崩溃就会导致系统丧失多数原则的状态,因此,在4个服务器的情况下,我们仅能允许一个服务器崩溃,而法定人数现在却更大,意味着,对每个请求,我们需要更多的确认操作,底线是,我们需要争取奇数个服务器。

总结

不管出于何种原因,由于zk的重要性,在项目中,一旦使用了zk,建议是用仲裁的机制进行运作,单点故障的情形,往往带来的业务的深度影响。

你可能感兴趣的:(BigData)