更多精彩内容,请关注微信公众号:后端技术小屋
zk client: github.com/samuel/go-zookeeper
zookeeper 是一款流行的分布式协调组件,被广泛用于 leader 选举、分布式锁、服务发现、名称服务、配置中心等场景。
zk client 与 zk server 在建立连接、保持连接、断开连接的过程中,会经历各种状态。如下所示
const ( // 暂未使用 StateUnknown State = -1 // 与 zk server 之间的连接断开(也包含初始状态),此时 zk client 会不断重连 StateDisconnected State = 0 // 与 zk server 建立连接之前的暂时状态,表示即将 connect zk server StateConnecting State = 1 // 暂未使用 StateAuthFailed State = 4 // 暂未使用 StateConnectedReadOnly State = 5 // 暂未使用 StateSaslAuthenticated State = 6 // 在和 zk server 重新建立 TCP 连接之后,握手阶段发现 session 超时 StateExpired State = -112 // 在和 zk server 成功建立 TCP 连接之后的状态 StateConnected = State(100) // 和 zk server 成功建立 TCP 连接,并且成功握手(即成功创建 session) StateHasSession = State(101) )
超时时间很大程度上影响了上述状态的转换,有三个超时时间值得关注:
func (c *Conn) setTimeouts(sessionTimeoutMs int32) { c.sessionTimeoutMs = sessionTimeoutMs sessionTimeout := time.Duration(sessionTimeoutMs) * time.Millisecond c.recvTimeout = sessionTimeout * 2 / 3 c.pingInterval = c.recvTimeout / 2 }
// Connect establishes a new connection to a pool of zookeeper // servers. The provided session timeout sets the amount of time for which // a session is considered valid after losing connection to a server. Within // the session timeout it's possible to reestablish a connection to a different // server and keep the same session. This is means any ephemeral nodes and // watches are maintained
如果 client 和 server 端连接发生异常,可分为三种情况:
推荐阅读
]]>更多精彩内容,请扫码关注微信公众号:后端技术小屋。如果觉得文章对你有帮助的话,请多多分享、转发、在看。
在按此逻辑编写后,发现第三步中存在问题,可能会出现如下情况:
在获取节点列表并计算出前一节点preNode
后,监听preNode
删除事件前,此preNode
被删除,则监听器永远不会被触发,造成死锁。
这种情况如何保证第三步的原子性?
]]>什么情况下,选择 zookeeper
为什么
网上很多博客列了一堆优缺点,但是。。。大脑里面无法形成判断,“想要什么的时候,由于有什么优点缺点,所以选择 xxx”
]]>