本文介绍了在使用Zookeeper的EPHEMERAL节点管理服务集群时可能出现的问题，包括连接丢失后的节点删除、节点创建判断错误、客户端关闭处理不当、连接异步处理以及Curator的重试限制等。这些陷阱可能导致服务列表异常，影响集群的稳定性和可靠性。解决方案包括正确处理连接状态变化、检查节点是否存在和会话ID、确保客户端关闭时的清理、避免长时间阻塞事件处理以及理解Curator的重试机制。
笔者在一个Websocket中间件产品（Apush，https://market.aliyun.com/products/56928004/cmapi020699.html#sku=yuncode1469900000）的集群管理中使用了zk的EPHEMERAL节点机制。
在编码过程中发现很多可能存在的陷阱，毛估估，第一次使用zk来实现集群管理的人应该有80%以上会掉坑，有些坑比较隐蔽，在网络问题或者异常的场景时才会出现，可能很长一段时间才会暴露出来。
1、不处理zk的连接状态变化事件导致zk客户端断开后与zk服务器集群没有重连。后果：连接丢失后EPHEMERAL节点会删除并且客户端watch丢失。
此坑不深，稍微注意一下还是容易发现的，并且采用Curator会减少此类问题的发生，不是完全避免，具体见第6个坑。
zk客户端如果和某台zk服务器断开，会主动尝试与zk集群中其他服务器重新连接，直到sessiontimeout，需要考虑极端的情况下出现sessiontimeout的处理。
zk客户端和zk服务器断开时会收到state为Disconnected的连接事件，此事件一般可以不处理，此事件后续会跟Expired状态的连接事件或者synconne
最低0.47元/天 解锁文章
扫一扫
1175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
