We continue discussing the ZooKeeper. It is a co-ordination service with elements from group messaging, shared registers and distributed lock services. It provides a interface that guarantees wait-free property and FIFO execution of requests from each client.  Requests across all clients are also linearized.
We were discussing the durability guarantee of ZooKeeper. On every read request, a zxid is returned that relates to the last transaction seen by the server. Since the writes are all transactional, this zxid indicates a partial order of the read requests.  If a client connects to a different server, that server ensures that its view of the ZooKeeper data is at least as current as that of the client by comparing its zxid with that of the client. If the client is more recent, the server does not reestablish a session until it has caught up. Since a majority of the ZooKeepers would be current before the client received the zxid, the client is guaranteed to find another server that has a recent view of the system.
Client session failures are detected using timeouts. The leader determines that the client is gone if none of the servers received anything within the timeout. The client is encouraged to send a heartbeat if there are no active requests for a long time. This is automatically done in the client library from ZooKeeper.
The evaluations done with ZooKeeper by the authors included measuring throughput when the system is saturated and changes on various injected failure. A large number of clients connected and this number was kept the same while the servers were varied. This simulated a large load and it was seen that the number of servers had a negative impact on performance. Read throughput is consistently higher than write throughput.Write requests had to go through atomic broadcast. Transactions are logged to non-volatile store. These contribute to the difference in throughput.

Software for  Email Campaign updated: https://1drv.ms/w/s!Ashlm-Nw-wnWsEXQ3UmFVYv0GpFe