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秒钟。

 

你可能感兴趣的:(ZooKeeper学习之关于Servers和Sessions)