zookeeper实现服务注册（ZooKeeper之会话session）

原文链接：https://dubby.cn/detail.html?id=9027 作者：杨正

使用客户端来创建一个和zk服务端连接的句柄，这就是一个会话（session）。Session一旦建立，状态就是连接中（CONNECTING）状态，然后客户端会尝试去连接zk服务端，连接成功之后状态变成已连接（CONNECTED）。一般正常情况下只会有这两个状态。不过，还是会发生一些无法恢复的错误/故障，比如：session过期，认证失败，或者客户端关闭连接，这种情况下，session状态会变成关闭（CLOSED）状态。下图给出了zk客户顿可能的状态转换情况：

以下内容是介绍zk的特性，不过很多是结合代码来描述

为了创建一个session，代码中必须要提供一个连接字符串，连接字符串由host:port组成，用,分割，例如127.0.0.1:4545，127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002。zk客户端会随意选择一个zk服务端来尝试连接。如果这个连接失败了，或者因为某种原因断开连接了，客户端会自动尝试下一个服务端，直到连接被成功建立。

3.2.0新特性：连接字符串增加了一个chroot后缀。意思就是所有操作的节点路径都是这个路径下的相对路径（类似unix的chroot命令）。举个例子，127.0.0.1:4545/app/a，127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a，这种情况下，你访问的/foo/bar节点，其实是zk服务端的/app/a/foo/bar节点。如果你的zk服务端是多应用共享的，这个特性应该会很适合你，因为可以很清晰的隔离开各个应用的数据。

当一个session建立的时候，zk服务端会生成一个64位的数字，也就是这个session的标识（姑且称之为session id吧），zk客户端会保存这个标识。如果zk客户端因为某种原因连接到了另一个zk服务端，他会把这个session id传给新的服务端。出于安全考虑，zk服务端在创建连接时，不仅仅生成一个session id，还会同时传给zk客户端一个密码，这个session id 密码是可以被任何一个zk服务端校验的。这样，每次zk客户端重连zk服务端的时候，会同时传递session id 密码，zk服务端校验通过了才会建立连接。

为什么需要密码呢？

随便举个例子，znode的权限是和session有关联的，如果任何客户端都可以伪造session id，那这种安全性就没有意义了。

使用zk客户端创建session的一个参数是session超时时间（毫秒）。但是请注意，这个session超时时间并不是客户端可以随意设置的。zk客户端会把这个session超时时间发给服务端，服务端会返回一个他可以接受的值给客户端。标准其实就是tickTime*2 <= session timeout <= tickTime*20。

如果zk客户端和zk服务端集群断开连接之后，在session超时时间之内，重新连接上了，那么session状态重新变为connected，如果在session超时时间之内没有连接上，那么session状态会变成expired。当session断开连接的时候，最好不用自己去建立一个新的session，因为zk客户端已经帮我做了这个工作，他会自动重连的。只有一种情况需要我们手动重新创建新的session，那就是明确知道session状态为过期状态（expiration）。

session是否过期是由zk服务端集群管理的，而不是zk客户端自己管理自己是否过期。zk服务端就是根据session过期时间来判断是否过期。当zk服务端超过一定的时间没有收到来自zk客户端的心跳，zk服务端就把这个session标记为过期，然后删除这个session创建的所有临时节点，并且李克通知所有监听了这些节点的其他session。在这个时候，zk客户端处于断开连接的状态，一旦它重新连接成功了，他也会收到自己被标记为过期这一事件提醒；在还没有重新连接成功之前，这个zk客户端是不会收到过期的提醒的。

下面举个例子来形象的展示一下上面说的:

1. connected：session被创建，客户端和服务端正常通信。
2. ……客户端和服务端断开连接。
3. disconnected：客户端和服务端失去连接。
4. ……随着时间的流逝，超过了session的超时时间，客户端还没有重新连接成功。
5. ……随着时间的流逝，客户端重新连接上了服务端。
6. expired：最后客户端连接上了服务端，但是之前的session已经被过期了，客户端也会收到过期的事件提醒。

3.2.0 — SessionMovedException：这是一个内部异常，一般不会被应用程序接触到。这个异常发生的情况比较少见，举个例子吧，当一个客户端发一个心跳请求个服务端，但是网络延时，导致服务端没有收到，过一会后，客户端连接上了另一个新的服务端，在这之后，之前的心跳被旧的服务端收到了，这时候旧的服务端会被提醒，当前session已经被转移了，然后旧的服务端会关闭这个连接。客户端一般不会感知到这个异常，因为旧连接一般都会被关闭。但是还有一个特殊情况，两个客户端同时使用保存这的session id 密码来重新连接服务端，第一个连接成功，紧着第二个又连接成功，这会导致第一个连接被关闭，然后就是这两个客户端无限重连了。

更新服务器列表，zk客户端可以使用一个新的连接字符串来更新服务列表。这个机制会使用一个负载均衡算法来重新平衡各个客户端和服务端的连接情况，所以会导致部分客户端断开连接并重新连接到其他服务端。

举个例子，如果之前的连接字符串包含了3和host，新的连接字符串除了之前的3个host还多出了2个新的host，那么会有40%的客户端需要断开连接来连接新的3个服务端，以保持负载均衡。就意味着这40%的客户端需要断开重连。

同样的道理，如果原本有5个host，新的只有3个，也就是移除了2个，那么那移除的2个服务端对应的客户端都会被断开，需要重新连接到3个服务端上。

更多Linux后台架构资讯

更多面试技术视频资料获取：

,