Zookeeper配置参数与简介(1)

[前言:这是一次艰苦的旅行...]

一.初始ZK

 
1. 什么是ZK：ZK是一个高效的分布式协调服务，它暴露了一些公用服务，比如命名/配置管理/同步控制/群组服务等。我们可以使用ZK来实现比如达成共识/集团管理/leader选举等。关键词：分布式协调  高性能
2. 设计目标：

• 简单：ZK中的namespace组织结构类似与标准的文件系统，通过这些共享的有层次的namespace来互相协调分布式中的多个进程，这些namespace由ZNodes组成，ZK数据被保存在内存中，这也意味着ZK将可以达到较高的吞吐量/较低的延迟。ZK的核心目标就是高性能，高可用，严格有序存取。高性能标志着ZK可以被使用在大规模分布式环境中，高可用标志着ZK避免单点故障，具有较强的容错能力；严格有序(strict ordering)意味着客户端可以实现复杂的同步。
• 复制：ZK的数据将会在ZK Cluster中的每台机器上协作复制(备份)，构成ZK服务的机器必须能够互相感知对方。它们保持了一个内存视图状态（in-memory image of state）,同时伴随这tnx log和snapshot的持久存储。只要大部分server有效，那么ZK 服务也是有效的。客户端只与一个zk server建立链接，client通过建立的TCP连接来进行请求/响应/获取事件/发送心跳等。如果此TCP连接失效，client将会尝试连接其他的ZK server。
• 全序性：对于每个update请求，ZK（leader）都会为其生成唯一的Zid来表示其事务的顺序，接下来的操作可以使用zid的顺序实现同步原语（队列）。
• 高效快速：ZK在“读主导”的应用中表现的非常的优秀。ZK应用可以运行在数台机器上，并且在read远大与write的场景中，是非常适合的，通常这个比例为10：1.

3. ZK server组成: ZK server根据其身份特性分为三种：leader，Follower，Observer，其中Follower和Observer又统称Learner（学习者）。

• Leader：负责客户端的writer类型请求
• Follower：负责客户端的reader类型请求，参与leader选举等
• Observer：特殊的“Follower”，其可以接受客户端reader请求，单不参与选举。（扩容系统支撑能力，提高了读取速度。因为它不接受任何同步的写入请求，只负责与leader同步数据）

4. zoo.cfg配置文件详解(参考源码:org.apache.zookeeper.server.quorum.QuorumPeerConfig)：
    //最小化配置

• tickTime=2000    //the length of single tick,it's the base time unit.(heartbeats,timeout,sessionTimeOut)
• clientPort=2181            //the port that client should connnect to.
• dataDir=        //the location :memory database snapshots
• dataLogDir=    //the location    :the txn log file,if not specified,it's the same as 'dataDir'

    //扩展配置

• globalOutstandingLimit(系统属性：zookeeper.globalOutstandingLimit) //default 1000.如果有大量client，会造成ZK server对请求的处理速度小于client的提交请求的速度，会造成server端大量请求queue滞留而OOM，此参数控制server最大持有未处理请求的个数。
• preAllocSize(系统属性：zookeeper.preAllocSize)    //为了避免大量磁盘检索，ZK对txn log文件进行空间预分配，默认为64M。每当剩余空间小于4K时，将会再次“预分配”。你可以尝试减小此值，比如当SNAP较为频繁时(snapCount较小).
• snapCount(系统属性：zookeeper.snapCount)    //默认为100000，在新增log（txn log）条数达到snapCount/2 + Random.nextInt(snapCount/2)时，将会对zkDatabase(内存数据库)进行snapshot，将内存中DataTree反序为snapshot文件数据，同时log计数置为0，以此循环。snapshot过程中，同时也伴随txn log的新文件创建（这也是snapCount与preAllocSize参数的互相协调原因）。snapshot时使用随机数的原因：让每个server snapshot的时机具有随即且可控，避免所有的server同时snapshot（snapshot过程中将阻塞请求）。参见SyncRequestProcessor.run()
• traceFile(系统属性：requestTraceFile)    //请求跟踪文件，如果设置了此参数，所有请求将会被记录在traceFile.year.month.day，类似与nginx的request log，不过此参数的配置，会带来一定的性能问题（Debug model）。
• maxClientCnxns=60    //default 60,一个client与server上最大的socket链接数（socket层），根据IP区分。设置为0，取消此限制。此值在一方面是为了避免DOS攻击。
• ClientPortAddress    //new in 3.3.0,IP或者hostName，指定侦听clientPort的address。此参数是可选的，默认是clientPort会绑定到所有的IP上，在物理server具有多个网络接口时，可以设置特定的IP。
• minSessionTimeout    //new in 3.3.0,default 2*tickTime,也是server允许的最小值，如果设置的值过小，将会采用默认值。
• maxSessionTimeout    //new in 3.3.0,default 20*tickTime,也是server允许的最大值。
• autopurge.snapRetainCount    //new in 3.4.0,zk server启动时会开启一个DatadirCleanupManager的线程，用于清理“过期”的snapshot文件和其相应的txn log file，此参数用于设定需要被retain的文件个数。（源码中关于清理机制，还有点意思）
• autopurge.purgeInterval    //new in 3.4.0,和上述参数配合，清理任务被处罚的时间间隔，单位：hours，实现原理为Timer.scheduleAtFixedRate(...)

    //cluster环境配置

