ZooKeeper学习之关于Servers和Sessions

Session是Zookeeper的一个重要的抽象。有序的保证，ephemeral znode，watch都与session紧紧关联。

session的跟踪机制也是很重要的一块。

 

ZooKeeper server的一个重要任务就是跟踪并维护这些session。运行于standalone模式下的单独的server会维护所有的session，而在quorum模式下由leader来维护。leader和standalone模式的server实际上跑着相同的session tracker（可以参考SessionTracker类和SessionTrackerImpl类）。follower仅仅是简单的把client提交的session信息转发到leader（参考LearnerSessionTracker类）。

 

为了保活(keep alive)session，server需要接收到session的心跳。心跳的形式可以是一个新的请求或者显式的ping消息（参考LearnerHandler.run()）。两种情况下，server通过更新session的超时时间来touch session（参考SessionTrackerImpl.touchSession()）。在quorum模式下，leader发送一个ping消息给它的learner，learner返回自从last PING之后的一个session列表。leader每隔半个tick就会发送一个ping给learner。所以，如果一个tick被设置成2秒，那么leader每隔一秒就会发送一个ping。

 

对于session的过期有2个重要的要点。一个称为expiry queue的数据结构（参考ExpiryQueue类）用来维护session的过期。这个数据结构使用bucket来维护session，每一个bucket对应一个时间范围，这个范围内的session会过期，leader每次会让一个bucket的session过期。为了决定哪一个bucket的session过期，如果有的话。当下一个deadline到来时，一个线程会检查这个expiry queue来找出要过期的bucket。这个线程在deadline到来之前处于sleep状态，当它被唤醒时，它会取出expiry queue的一批session，让它们过期。当然取出的这批数据可能是空的。

 

为了维护这些bucket，leader把时间分成一些片段，以expirationInterval为单位进行分割，并把每个session分配到它的过期时间对应的bucket里。更具体的说，是对下面的表达式进行计算，当session的过期时间更新时，根据结果来决定它属于哪一个bucket。

(expirationTime / expirationInterval + 1) * expirationInterval

 

举个例子来说明，比如expirationInterval为2，session的超时时间为10。那么这个session分配到bucket 12中（(10/2+1)*2）。注意当我们touch这个session时这个超时时间会增加，所以我们要把这个session移动到其他的bucket中来推迟过期。

 

使用bucket的模式来管理的一个主要原因是为了减少让session过期这项工作的系统开销。一个生产环境中的ZooKeeper机器可能会有数千个client，对应着数千个session。在这种场景下要细粒度的检查session过期是不合适的。如果expirationInterval短的话，那么检查session过期的粒度会不错。目前是一个tick，相当于1秒钟。