我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:老奇人论坛一平特肖 > 单点 >

通常我们会选择在多台机器上进行部署来组成一个集群

归档日期:08-05       文本归类:单点      文章编辑:爱尚语录

  对于一些普通的应用,为了达到容灾标准,通常我们会选择在多台机器上进行部署来组成一个集群,这样即使在集群的一台或是若干台机器出现故障的情况下,整个集群依然能够对外提供可用的服务。

  由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性,被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。

  在进行 ZooKeeper 的容灾方案设计过程中,我们要充分考虑到“过半原则”。也就是说,无论发生什么情况,我们必须保证 ZooKeeper 集群中有超过半数的机器能够正常工作。因此,通常有以下两种部署方案。

  其中,id 被称为 Server ID,用来标识该机器在集群中的机器序号(在每台机器的 dataDir 目录下创建 myid 文件,文件内容即为该机器对应的 Server ID 数字)。

  本文的目标读者是对 ZooKeeper 有一定了解的技术人员,将从 ZooKeeper 运行模式、集群组成、容灾和水平扩容四方面逐步深入,最终构建出高可用的 ZooKeeper 集群。

  在进行容灾方案的设计时,我们通常是以机房为单位来考虑问题。在现实中,很多公司的机房规模并不大,因此双机房部署是个比较常见的方案。

  所谓容灾,在 IT 行业通常是指我们的计算机信息系统具有的一种在遭受诸如火灾、地震、断电和其他基础网络设备故障等毁灭性灾难的时候,依然能够对外提供可用服务的能力。

  在 Java 中,“/” 运算符会自动对计算结果向下取整操作。举个例子,如果 N=8,那么 N1=3;如果 N=7,那么 N1 也等于 3。

  ZooKeeper 确实已经很好地解决了单点问题。我们已经了解到,基于“过半”设计原则,ZooKeeper 在运行期间,集群中至少有过半的机器保存了最新的数据。因此,只要集群中超过半数的机器还能够正常工作,整个集群就能够对外提供服务。

  上面讲到的都是应用层面的容灾模式,那么对于 ZooKeeper 这种底层组件来说,如何进行容灾呢?讲到这里,可能多少读者会有疑问,ZooKeeper 既然已经解决了单点问题,那为什么还要进行容灾呢?

  注意,如果是一个由6台服务器构成的 ZooKeeper 集群,同样只能够挂掉 2 台机器,因为如果挂掉 3 台,剩下的机器就无法实现过半了。

  只是 N3 的取值必须满足 N3 N1+N2。在满足这个条件的基础下,我们遍历步骤 2 中计算得到的 N2 的可选值,即可得到三机房部署时每个机房的服务器数量了。

  在整体重启的过程中,所有该集群的客户端都无法连接上集群。等到集群再次启动,这些客户端就能够自动连接上——注意,整体启动前建立起的客户端会话,并不会因为此次整体重启而失效。也就是说,在整体重启期间花费的时间将不计入会话超时时间的计算中。

  我们唯一能做的,就是尽量在主要机房部署更多的机器。例如,对于一个由 7 台机器组成的 ZooKeeper 集群,通常在主要机房中部署 4 台机器,剩下的 3 台机器部署到另外一个机房中。

  这种模式一般适用于开发测试环境,一方面我们没有那么多机器资源,另外就是平时的开发调试并不需要极好的稳定性。

  很显然,现在只剩下 N3 了,可以简单的认为 N3 的取值就是剩下的机器数,即:

  关于 ZooKeeper 集群的服务器组成,相信很多对 ZooKeeper 了解但是理解不够深入的读者,都存在或曾经存在过这样一个错误的认识:为了使得 ZooKeeper 集群能够顺利地选举出 Leader,必须将 ZooKeeper 集群的服务器数部署成奇数。这里我们需要澄

本文链接:http://canfilmi.com/dandian/741.html