April 20, 2021
I like to share some content in the book. I learn from reading quickly.
Page 27 - 28, 2021
Another important issue with communication failures is the impact they have on synchronization
primitives like locks. Because nodes can crash and systems are prone to
network partitions, locks can be problematic: if a node crashes or gets partitioned away,
the lock can prevent others from making progress. ZooKeeper consequently needs to
implement mechanisms to deal with such scenarios. First, it enables clients to say that
some data in the ZooKeeper state is ephemeral. Second, the ZooKeeper ensemble
Page 28
requires that clients periodically notify that they are alive. If a client fails to notify the
ensemble in a timely manner, then all ephemeral state belonging to this client is deleted.
Using these two mechanisms, we are able to prevent clients individually from bringing
the application to a halt in the presence of crashes and communication failures.
Recall that we argued that in systems in which we cannot control the delay of messages
it is not possible to tell if a client has crashed or if it is just slow. Consequently, when we
suspect that a client has crashed, we actually need to react by assuming that it could just
be slow, and that it may execute some other actions in the future.
Page 30
It turns out that a famous result in distributed computing, known as FLP after the
authors Fischer, Lynch, and Patterson, proved that in a distributed system with asynchronous
communication and process crashes, processes may not always agree on the
one bit of configuration.1 A similar result known as CAP, which stands for Consistency,
Availability, and Partition-tolerance, says that when designing a distributed system we
may want all three of those properties, but that no system can handle all three.2 Zoo‐
Keeper has been designed with mostly consistency and availability in mind, although
it also provides read-only capability in the presence of network partitions.
Page 23, 39/238
Versions
Each znode has a version number associated with it that is incremented every time its
data changes. A couple of operations in the API can be executed conditionally: setDa
ta and delete. Both calls take a version as an input parameter, and the operation succeeds
only if the version passed by the client matches the current version on the server.
The use of versions is important when multiple ZooKeeper clients might be trying to
perform operations over the same znode. For example, suppose that a client c1 writes a
znode /config containing some configuration. If another client c2 concurrently updates
the znode, the version c1 has is stale and the setData of c1 must not succeed. Using
versions avoids such situations. In this case, the version that c1 uses when writing back
doesn’t match and the operation fails. This situation is illustrated in Figure 2-4.
Page 31, 47/238
session timeout, heartbeat message, ZooKeeper client, ZooKeeper, ...
One important parameter you should set when creating a session is the session timeout,
which is the amount of time 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 nothing 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.
No comments:
Post a Comment