后使用快捷导航没有帐号？
zookeeper 运营经验分享
查看: 20941|
评论: 0|来自: 腾讯大数据
摘要: Zookeeper作为TDBank系统的一个重要模块，我们运营它已经两年多。在使用过程中，我们也遇到了一些问题及走过很多弯路，本文主要对zookeeper运营经验进分享。Zookeeper在TDBank中的使用场景TDBank主要利用zookeeper实 ...
Zookeeper作为TDBank系统的一个重要模块，我们运营它已经两年多。在使用过程中，我们也遇到了一些问题及走过很多弯路，本文主要对zookeeper运营经验进分享。Zookeeper在TDBank中的使用场景TDBank主要利用zookeeper实现配置管理、配置更新通知、节点主备容灾、节点心跳管理等。使用到的模块包括消息中间件Tube、流式处理平台、分拣中心TDSort及配置管理中心TDManager，各模块利用zookeeper的功能如下Tube我们利用zookeeper实现Tube的master进行主、备容灾，实现master的高可用性；另外，利用zookeeper保存各消费者的消费offset信息；StormStorm的所有的状态信息都是保存在Zookeeper里面，nimbus通过在zookeeper上面写状态信息来分配任务，supervisor，task通过从zookeeper中读状态来领取任务，同时supervisor, task也会定义发送心跳信息到zookeeper，使得nimbus可以监控整个storm集群的状态，从而可以重启一些挂掉的task。ZooKeeper 使得整个storm集群十分的健壮，任何一台工作机器挂掉都没有关系，只要重启然后从zookeeper上面重新获取状态信息就可以了。TDSort和TDManagerTManager和TDSort通过zookeeper实现配置的共享和配置更新的通知。TDManager定时将业务配置写入zookeeper，TDSort将从zookeeper中读取业务配置并对数据进行分拣。当TDManager对业务配置更新后，它同样通过zookeeper通知TDSort更新内存中的配置。通过zookeeper，TDBank实现几千个分拣进程共享配置。Zookeeper部署为了确保ZooKeeper服务的稳定与可靠性，我们通常是将zk搭建成一个集群来对外提供服务，因此这里主要介绍zk集群的部署。Zookeeper集群有一个很重要的特性：集群中的zk节点只要有过半存活，集群就能正常工作。基于这个特性，建议将ZK集群的机器数量控制为奇数较为合适。当集群的机器个数是3个时，允许最多一台机器宕机；当集群的机器个数是5个时，最多允许2台机器同时宕机，以此类推……当然，并不是机器个数越多越好，机器越多虽然可以提供集群的吞吐量，但是带来的代价是一致性同步时间更长，大家可以根据业务的特性来确定机器的个数。TDBank的业务场景既要吞吐量，也需要一致性同步耗时短，因此我们使用5台机器搭建集群。确定机器的个数后，我们下一步需要选择机型和机器。我们建议选择含有多块硬盘的机型，这样可以把zookeeper的数据文件和事务日志分别放存到不同的盘，以免两者抢占IO，影响zookeeper节点工作。对于机器，如果条件允许，建议选择的zookeeper机器分布在不同机架，选择不同机架是为了防止机架掉电造成zk服务中断。如果条件允许，也可尝试跨机房部署，多个机房同时发生故障的机率会更小的，但跨机房需要考虑网络质量，包括网络延时及IDC中断等情况。TDBank综合自身场景，选择了公司的TS4机型，TS4使用的方法：将11块盘中10块拆成两组，每组5块盘，分别作软raid10，将数据文件和事务日志分别放存到不同的raid10组中；我们的机器分布在同一个机房的5个不同机架。Zookeeper集群的搭建步骤包括如下：1、安装JDK，配置环境，执行java –version和javac –version命令来确定环境是否OK；2、选择合适的zookeeper版本，并把对应的包上传到各台机器；http://www.apache.org/dyn/closer.cgi/zookeeper/3、在各台zookeeper的conf目录下建立一个zoo.conf，在同一个集群中，各台机器的zoo.conf内容一致，内容示例如下备注：/data0和/data1分别属于不同的挂载点；zoo1至zoo5分别为5台不同的zookeeper机器，建议使用域名，更方便维护；集群中的每台机器都需要感知整个集群是由哪几台机器组成的，在配置文件中，可以按照这样的格式，每行写一个机器配置：server.id=host:port:port. 关于这个id，我们称之为Server ID，标识host机器在集群中的机器序号4、在每台机器建立dataDir和dataLogDir目录，同时在每台机器的dataDir下建立文件myid，文件的内容为配置1,2,3,4…，具体值跟上面提到的ServerID一致，例子中的zoo1机器中的myid内容为1，zoo5机器中的myid内容为55、至此，配置已完成，接下来逐台启动zookeeper进程，进入%ZK_HOME%/bin，执行./zkServer.sh start6、验证是否启动成功，进入%ZK_HOME%/bin，执行下面命令，就可以连接上zookeeper；./zkCli.sh当然，也可以使用下面命令快速确定节点的状态echo stat|netcat localhost 2181Zookeeper监控对于zookeeper的监控，我们可以使用zk提供的4字命令返回的内容进行解析监控当然，你也可以使用淘宝的开源工具TaoKeeper进行监控。Zookeeper的监控包括下面几个方面：1、机器的CPU、内存、负载、硬盘IO利用率等基础监控，这些均可以网管系统实现；2、ZK日志目录所在磁盘空间监控，这可以针对性的监控；3、各节点的进程监控，配置自动拉起等；4、各节点的连接数监控，配置峰值告警；5、各节点的Watcher数监控，配置峰值告警；6、使用四字命令，对每个节点进行检查，确保进程不僵死；7、节点存活个数监控；Zookeeper数据及日志维护Zookeeper的数据文件存放在配置中指定的dataDir中，每个数据文件名都以snapshot开头，每个数据文件为zookeeper某个时刻数据全量快照。在zookeeper中，对数据的更新操作，包括创建节点、更新节点内容、删除节点都会记录事务日志，zookeeper在完成若干次事务日志（snapCount）后会生成一次快照，把当前zk中的所有节点的状态以文件的形式dump到硬盘中，生成一个snapshot文件。这里的事务次数是可以配置，默认是100000个。Zookeeper的日志包括两个部分，一部分是系统日志，另一部分是事务日志。系统日志使用log4j进行管理，conf目录中有一个log4j配置文件，该配置文件默认没有打开滚动输出，需要用户自己配置，具体请参看log4j介绍。事务日志默认存放在dataDir中，当然可以使用dataLogDir指定存放的位置。正常运行过程中，针对所有更新操作，在返回客户端“更新成功”的响应前，ZK会确保已经将本次更新操作的事务日志写到磁盘上，只有这样，整个更新操作才会生效。每触发一次数据快照，就会生成一个新的事务日志。默认情况下，zk不会自动清理数据文件和日志文件，因此需要管理员自己清理。我们可以使用ZK的工具类PurgeTxnLog进行清理，当然，我们也可以写脚本自己维护，同时可以使用工具慢慢清理，避免占用大量IO。清理脚本如下：务必注意：如果长时间不清理，切忌同一时间使用rm命令同时删除大量文件，这样会造成IO利用率瞬间飙升，zookeeper的连接会出现断连或session超时，影响现网业务使用。另外，对于每一个数据文件，它都是某一时刻的完整快照，我们可以定时将该文件备份，方便对数据进行还原或将zookeeper直接迁移到另外一个集群。Zookeeper常用命令命令行下连接zookeeperbin/zkCli.sh -server zoo1:2181,zoo2:2181,zoo3:2181,zoo4:2181,zoo5:2181查看子节点ls /创建节点create /node data删除节点delete /node设置节点值，set /node data1命令行下连接zookeeper并将结果打印到控制台bin/zkCli.sh -server zoo1:2181,zoo2:2181,zoo3:2181,zoo4:2181,zoo5:2181 get /data/test常用的四字命令四字命令的用法为echo 四字命令|netcat localhost 2181例如输出server的配置信息echo conf|netcat localhost 2181Zookeeper优化建议对于zookeeper的优化，有下面几点建议：1、将zookeeper与其他应用分开部署，避免相互影响；对于zookeeper来说，如果在运行过程中，需要和其它应用程序来竞争磁盘、CPU、网络、内存资源，那么整体性能将会大打折扣。我们在使用zookeeper初期尝试将zookeeper与其他应用公用机器，在系统流量上涨后，由于IO及CPU被其他应用使用很大，造成zookeeper的session经常超时甚至应用与zookeeper的连接断开。因此，建议zookeeper与其他应用分开部署；2、将数据文件和事务日志分开存放，提高zookeeper性能；我们先分析一下磁盘对zookeeper性能的影响。客户端对ZK的更新操作都是永久的，不可回退的。为做到这点，ZK会将每次更新操作以事务日志的形式写入磁盘，写入成功后才会给予客户端响应。明白这点之后，你就会明白磁盘的吞吐性能对于ZK的影响了，磁盘写入速度制约着ZK每个更新操作的响应。因此，我们在选择机型时尽量选择多块硬盘的机器，ZK的事务日志输出是一个顺序写文件的过程，本身性能是很高的，所以尽量保证不要和其它随机写的应用程序共享一块磁盘，尽量避免对磁盘的竞争。3、尽量避免内存与磁盘空间的交换，确保设置一个合理的JVM堆大小；如果设置太大，会让内存与磁盘进行交换，这将使ZK的性能大打折扣。例如一个4G内存的机器的，如果你把JVM的堆大小设置为4G或更大，那么会使频繁发生内存与磁盘空间的交换，通常设置成3G就可以了。
刚表态过的朋友 ()
上一篇：下一篇：双鱼座小龙 的BLOG
用户名：双鱼座小龙
文章数：104
评论数：204
访问量：158039
注册日期：
阅读量：5863
阅读量：12276
阅读量：414472
阅读量：1102072
51CTO推荐博文
& 部署一个zookeeper集群，要多简单就能有多简单（下载压缩包，解压，修改配置文件zoo.cfg,执行启动脚本），但是想要真的把这套东西玩好了，还是需要费些功夫研究一番的。就跟自己搭建一个lnmp的站点，仅仅搭建，网上有各种教程和专门的一键安装包，但是部署后，根据实际场景需求和系统负载进行配置优化时，我们就需要了解一些与lnmp相关的知识了。 & & &目前，我们业务应用是通过配置中心集中管理应用各种配置的，管理中心应用到了zookeeper集群推送配置信息，研究下zookeeper的leader选举，数据更新同步的知识还是有收获的。 & zookeeper集群主要用来解决分布式集群中应用系统的一致性问题，应用场景目前接触到的主要就是两种：同步锁和配置管理。zookeeper集群的部署：环境：操作系统版本：lsb_release -aDescription: & &CentOS release 6.3 (Final)Linux zookeeper01.nh 2.6.32-279.el6.x86_64 &x86_64 x86_64 x86_64 GNU/Linuxzookeeper版本：zookeeper-3.4.5配置文件： 目录：/data/webapps/zookeeper/conf &配置详情：less zoo.cfg# The number of milliseconds of each ticktickTime=2000 #CS通信心跳数，服务器之间或客户端与服务器之间间隔多久发送一个心跳#tickTime以毫秒为单位。# The number of ticks that the initial # synchronization phase can takeinitLimit=10#initLimit：Leader与Follower初始通信时限#集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）。# The number of ticks that can pass between # sending a request and getting an acknowledgementsyncLimit=5#syncLimit：Leader与Follower同步通信时限#集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。# 3.4.0 版本后引入了数据自动清理功能autopurge.purgeInterval=1 (zookeeper自动清理间隔，单位小时)autopurge.snapRetainCount=10 （保留快照文件个数）# the directory where the snapshot is stored.dataDir=/data/appdatas/zookeeperZookeeper保存数据的目录，默认情况下，Zookeeper将写数据的日志文件也保存在这个目录里。#commitLog数据存储dataLogDir=/data/applogs/zookeeperZookeeper保存日志文件的目录。# the port at which the clients will connectclientPort=2181#客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。# znode#zookeeper 集群信息（服务器编号，服务器地址，Leader与Follower通信端口，选举端口）#选举端口，表示选举新leader时服务器间相互通信的端口（当leader挂掉时，其余服务器会相互通信，选择出新的leader）server.1（myid文件，dataDir目录中）=101.1.2.132: #servers making up the ZooKeeper ensemble. When the server starts up, it determines which server it is by looking for the file myid in the data directory. That file contains the server number, in ASCII, and it should match x in server.x in the left hand side of this setting.server.2=101.1.2.137: server.3=101.1.2.162:server.4=101.1.2.167: server.5=101.1.2.158:详细配置说明参看：https://zookeeper.apache.org/doc/trunk/zookeeperAdmin.html#sc_advancedConfiguration保证zookeeper持续提供服务daemontools ：安装方法： & & mkdir -p /package & & chmod 1755 /package & & cd /package & & wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz & & tar -zxvf daemontools-0.76.tar.gz & & cd admin/daemontools-0.76 & & package/install创建目录：/service/zookeeper# 创建文件 run #!/bin/bash
. /etc/profile
exec /data/webapps/zookeeper/bin/zkServer.sh start-foreground启动：supervise &zookeeper &&supervise就会在后台监控zookeeper的进程，如果zookeeper进程被意外关闭，supervise进程会立即执行run文件中的命令，重启启动zookeeper。zookeeper监控：taokeeper, ZooKeeper-Monitor, a monitor for zookeeper in java官方地址：taokeeper相关截图：zabbix相关模版截图：zabbix agent相关检测配置：UserParameter=zk_version, echo stat | nc 127.0.0.1 2181 |grep version | awk -F ":" '{print $2}'UserParameter=zk_received, echo stat | nc 127.0.0.1 2181 |grep Received | awk -F ":" '{print $2}'UserParameter=zk_sent, echo stat | nc 127.0.0.1 2181 |grep Sent | awk -F ":" '{print $2}'UserParameter=zk_mode, echo stat | nc 127.0.0.1 2181 |grep Mode | awk -F ":" '{print $2}'UserParameter=zk_nodecount, &echo stat | nc 127.0.0.1 2181 |grep 'Node count'| awk -F ":" '{print $2}'UserParameter=zk_clientscount, & &echo cons | nc 127.0.0.1 2181 |grep -v '127.0.0.1' |wc -lUserParameter=zk_status, & &echo ruok | nc 127.0.0.1 2181 UserParameter=zk_aclient, & &echo cons | nc 127.0.0.1 2181 &|grep -v 127.0.0.1 |awk -F: '{print $1}'|awk -F/ '{print $2}'|head -n1zookeeper工作原理： & &ZooKeeper是一开源分布式应用程序协调服务，包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等功能，可提供一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。 zookeeper的基本概念角色Zookeeper中的角色主要有以下三类，如下表所示：Leader，"Learner"(Follower,Observer),client系统模型如图所示：设计目的1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图。2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。5.原子性：更新只能成功或者失败，没有中间状态。6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。数据模型：Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统。Zookeeper 数据结构有如下这些特点：每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端工作原理Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。每个Server在工作过程中有三种状态：LOOKING：当前Server不知道leader是谁，正在搜寻LEADING：当前Server即为选举出来的leaderFOLLOWING：leader已经选举出来，当前Server与之同步Leader选举流程：当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：1 .选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；2 .选举线程首先向所有Server发起一次询问(包括自己)；3 .选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息( id,zxid)，并将这些信息存储到当次选举的投票记录表中；4. 收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数， 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图如下所示：fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程图如下所示：zookeeper数据同步过程：选完leader以后，zk就进入状态同步过程。1. leader等待server连接；2 .Follower连接leader，将最大的zxid发送给leader；3 .Leader根据follower的zxid确定同步点；4 .完成同步后通知follower 已经成为uptodate状态；5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。流程图如下所示：工作流程Leader工作流程Leader主要有三个功能：1 .恢复数据；2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。Leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。2.3.2 Follower工作流程Follower主要有四个功能：1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；2 .接收Leader消息并进行处理；3 .接收Client的请求，如果为写请求，发送给Leader进行投票；4 .返回Client结果。Follower的消息循环处理如下几种来自Leader的消息：1 .PING消息：心跳消息；2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；3 .COMMIT消息：服务器端最新一次提案的信息；4 .UPTODATE消息：表明同步完成；5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。Follower的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。学习参考：
/dsdoc/dsdoc/blob/master/paxosmadesimple/index.rst本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)