How cluster operations ensure data consistency
Byzantine Generals Problem : The Byzantine Generals Problem is a problem of agreement in which the generals of the Byzantine Empire army must unanimously decide whether to attack an enemy army. The problem is that the generals are geographically separated and there are traitors among the generals. Traitors can act arbitrarily to achieve the following goals: trick some generals into taking an offensive action; facilitate a decision that not all generals agree on, such as facilitating an offensive action when the generals do not wish to attack; or confuse some generals so that they cannot Decide. If the traitor achieves one of these ends, the outcome of any offensive operation is doomed, and victory can only be achieved by a fully agreed effort.
Paxos Algorithm : A consensus algorithm based on message passing and highly fault-tolerant.
The problem solved by the Paxos algorithm is how to quickly and correctly agree on a data value in a distributed system, and ensure that no matter what abnormality occurs, the consistency of the entire system will not be destroyed.
In a Paxos system, all nodes are first divided into Proposers, Acceptors, and Learners. (Note: each node can have multiple roles)
• A complete Paxos algorithm flow is divided into three stages:
• Prepare preparation stage • Proposer issues Propose requests to multiple Acceptors
• Accept acceptance stage • Proposer sends a Propose request to Acceptor after receiving most of the Promises promised by Acceptor • Acceptor performs Accept processing on the received Propose request
• Learn stage: Proposer sends the formed resolution to all Learners
Paxos algorithm flow
(1) Prepare: The Proposer generates a globally unique and incremental Proposal ID, and sends a Proposal request to all Acceptors. There is no need to carry the proposal content here, only the Proposal ID can be carried.
(2) Promise: After the Acceptor receives the Propose request, it makes "two promises and one response".
➢ No longer accept Propose requests whose Proposal ID is less than or equal to (note: <= here) for the current request.
➢ No longer accept Accept requests whose Proposal ID is less than (note: here is < ) the current request.
➢ Without violating previous commitments, reply to the Value and Proposal ID of the proposal with the largest Proposal ID among the accepted proposals, or return a null value if not.
(3) Propose: After the Proposer receives the Promise responses from most Acceptors, it selects the Value of the proposal with the largest Proposal ID from the responses as the proposal to be initiated this time. If the Proposal Value of all responses is empty, you can decide the Proposal Value at will. Then carry the current Proposal ID and send a Propose request to all Acceptors.
(4) Accept: After the Acceptor receives the Propose request, it accepts and persists the current Proposal ID and Proposal Value without violating its previous promise.
(5) Learn: After the Proposer receives the Accept of the majority of Acceptors, a resolution is formed, and the formed resolution is sent to all Learners.
Case explanation
There are five ABCDE people to make resolutions on company issues
The first case:
A made a proposal to others and asked if he could accept his own opinion, but did not say the specific content
BCDE responds to A agreeing
When A receives 2 replies, he will inform others about the specific content of his proposal
BCDE agrees in response to A
At this point, A's proposal will be passed
Second case:
A and E initiated proposals at the same time, and asked if they could accept their opinions. They did not say the specific content. The serial numbers of AE were 1 and 2 respectively.
B responds to A, D responds to E, then C becomes the key
(1) C receives A's message first and responds to A
At this point, A will express his specific opinion
BC accepts
After that, C receives a message from E and responds to E.
At this time, E will also express specific opinions
CD accepted
At this time, AE will broadcast the resolution at the same time, because E's id is large, so E will cover A's proposal
The third case:
AE initiates proposal
B responds to A, D responds to E, then C becomes the key
C receives A's message and replies to A, then immediately receives E's message and replies to E again
At this time, A expresses specific opinions, C will not reply, and there is not enough response
At this time, A will initiate a new proposal. At this time, A's id will become 3, and C will reply to A again.
At this time, E expresses specific opinions, C will not reply, and will re-initiate the proposal
Then there will be a problem
ZAB protocol
Drawing on the Paxos algorithm, on the basis of Paxos, zookeeper is designed to have only one client (Leader) responsible for processing requests for external write transactions, and to synchronize to other nodes, that is, only one Leader can initiate proposals
message broadcast
(1) The client initiates a write operation request.
(2) The leader server converts the client's request into a transaction proposal, and assigns a global ID, namely zxid, to each proposal.
(3) The leader server allocates a separate queue for each follower server, and then puts the proposals that need to be broadcast into the queue in turn, and sends messages according to the FIFO policy.
(4) After the Follower receives the Proposal, it will first write it to the local disk in the form of a transaction log. After the writing is successful, it will return an Ack response message to the Leader.
(5) After the leader receives more than half of the follower's Ack response messages, it considers that the message is sent successfully and can send the commit message.
(6) The Leader broadcasts the commit message to all Followers, and at the same time completes the transaction commit itself. After the Follower receives the commit message, it will commit the previous transaction.
(7) Zookeeper adopts the core of the Zab protocol, that is, as long as one server submits the proposal, it is necessary to ensure that all servers can finally submit the proposal correctly.
At this point, 2 situations will occur :
(1) Leader initiates a transaction Proposal1 and then crashes, and Followers do not have Proposal1
(2) The Leader received half of the ACKs and went down, and did not have time to send Commit to the Follower
crash recovery
Leader election: According to the above requirements, the Zab protocol needs to ensure that the elected leader needs to meet the following conditions:
(1) The newly elected leader cannot contain unsubmitted proposals. That is, the new Leader must be the Follower server node that has submitted the Proposal.
(2) The newly elected Leader node contains the largest zxid. The advantage of this is to avoid the Leader server checking the Proposal submission and discarding the work.
After the election, how Zab synchronizes data:
(1) After the leader election is completed, the leader server will first confirm whether all the proposals in the transaction log have been committed by more than half of the servers in the cluster before officially starting the work (receiving transaction requests and then making new proposals).
(2) The leader server needs to ensure that all follower servers can receive the proposal of each transaction, and can apply all committed transaction proposals to the memory data. After the Follower synchronizes all unsynchronized transaction proposals from the Leader server and applies it to the memory data, the Leader will add the Follower to the list of truly available Followers.
CAP theory
The CAP theory tells us that a distributed system cannot satisfy the following three CAP theories at the same time
⚫ Consistency (C: Consistency)
⚫ Availability (A:Available)
⚫ Partition Tolerance (P: Partition Tolerance) These three basic requirements can only meet at most two of them at the same time, because P is necessary, so the choice is often in CP or AP.
1) Consistency (C: Consistency) In a distributed environment, consistency refers to the characteristics of whether data can maintain data consistency among multiple copies. Under the requirement of consistency, when a system performs an update operation in a state of consistent data, it should ensure that the data of the system is still in a consistent state.
2) Availability (A:Available) Availability means that the services provided by the system must always be available, and the results can always be returned within a limited time for each operation request of the user.
3) Partition Tolerance (P: Partition Tolerance) When a distributed system encounters any network partition failure, it still needs to be able to provide external services that meet consistency and availability unless the entire network environment fails
ZooKeeper guarantees CP
(1) ZooKeeper cannot guarantee the availability of each service request. (Note: In extreme environments, ZooKeeper may drop some requests, and the consumer program needs to re-request to get results). Therefore, ZooKeeper cannot guarantee service availability. (2) The cluster is unavailable during leader election
Persistence
Leader and Follower data will be saved in memory and on disk, so they need to be persisted to disk
The disk will first perform snapshot storage, and then synchronize to the disk when it is idle, and store information according to serialization and deserialization
initialization process
