前言：这几天忙合作方的项目，就在刚刚如期上线了， 才得以得空，闲下来，和大家吹吹牛，讨论讨论技术，吹吹牛逼，打发着这闲淡的时光。话不多说 咋们直接进入正题。讨论一下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青年 欢迎交流 相互学习。
补一张公司加班狗的图照：