• electionAlg=    //default 3.使用何种选举方式，（0，1，2，3），“0”表示使用原生的UDP（LeaderElection），“1”表示使用非授权UDP，“2”表示授权UDP，“3”基于TCP的快速选举（FastLeaderElection）。目前保留“3”，其他方式将在未来版本不予支持，参见QuorumPear.createElectionAlgorithm（int alg）
• initLimit=10    //Leader与Learner建立的链接中（终端为learner），sock通讯read所阻塞的时间(initLimit * tickTime)，此值为tick的倍数 ，如果Learner数量较多或者Leader的数据很大，建议增加此值。参见LearnerHandler.run()。
• SyncLimit=5    //Learner与Leader建立的链接中，sock通讯read阻塞的时间。其中包括数据同步/和数据提交操作等,此值为tick的倍数，参见learner.connectToLeader()/syncWithLeader().
• peerType    //ZK server类型：observer，participant
• leaderServes(系统属性：zookeeper.leaderServes)    //leader是否接受client请求，默认为“yes”即leader可以接受client的链接。在ZK cluster环境中，当节点数量》3时，建议关闭。

//server列表
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890
server.4=127.0.0.1:2891:3891
server.5=127.0.0.1:2892:3892
//上述为ZK 节点列表，格式：server.sid = hostname:followingPort:electionPort,如果采用UDP方式，electionPort可以不用设置。
//Leader选举成功之后,Follower可以在followingPort上与leader建立链接,以便此后进行各种通讯.比如server.1为Leader,那么其他机器将会在127.0.0.1:2888上建立链接.
//electionPort为Leader选举的端口,当集群处于危险期时,每个server都会根据server列表中配置,和其他server的electionPoint建立链接,并在此后通过此连接发送"选举"信息.

 

• cnxTimeout(系统属性：zookeeper.cnxTimeout)    //leader选举时，socket链接打开的时长。只有在elctionArg为3时生效。

    //不安全配置（不建议修改部分）

• skipACL(系统属性：zookeeper.skipACL)        //默认为no。是否忽略所有的ACL检查。
• forceSync(系统属性：zookeeper.forceSync)    //默认为yes。在update执行前，是否强制对操作立即持久写入txn log文件。关闭此选项，会造成服务失效后，尚未持久的数据丢失。
• Jute.maxbuffer(系统属性：jute.maxbuffer)    //默认为1024，单位KB，即表示节点可挂载的data最大为1M。如果修改此值，请首先确保所有的server上一致。

4.  ZK Commands:
四字指令(指令为四个字符组成)，是方便我们获取ZK cluster状态信息的简单的方式，开发者可以使用"命令"的方式操作,其通过telnet或者nc的方式向ZK的clientPort发送指令.(源码:FourLetterWordMain.java)
【$echo “cmd” | nc ip clientPost】,如下为”cmd”合法值列表:
    conf:打印server配置信息
    cons:列举出与server建立的所有链接/session详情，包括数据接收/发送量，sessionId，操作延迟等等。
    crst：reset关于链接/session的统计信息。
    dump:列举所有的session和临时节点，只能在leader上生效。
    envi：打印server的环境
    ruok：检测server是否正常，如果响应“imok”则表示正在运行。
    srst：重置server的统计信息
    stat：列举server主要的信息。（比如可以获取此server是否为Leader）
    mntr：输出cluster的健康监控参数数据。


5. 其他;
    data被存储在data文件夹，txn log被存储在日至文件夹中，默认这两个路径一样。对于每个ZK Server还需要一个myid的文件，此文件作为一个data文件放置与data目录下，用于标识此server的SID，cluster中sid用于区分通讯中server信息，且不能有重复值(myid文件中只包含一个Integer的数字)。snapshot文件即为ZKDatabase的“快照”，其文件名称格式为    snapshot.zid,其中zid为“快照”开始时最大的zid。