Zab (ZooKeeper Atomic Broadcast, ZooKeeper Atomic Broadcast Protocol, a distributed consensus protocol)

Zab
(ZooKeeper Atomic Broadcast) ( ZooKeeper
Atomic Broadcast Protocol, a distributed consensus protocol)


 
directory

 
The state change caused.
Zab implements a simple totally ordered broadcast protocol (A simple totally ordered broadcast protocol, a distributed consensus protocol)
A simple totally ordered broadcast protocol, a distributed consensus protocol can refer to the document http://diyhpl.us /~bryan/papers2/distributed/distributed-systems/zab.totally-ordered-broadcast-protocol.2008.pdf
1 Introduction
At Yahoo, we developed Zookeeper, a high-performance, high-availability collaboration service that allows large-scale application execution Coordination tasks such as leader elections, state propagation, and convention assemblies. This service implements a hierarchical space of data nodes (znodes) that clients use for their coordination work. We found this service to be very flexible in performance and easily meet the production needs of our site-scale, mission-critical application at Yahoo. Instead of using locks, ZooKeeper uses wait-free shared data objects to guarantee the ordering of operations on these objects.

2 requirements
We assume a set of processes that implement the atomic broadcast protocol and use it. In Zookeeper, in order to ensure the correct conversion to idempotent requests, there must be only one leader (leader) at the same time. Therefore, through the protocol implementation, we upgrade one of the processes to such a process as a leader. We'll discuss it more when we introduce more detailed details of the protocol.
Regarding the broadcast protocol, Zoopkeeper requires the following:
Reliable delivery
If a server successfully delivers a message m, then all correct servers will eventually successfully deliver the message.
Total order
If a server successfully delivers messages a and b, and message a is delivered before message b, then when each server delivering messages a and b delivers messages, message a is delivered before message b.
Causal ordering
If message a is delivered before message b for a reason, and both are delivered successfully, then message a must be delivered sequentially before b.
To ensure correctness, Zoopkeeper also requires the following prefix properties:
Prefix property
If message m is the last message delivered by leader L, any message proposed by leader L before message m is delivered must also It was delivered successfully.
Note: A process may be elected multiple times, but each time it is elected as the leader, the effect on the prefix attribute is considered to be a different leader.
We can maintain a correct replica of the ZooKeeper database through the following three guarantees:
1. Reliability and total order guarantees ensure that all replicas have a consistent state.
2. Using the Zab protocol, from the application point of view, the causal order ensures the correct state of the replicas.
3. The leader proposes an update to the database according to the received request.
Zab considered two types of causality. Pay attention to this, this is very important.
1. If two messages a and b are sent by the same server, and message a is proposed before message b, we say that message a precedes b for a reason.
2. Zab assumes that only one leader can submit proposals at a time. If the leader changes, any previously proposed messages are reasoned ahead of those proposed by the new leader.
Violation of causality.


Other performance requirements are as follows:
low latency
bursty high throughput
smooth fault handling


3 why another protocol is needed

4 protocol
Zab protocol includes two modes: recovery (recovery) mode and broadcast (broadcast) mode.

4.1 Broadcast

5 Conclusion



 
1. Zab, https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab
2. A simple totally ordered broadcast protocol, http://diyhpl.us/~bryan/papers2/distributed/distributed -systems/zab.totally-ordered-broadcast-protocol.2008.pdf
3.