What is the session mechanism of Zookeeper

The default ZK server port is 2181 when Zookeeper is started. When the client connects to the server, it is essentially a TCP connection (long connection). When the connection is formally established, it starts the life cycle of the session. After the session, the subsequent request sending, response, heartbeat detection and other mechanisms are implemented based on the session. For ZK server, how to maintain and manage these sessions, is the content of this article ~

Basic concepts related to Session

When a connection is established, the Session is established, and there are three important values associated with this process:

  • SessionID: unique SessionID assigned by ZK

  • TimeOut: indicates the session TimeOut time. During the client connect to the server, if for some reason to disconnect the connection (e.g., network interruption, etc.), the sessions as well as its related temporary node will not be deleted immediately, but waiting for a TimeOut after run out, if the client has not reconnection, the failure, this session will be related to some temporary node will be deleted

  • Expiration Time: TimeOut is a relative Time, and Expiration Time is an absolute Expiration Time on the timeline. As you might imagine, a common way to calculate this is:


    This is the most accurate time. But that’s not how ZK works. It uses



    The default value of ExpirationInterval is 2000 milliseconds. Context

SessionId generation is associated with two things, one is the timestamp, one is the machine ID

/** where id is the machine id**/
public static long initializeNextSession(long id) {
        long nextSid = 0;
        nextSid = (System.currentTimeMillis() << 24) > > >8;
        nextSid =  nextSid | (id <<56);
        return nextSid;
}
Copy the code

Points bucket mechanism

Session is managed by ZK server. A server can serve multiple clients, that is, there are multiple sessions. How are these sessions managed? And the bucket mechanism can be said to be a means of its management. The ZK server maintains buckets and allocates sessions to buckets. And this distinguishing dimension is ExpirationTime

Why this distinction? The ZK server periodically checks Session timeouts during runtime. If sessions are not maintained, then all sessions must be traversed during Session timeouts. This is obviously not a good idea, so the Session is stored in the timeout dimension, so that during detection, only the corresponding bucket can be scanned

In this case, a new problem arises: the timeout per Session is a very diffuse value. If there are 1000 sessions, it is likely that there will be 1000 different timeout times, and then there will be 1000 buckets. Does that make sense? This would be to look back at the ExpirationTime calculation formula, then paste:



ExpirationTime is a multiple of ExpirationInterval, and ExpirationInterval is the frequency with which the ZK server checks expired sessions. The default value is 2000 milliseconds. Therefore, every Session ExpirationTime is an approximate value, a multiple of ExpirationInterval. In this case, ZK only needs to scan a bucket when scanning.

In addition, the expiration time is a multiple of the ExpirationInterval so that the check time and expiration time of each Session are on the same time node. Otherwise, there is a problem: a Session expires 1 millisecond after the ZK check is complete, which is definitely not a good situation.

Session activation (Renewal)

The expiration time is generated after the client completes the connection with the server. This value is not constant, but is updated as the client interacts with the server. The expiration date is updated, of course, along with the Session migration on the bucket

At its simplest, every time a client sends a request to a server, both read and write, it triggers an activation, because it indicates that the client is active

If the client has not sent a read or write request within a third of TimeOut, the client will send a PING to trigger Session activation. Of course, if the client disconnects directly, the server will scan the connection after TimeOut