长沙seo研究中心,优化产业结构,装wordpress需要配置apache,wordpress dnsZooKeeper 是 Apache 的一个顶级项目#xff0c;为分布式应用提供高效、高可用的分布式协调服务#xff0c;提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性#xff0c… ZooKeeper 是 Apache 的一个顶级项目为分布式应用提供高效、高可用的分布式协调服务提供了诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知和分布式锁等分布式基础服务。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的稳定性被广泛地应用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。 本文的目标读者是对 ZooKeeper 有一定了解的技术人员将从 ZooKeeper 运行模式、集群组成、容灾和水平扩容四方面逐步深入最终构建出高可用的 ZooKeeper 集群。 运行模式 Zookeeper 有三种运行模式单机模式、伪集群模式和集群模式。 单机模式 这种模式一般适用于开发测试环境一方面我们没有那么多机器资源另外就是平时的开发调试并不需要极好的稳定性。 在 Linux 环境下运行单机模式需要执行以下步骤 1. 准备 Java 运行环境 安装 Java 1.6 或更高版本的 JDK并配置好 Java 相关的环境变量 $JAVA_HOME 。 2. 下载 ZooKeeper 安装包 下载地址http://zookeeper.apache.org/releases.html。选择最新的 stable 版本并解压到指定目录我们用 $ZK_HOME 表示该目录。 3. 配置 zoo.cfg 首次使用 ZooKeeper需要将 $ZK_HOME 下的 zoo_sample.cfg 文件重命名为 zoo.cfg并进行以下配置 tickTime2000 ##Zookeeper最小时间单元单位毫秒(ms)默认值为3000
dataDir/var/lib/zookeeper ##Zookeeper服务器存储快照文件的目录必须配置dataLogDir/var/lib/log ##Zookeeper服务器存储事务日志的目录默认为dataDir
clientPort2181 ##服务器对外服务端口一般设置为2181
initLimit5 ##Leader服务器等待Follower启动并完成数据同步的时间默认值10表示tickTime的10倍
syncLimit2 ##Leader服务器和Follower之间进行心跳检测的最大延时时间默认值5表示tickTime的5倍 4. 启动服务 使用 $ZK_HOME/bin 目录下的 zkServer.sh 脚本进行服务的启动。 集群模式 一个 ZooKeeper 集群通常由一组机器组成一般 3 台以上就可以组成一个可用的 ZooKeeper 集群了。 组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态并且每台机器之间都会互相保持通信。重要的一点是只要集群中存在超过一半的机器能够正常工作那么整个集群就能够正常对外服务。 ZooKeeper 的客户端程序会选择和集群中的任意一台服务器创建一个 TCP 连接而且一旦客户端和服务器断开连接客户端就会自动连接到集群中的其他服务器。 那么如何运行 ZooKeeper 集群模式呢首先假如我们有三台服务器IP 分别为 IP1、IP2 和 IP3则需要执行以下步骤 1. 准备 Java 运行环境同上 2. 下载 ZooKeeper 安装包同上 3. 配置 zoo.cfg tickTime2000
dataDir/var/lib/zookeeper
dataLogDir/var/lib/log
clientPort2181
initLimit5
syncLimit2
server.1IP1:2888:3888
server.2IP2:2888:3888
server.3IP3:2888:3888 可以看到相比于单机模式集群模式多了 server.idhost:port1:port2 的配置。其中id 被称为 Server ID用来标识该机器在集群中的机器序号在每台机器的 dataDir 目录下创建 myid 文件文件内容即为该机器对应的 Server ID 数字。host 为机器 IPport1 用于指定 Follower 服务器与 Leader 服务器进行通信和数据同步的端口port2 用于进行 Leader 选举过程中的投票通信。 4. 创建 myid 文件 在 dataDir 目录下创建名为 myid 的文件在文件第一行写上对应的 Server ID。 5. 按照相同步骤为其他机器配置 zoo.cfg 和 myid文件 6. 启动服务 伪集群模式 这是一种特殊的集群模式即集群的所有服务器都部署在一台机器上。当你手头上有一台比较好的机器如果作为单机模式进行部署就会浪费资源这种情况下ZooKeeper允许你在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例以此来以集群的特性来对外服务。 这种模式下只需要把 zoo.cfg 做如下修改 tickTime2000
dataDir/var/lib/zookeeper
dataLogDir/var/lib/log
clientPort2181
initLimit5
syncLimit2
server.1IP1:2888:3888
server.2IP1:2889:3889
server.3IP1:2890:3890 集群组成 要搭建一个高可用的 ZooKeeper 集群我们首先需要确定好集群的规模。关于 ZooKeeper 集群的服务器组成相信很多对 ZooKeeper 了解但是理解不够深入的读者都存在或曾经存在过这样一个错误的认识为了使得 ZooKeeper 集群能够顺利地选举出 Leader必须将 ZooKeeper 集群的服务器数部署成奇数。这里我们需要澄清的一点是任意台 ZooKeeper 服务器都能部署且能正常运行。 那么存在于这么多读者中的这个错误认识是怎么回事呢其实关于 ZooKeeper 集群服务器数ZooKeeper 官方确实给出了关于奇数的建议但绝大部分 ZooKeeper 用户对于这个建议认识有偏差。在本书前面提到的“过半存活即可用”特性中我们已经了解了一个 ZooKeeper 集群如果要对外提供可用的服务那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。基于这个特性如果想搭建一个能够允许 N 台机器 down 掉的集群那么就要部署一个由 2*N1 台服务器构成的 ZooKeeper 集群。因此一个由 3 台机器构成的 ZooKeeper 集群能够在挂掉 1 台机器后依然正常工作而对于一个由 5 台服务器构成的 ZooKeeper 集群能够对 2 台机器挂掉的情况进行容灾。注意如果是一个由6台服务器构成的 ZooKeeper 集群同样只能够挂掉 2 台机器因为如果挂掉 3 台剩下的机器就无法实现过半了。 因此从上面的讲解中我们其实可以看出对于一个由 6 台机器构成的 ZooKeeper 集群来说和一个由 5 台机器构成的 ZooKeeper 集群其在容灾能力上并没有任何显著的优势反而多占用了一个服务器资源。基于这个原因ZooKeeper 集群通常设计部署成奇数台服务器即可。 容灾 所谓容灾在 IT 行业通常是指我们的计算机信息系统具有的一种在遭受诸如火灾、地震、断电和其他基础网络设备故障等毁灭性灾难的时候依然能够对外提供可用服务的能力。 对于一些普通的应用为了达到容灾标准通常我们会选择在多台机器上进行部署来组成一个集群这样即使在集群的一台或是若干台机器出现故障的情况下整个集群依然能够对外提供可用的服务。 而对于一些核心应用不仅要通过使用多台机器构建集群的方式来提供服务而且还要将集群中的机器部署在两个机房这样的话即使其中一个机房遭遇灾难依然能够对外提供可用的服务。 上面讲到的都是应用层面的容灾模式那么对于 ZooKeeper 这种底层组件来说如何进行容灾呢讲到这里可能多少读者会有疑问ZooKeeper 既然已经解决了单点问题那为什么还要进行容灾呢 单点问题 单点问题是分布式环境中最常见也是最经典的问题之一在很多分布式系统中都会存在这样的单点问题。具体地说单点问题是指在一个分布式系统中如果某一个组件出现故障就会引起整个系统的可用性大大下降甚至是处于瘫痪状态那么我们就认为该组件存在单点问题。 ZooKeeper 确实已经很好地解决了单点问题。我们已经了解到基于“过半”设计原则ZooKeeper 在运行期间集群中至少有过半的机器保存了最新的数据。因此只要集群中超过半数的机器还能够正常工作整个集群就能够对外提供服务。 容灾 解决了单点问题是不是该考虑容灾了呢答案是否定的在搭建一个高可用的集群的时候依然需要考虑容灾问题。正如上面讲到的如果集群中超过半数的机器还在正常工作集群就能够对外提供正常的服务。那么如果整个机房出现灾难性的事故这时显然已经不是单点问题的范畴了。 在进行 ZooKeeper 的容灾方案设计过程中我们要充分考虑到“过半原则”。也就是说无论发生什么情况我们必须保证 ZooKeeper 集群中有超过半数的机器能够正常工作。因此通常有以下两种部署方案。 双机房部署 在进行容灾方案的设计时我们通常是以机房为单位来考虑问题。在现实中很多公司的机房规模并不大因此双机房部署是个比较常见的方案。但是遗憾的是在目前版本的 ZooKeeper 中还没有办法能够在双机房条件下实现比较好的容灾效果——因为无论哪个机房发生异常情况都有可能使得 ZooKeeper 集群中可用的机器无法超过半数。当然在拥有两个机房的场景下通常有一个机房是主要机房一般而言公司会花费更多的钱去租用一个稳定性更好、设备更可靠的机房这个机房就是主要机房而另外一个机房则更加廉价一些。我们唯一能做的就是尽量在主要机房部署更多的机器。例如对于一个由 7 台机器组成的 ZooKeeper 集群通常在主要机房中部署 4 台机器剩下的 3 台机器部署到另外一个机房中。 三机房部署 既然在双机房部署模式下并不能实现好的容灾效果那么对于有条件的公司选择三机房部署无疑是个更好的选择无论哪个机房发生了故障剩下两个机房的机器数量都超过半数。假如我们有三个机房可以部署服务并且这三个机房间的网络状况良好那么就可以在三个机房中都部署若干个机器来组成一个 ZooKeeper 集群。 我们假定构成 ZooKeeper 集群的机器总数为 N在三个机房中部署的 ZooKeeper 服务器数分别为 N1、N2 和 N3如果要使该 ZooKeeper 集群具有较好的容灾能力我们可以根据如下算法来计算 ZooKeeper 集群的机器部署方案。 1. 计算 N1 如果 ZooKeeper 集群的服务器总数是 N那么 N1 (N-1)/2 在 Java 中“/” 运算符会自动对计算结果向下取整操作。举个例子如果 N8那么 N13如果 N7那么 N1 也等于 3。 2. 计算 N2 的可选值 N2 的计算规则和 N1 非常类似只是 N2 的取值是在一个取值范围内 N2 的取值范围是 1~(N-N1)/2 即如果 N8那么 N13则 N2 的取值范围就是 1~2分别是 1 和 2。注意1 和 2 仅仅是 N2 的可选值并非最终值——如果 N2 为某个可选值的时候无法计算出 N3 的值那么该可选值也无效。 3. 计算 N3同时确定 N2 的值 很显然现在只剩下 N3 了可以简单的认为 N3 的取值就是剩下的机器数即 N3 N - N1 - N2 只是 N3 的取值必须满足 N3 N1N2。在满足这个条件的基础下我们遍历步骤 2 中计算得到的 N2 的可选值即可得到三机房部署时每个机房的服务器数量了。 现在我们以 7 台机器为例来看看如何分配三机房的机器分布。根据算法的步骤 1我们首先确定 N1 的取值为 3。根据算法的步骤 2我们确定了 N2 的可选值为 1 和 2。最后根据步骤 3我们遍历 N2 的可选值即可得到两种部署方案分别是 (3,1,3) 和 (3,2,2)。以下是 Java 程序代码对以上算法的一种简单实现 public class Allocation { static final int n 7; public static void main(String[] args){ int n1,n2,n3;n1 (n-1) / 2; int n2_max (n-n1) / 2; for(int i1; in2_max; i){n2 i;n3 n - n1 -n2; if(n3 (n1n2)){ continue;}System.out.println((n1,n2,n3));}}
} 水平扩容 水平可扩容可以说是对一个分布式系统在高可用性方面提出的基本的也是非常重要的一个要求通过水平扩容能够帮助系统在不进行或进行极少改进工作的前提下快速提高系统对外的服务支撑能力。简单地讲水平扩容就是向集群中添加更多的机器以提高系统的服务质量。 很遗憾的是ZooKeeper 在水平扩容扩容方面做得并不十分完美需要进行整个集群的重启。通常有两种重启方式一种是集群整体重启另外一种是逐台进行服务器的重启。 整体重启 所谓集群整体重启就是先将整个集群停止然后更新 ZooKeeper 的配置然后再次启动。如果在你的系统中ZooKeeper 并不是个非常核心的组件并且能够允许短暂的服务停止通常是几秒钟的时间间隔那么不妨选择这种方式。在整体重启的过程中所有该集群的客户端都无法连接上集群。等到集群再次启动这些客户端就能够自动连接上——注意整体启动前建立起的客户端会话并不会因为此次整体重启而失效。也就是说在整体重启期间花费的时间将不计入会话超时时间的计算中。 逐台重启 这种方式更适合绝大多数的实际场景。在这种方式中每次仅仅重启集群中的一台机器然后逐台对整个集群中的机器进行重启操作。这种方式可以在重启期间依然保证集群对外的正常服务。 参考文章《从Paxos到Zookeeper 分布式一致性原理与实践》 原文链接http://www.cnblogs.com/cyfonly/p/5626532.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
