zookeeper分布式锁和服务优化配置

转自：https://www.jianshu.com/p/02eeaee4357f?utm_campaign=maleskine&utm_content=note&utm_medium=pc_all_hots&utm_source=recommendation

前言：这几天忙合作方的项目，就在刚刚如期上线了， 才得以得空，闲下来，和大家吹吹牛，讨论讨论技术，吹吹牛逼，打发着这闲淡的时光。话不多说  咋们直接进入正题。讨论一下ZK的分布式锁以及在生产环境中如何优化我们ZK的服务配置。

在分布式服务下，要想利用ZK实现一个分布式锁，可利用zk的节点特殊性，来实现我们的分布式锁。上一章 我们已经介绍了ZK的节点基本知识。我们可以通过zk的临时节点实现分布式锁的机制

通过以下方式来实现:

1 利用节点名称的唯一性来实现共享锁

ZooKeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在Zookeeper目录/test目录下创建，两个客户端创建一个名为Lock节点，只有一个能够成功。即只有一个服务能创建成功。即创建成功的服务获取分布式锁，解锁时 ，删除相应的节点即可，其余客户端再次进入竞争创建节点，直到所有的客户端都能获得锁。完成自己的业务逻辑。

2 利用临时顺序节点实现共享锁的一般做法

Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/test/lock/0000000001、/test/lock/0000000002、/test/lock/0000000003。

ZK的临时节点特性  当客户端与ZK集群断开连接，则临时节点自动被删除。

利用上面这两个特性，我们来看下获取实现分布式锁的基本逻辑：

客户端调用create()方法创建名为“test/lock-*”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。

客户端调用getChildren(“lock-*”)方法来获取所有已经创建的子节点，同时在这个节点上注册上子节点变更通知的Watcher。

客户端获取到所有子节点path之后，循环子节点 发现创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁。如果发现循环过程中发现自己创建的节点不是最小的，说明自己还没有获取到锁，就开始等待，直到下次子节点变更通知的时候，再进行子节点的获取，判断是否获取锁。

我知道的就这两种方式，可能有其他的方式，网上有人说，还有其他的方式，具体的我没有深入，也就不知道了，如果你深入了解的话，欢迎来信交流。

而在实际的项目中，我们通常会采取第一种方式，因为第二种方式有一个不好的地方：

即在获取所有的子点，判断自己创建的节点是否已经是序号最小的节点”，这个过程，在整个分布式锁的竞争过程中，大量重复运行，并且绝大多数的运行结果都是判断出自己并非是序号最小的节点，从而继续等待下一次通知——这个显然看起来不怎么科学。客户端无端的接受到过多的和自己不相关的事件通知，这如果在集群规模大的时候，会对Server造成很大的性能影响，并且如果一旦同一时间有多个节点的客户端断开连接，这个时候，服务器就会像其余客户端发送大量的事件通知 这是一个不友好的方式。所以我们一般利用ZK来实现我们分布式锁的时候 通常会采用第一种方式来 实现。

像我们做游戏sdk 实时语音的，经常对接游戏Cp 用户量对于我们来说是很大，玩家通过我们的语音服务在游戏交流。那么场景来了：

不同的游戏方 对于我们来说 是不同的应用 用户登入我们实时语音时 我们是根据应用随机分配服务器的，那么在并发量大的时候 肯定在分配的时候 存在竞争，而我们的服务 又是分布式的 此时分布式锁的场景就出现了。我们利用第一种方式来实现我们的分布式锁和自己的业务 。

由于我们是用curator 来实现我们分布式锁，而curator实现分布式锁有好几种锁的方式：

1 共享锁  InterProcessMutex

2 读写锁  InterProcessReadWriteLock

3 共享信号量 InterProcessSemaphoreV2

大概就这么几种吧  而我们的实际的项目中用的是InterProcessMutex来实现分布式锁

