知识库--ZooKeeper + States and the Lifetime of a Session（62）

States and the Lifetime of a Session

The lifetime of a session corresponds to the period between its creation and its end, whether it is closed gracefully or expires because of a timeout. To talk about what happens in a session, we need to consider the possible states that a session can be in and the possible events that can change its state.

The main possible states of a session are mostly sef-explanntory:CONNECTING,CONNECTED,CLOSED, and NOT_CONNECTED. The state transitions depend on various events that happen between the client and the service.

A session starts at the NOT_CONNECTED state and transitions to CONNECTING with the initialization of the ZooKeeper client. Normally, the connection to a ZooKeeper server succeeds and the session transitions to CONNECTED. When the client loses its connection to the ZooKeeper server or doesn’t hear from the server, it transitions back to CONNECTING and tries to find another ZooKeeper server. If it is able to find another server or reconnect to the original server, it transitions back to CONNECTED once the server confirms that the session is still valid. Otherwise , it declares the session expired and transitions to CLOSED. The application can also explicity close the session.

If a client disconnects from a server due to timeout, the client remains in the CONNECTING state. If the disconnection happens because the client has been partitioned away from the ZooKeeper ensemble, it will remain in this state until either it closes the session explicity, or the partition heals and the client hears from a ZooKeeper server that the session has expired. We have this behavior because the ZooKeeper ensemble is the one responsible for declaring a session expired, not the client. Until the client hears that a ZooKeeper session has expired, the client cannot declare the session expired. The client may choose to close the session, however.

//timeout 参数是一个重要的参数，服务端用来宣布 客户端过期。 客户端用来据此发送 heartbeat message 并且 寻找不同的 服务端。

One important parameter you shuold set when creating a session is the session timeout, which is the amount of timee the ZooKeeper service allows a session before declaring it expired. If the service does not see messages associated to a given session during time t, it declares the session expired. On the client side, if it has heard noting from the server at 1/3 of t, it sends a heartbeat message to the server. At 2/3 of t, the ZooKeeper client starts looking for a different server, and it has another 1/3 of t to find one.

//应用程序传递 服务列表 给客户端 即zk list
In quorum mode, the application is supposed to pass a list of servers the client can connect to and choose from.

//游离的客户端如何选择 服务器
When trying to connect to a different server, it is important for the ZooKeeper state of this server to be at least as fresh as the last ZooKeeper state the client has observed. A client cannot connect to a server that has not seen an update that the client might have seen. ZooKeeper determines freshness by ordering updates in the service. Every change to the state of a ZooKeeper deployment is totally ordered with respect to all other executed updates. Consequently, if a client has observed an update in position i, it cannot connect to a server that has only seen i’< i. In the ZooKeeper implementation, the transaction identifiers that the system assigns to each update establish the order.

Following figure illustrates the use of transaction identifiers (zxids) for reconnecting. After the client disconnects from s1 because it times out, it tries s2, but s2 has lagged behind and does not reflect a change known to the client. However, s3 has seen the same changes as the client, so it is safe to connect.