If you understand the 2pc and 3pc protocols of distributed transactions (it doesn’t matter if you don’t understand, we will talk about it later), the message broadcast process is actually a simplified version of the two-phase commit process
1. After receiving the message request, the leader assigns the message to a globally unique 64-bit self-incrementing id called: zxid. The feature of causal order can be realized by comparing the size of zxid.
2. The leader prepares a FIFO queue for each follower (implemented through the TCP protocol to achieve the feature of global order) and distributes the message with zxid as a proposal to all the followers
3. When the follower receives the proposal, first write the proposal to the disk, and then reply an ack to the leader after the write is successful
4. When the leader receives a legal number of ACKs (more than half of the nodes), the leader will send a commit command to these followers, and will execute the message locally
5. When the follower receives the commit command of the message, it will submit the message
ps: The difference from a complete 2pc transaction is that the zab protocol cannot terminate the transaction. The follower node must either ACK to the leader or discard the leader. You only need to ensure that more than half of the nodes respond to this message and submit it, although in a certain one The status of the follower node and the leader node will be inconsistent at any time, but this feature also improves the overall performance of the cluster. Of course, for this kind of data inconsistency, the zab protocol provides a recovery mode for data recovery. The follow-up explanation
The things to note here are:
The leader’s voting process does not require the Observer’s ack, that is, the Observer does not need to participate in the voting process, but the Observer must synchronize the leader’s data to ensure data consistency when processing requests