此锁属于可重入式锁，当一个客户端获取到lock锁之后，可以重复调用acquire()而不会发生阻塞。基于InterProcessSemaphoreMutex实现的分布式的分布式锁是不可重入的，当一个客户端获取到lock锁之后，再次调用acquire方法获取锁时会发生阻塞。基于InterProcessReadWriteLock实现的分布式锁里边包含了读锁与写锁，其中读锁与读锁互斥，读锁与写锁互斥，读锁与读锁不互斥。所以我们就选择了InterProcessMutex 来实现吧。

在分配服务的时候 实现分布式锁：

 

 

 

 

释放锁：

 

 

获取锁：

 

 

其他两种锁的实现方式如下：

InterProcessReadWriteLock简单的一个实例：

 

 

InterProcessSemaphoreV2 简单的一个实例：

 

 

关于ZK的分布式锁大概就介绍到这里吧 我对ZK的分布式锁也就了解的这么多了，如果你比我更深入的话 欢迎私信 我等渣渣向大神学习。

zk启动的时候 我们可以优化我们的配置 比如以下几种：
1 如果zk jvm内存不够的时候 我们要适当的增加：

更改{ZK_HOME}/bin/zkServer.sh，大约在109-110行。

nohup $JAVA “-Dzookeeper.log.dir=${ZOO_LOG_DIR}” “-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}” \

-cp “$CLASSPATH” $JVMFLAGS $ZOOMAIN “$ZOOCFG” > “$_ZOO_DAEMON_OUT” 2>&1 < /dev/null &

改为：

nohup $JAVA “-Xmx1G -Xms1G -Dzookeeper.log.dir=${ZOO_LOG_DIR}”…

即可增加内存。

2 zoo.cfg 配置文件  是zk的集群基本配置文件  调整里面的参数可以很好的保持我们的集群服务稳定。所以大家要对里面的配置熟悉。如下：

1.tickTime：CS通信心跳数

Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单位

tickTime=2000

2.initLimit：LF初始通信时限

集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）

initLimit=10

3.syncLimit：LF同步通信时限

集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。

syncLimit=5

4.dataDir：数据文件目录

Zookeeper保存数据的目录，默认情况下，Zookeeper将写数据的日志文件也保存在这个目录里。

dataDir=E:\\comany\\zookeeper\\zkdata\\data1

5.dataLogDir：日志文件目录

Zookeeper保存日志文件的目录。

dataLogDir=E:\\comany\\zookeeper\\zkdata\\logs1

6.clientPort：客户端连接端口

客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

clientPort=2181

7.服务器名称与地址：集群信息（服务器编号，服务器地址，LF通信端口，选举端口）

这个配置项的书写格式比较特殊，规则如下：

server.1=127.0.0.1:2287:3387

#server.2=127.0.0.1:2288:3388

#server.3=127.0.0.1:2289:3389

尾记：今天就给大家介绍到这些了吧，我所知道的ZK的分布式锁和服务优化也就这些了，只怪自己太渣，没办法，只能讲到这个程度，时间如白驹过隙，一晃之间就到了9月，一年也就快过完了，自己也越来越年长，自己还是一如既往的渣渣，危机感也越来越重，愿未来更要自我约束，自我鞭策，自我学习。

时间不早了 该回去了  晚上在产业园吃了碗面 完全不管饱，身体要紧，回去补点狗粮，我是小志码字，一个简单码代码的小人物。如果想了解这个项目和代码  加我微信  微信号：2B青年  欢迎交流 相互学习。

 

 

 

 

@siri_7fa6 我们的场景在利用zk做负载均衡和容灾机制，刚好存在分布式锁的情况下 就利用了zk的这种特质实现 之前我们也是利用redis 做分布式锁的 要是说谁好谁坏 还真说不上来了 具体要看自己的场景 不能为了实现分布式锁 而引入zk 这种对运维成本是很高的

作者：小志码字
链接：https://www.jianshu.com/p/02eeaee4357f
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。