Skip to main content
 首页 » 编程设计

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

2022年07月18日46bluestorm

转自: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
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

本文参考链接:https://www.cnblogs.com/maohuidong/p/8401837.html