-zookeeper introduction of Auction AD system

ZooKeeper Introduction

To tell the integrity, introduce ZooKeeper. Zookeeper is used more in index and AD server, although it may not be as good as Google's chubby, but it is an open source tool. Take a usage scenario, such as we have a lot of Index, or have a lot of Ad Server, some of them crashed, or some of the machines are newly added to the cluster, how to use a distributed management system to notify other related modules, which machines are available. Zookeeper is the solution to this problem,zookeeper is the basic service to solve the consistency problem in the distributed environment based on the message-passing communication model.

Zookeeper maintains a synchronized state space with a hierarchical namespace, such as the ability to create App1 in the root directory, app2, App1 can be created under P_1 . the principle of zookeeper is to use a lot of machines to make distributed decisions about the state in each of the namespaces. Because it is a distributed decision, the scalability of the system is better.

Here are some of the basic features that I've listed for several zookeeper implementations:sequential consistency, atomicity, single System Image, reliability, timeliness. However, some complex synchronization patterns need to be implemented in API programming.

Paxos algorithm

There are several Paxos made simple in the online version, I removed the implementation of the later state machine model. I think the following translation is more fluent. The example in the Wiki Paxos A better understanding of the Paxos algorithm.

Paxos Made Simple

Leslie Lamport

Sparkliang translation

First explain the translation of several key words in the text:

Proposal translated as "motion", proposed by proposer, Aceeptor approved or rejected

Value translated as "Resolution", it is the content of the motion, a motion is a {number, resolution } on

Accept translated as "approved", indicating that the bill was acceptor approved

Choose is translated as "choice", which means that the motion is "chosen", which is approved by most acceptor

Introduced

The Paxos algorithm, proposed to implement a fault-tolerant distributed system, was considered difficult to understand, perhaps because for most readers the original description was based on the Greek story [5]. In fact, it is one of the simplest and most intuitive distributed algorithms. Its core is a consistency algorithm--[5] proposed in the "Synod" algorithm. The next section describes this conformance algorithm and conforms to the nature of our requirements. The last section explains the complete Paxos algorithm, from the intuitive application of consistency to the finite state machine model for building distributed systems--should be a general known model because it is the subject of the paper [5]-it may be the most cited paper in the theory of distributed systems.

2 Consistency Algorithm

2.1 The question is raised

Imagine a group of process that can present a resolution (value) . The consistency algorithm guarantees that in all proposed resolutions, one resolution will be selected (chosen). If no resolution is made, there will be no choice. If a resolution is chosen, then the process will eventually be able to know the chosen resolution. The security of consistency includes:

-The resolution may be chosen only after it has been proposed,

--Only one resolution is chosen, and

--Theprocess will never be informed that a resolution has been chosen unless the resolution has indeed been chosen.

We will not be particularly clear about precise timing requirements. However, the goal is to eventually have a proposed resolution chosen, and the process will eventually be informed of the chosen resolution, if any.

We divide 3 roles for the conformance algorithm , and are represented by proxies:proposer (the issuer),acceptor (approver), and Listener (recipient). Implementation, allowing a process to play multiple proxies, here we do not care about the mapping from agent to process.

Assume that the agent communicates with the message. We use the asynchronous, non-Byzantine model of the Byzantine model (Byzantine models), where messages may be lost, duplicated, or corrupted in content. In other words, a non-Byzantine model would allow the message to be lost or duplicated, but without corruption of the content ":

-the agent operates at any speed and may fail due to downtime and may restart. Because either agent may stop and restart after the resolution is selected, the solution requires that the agent be able to remember some information so that it can be re-loaded after a reboot.

--The message delivery speed is unpredictable, may be duplicated or lost, but the content will not be corrupted.

2.2 Select Resolution

The simplest way is to use a single acceptor proxy. Proposer sent a motion (proposal) to the acceptor, which chose the first to receive the motion. Although simple, if the acceptor down, then the system can not continue to operate, this program does not meet the requirements.

It seems that we need to choose another method, we use multiple acceptor agents, rather than one,proposer to a group of acceptor to move a motion. A acceptor may approve the bill, when there is a large enough acceptor set to approve the bill, the resolution "The motion is a {number, resolution }" was chosen. So how big is this set to be enough? In order to ensure that only one resolution is chosen, we can let this set contain the majority of the agents "later also called the majority". Since any two majority has at least one proxy, it is feasible if a acceptor can only approve one resolution at most.

Assuming that there is no failure or that the message is lost, even if only one proposer has proposed a resolution, we would also like to choose a resolution. This will export the following requirements:

P1. Acceptor must approve the first resolution it receives.

But that demand can cause a problem. At the same time , several proposer may have proposed several different resolutions, which led each acceptor to approve a resolution, but no resolution was approved by the majority. Even if there were only two resolutions, if each was approved by half of the acceptor, a single acceptor failure would also lead to the impossibility of knowing which resolution was chosen.

A resolution has to be approved by the majority to be chosen, and the demand and P1 imply that acceptor must be able to approve multiple motions. We assign a number to each bill to record different motions, so a motion consists of a number and a resolution consisting of "the motion ={number, resolution }". To avoid confusion, we require that the number of motions be unique. This depends on the implementation, and we assume that this can be done. If a motion {n, v} is approved by a majority, then resolution V is chosen. In this case, we call the motion (including its resolution V) to be selected.

We allow multiple motions to be selected, but we must ensure that all selected motions include the same resolution. The number of motions can be summed to ensure that:

P2. If a motion {n, v} is selected, then all the selected motions (higher numbers) contain the resolution v.

Because the numbers are all ordered,P2 guarantees that "only one resolution is selected" is the key security attribute. The bill must be approved by at least one acceptor before it can be chosen. Therefore, the P2 can be satisfied as long as the following conditions are met :

P2A. If a motion {n, v} is selected, then any acceptor-approved motion (higher number) contains a resolution of v.

We are still P1 to confirm that some of the motions have been selected. Because the communication is asynchronous, in special cases, some acceptor C has not received any motions, they may be "wrong" to approve a bill. Imagine a new proposer "waking up" and proposing a higher numbered bill (with different resolutions). According to P1 's request,C should approve the bill, but this violates the p2a. In order to ensure both P1 and p2a, we need to enhance the p2a:

p2b. If a motion {n, v} is selected, then any proposer proposed by the bill (higher number) contains the resolution v.

Because a bill must be proposer by the acceptor to be approved, so p2b contains p2a, and then contains P2.

How to satisfy p2b, let's consider how to prove it is set up. We assume that a motion {m, v} is selected, and then the resolution of any numbered n>m motion is v. To N Induction can simplify the proof, according to the conditions: each proposed motion (numbered from m to N-1) of the resolution is V, we can prove that the resolution of the motion number n is v. For the selected motion (number m), there must be a set of C (acceptor majority), andevery acceptor in C approves the motion. In combination with the inductive hypothesis,m is chosen as a precondition that implies:

Each acceptor in C approves a motion in the range of M to n-1, and the resolution of the motion is v.

Since any set S consisting of a majority contains at least one member of C, we can conclude that if the following invariance is true, then the resolution of the motion with number n is V:

p2c. for arbitrary V and N, if the motion {n, v} is raised, then there is a set of s that consists of a acceptor majority , or a) s without Acceptor approves a motion with a number less than N, or b) all motions approved by any acceptor in s (number less than N),V is the resolution of the most numbered motion.

By keeping p2c, we can meet p2b.

In order to maintain the invariance p2c, the proposer of the proposed motion (number N) must know that the largest number of all motions with a number less than N, if present, is or will be approved by a majority of the acceptor. It is easy to get the approved bill, but it is difficult to foresee a bill that may be approved in the future. proposer does not make predictions, but assumes that there is no such situation. In other words,proposer requires acceptor not to approve any motion with a number less than N. This leads to the following proposed motion algorithm "This is the two-phase commit."

1. Proposer selects a new number N, sends a request to all members in a Acceptor collection, "prepare request phase,N is the number of the prepare request, and the following Accept the requested motion number "and request a response:

A) a promise to never approve a motion with a number less than N, and

b) in the bill that it has approved for all numbers less than N, the largest number of motions, if any.

I call such a request prepare request N.

2. If proposer receives a response from most acceptor, it can propose a motion {n, v}, where V is the resolution of the highest-numbered motion in all responses, or any value chosen by the proposer, if The Acceptor responded that the bill had not been approved.

A proposer sends an approved motion to a acceptor collection (not necessarily a acceptor collection that responds to the proposer initial request ), which we call the accept request.

We have described the proposer algorithm. What about acceptor? It can receive two requests from proposer: prepare request and accept request. acceptor can ignore any request without worrying about security. So we just need to describe the situation in which it needs to respond to requests. Any time it can respond to a prepare request "in this article, the response means to accept this prepare request and number n", which can respond to the accept request and approve the motion when and only if it has not committed " Commit to approve or approve a higher numbered bill. " In other words:

P1a. Acceptor A motion that is numbered n can be approved when and only if it has not responded to a prepare request with a number greater than n . P1a contains the P1.

Now we have a complete resolution selection algorithm that meets the security attributes we require-assuming the motion number is unique. The final algorithm can be obtained by some simple optimizations.

Suppose a acceptor receives a prepare request with number N, but it has responded to a prepare request with a number greater than n . So acceptor had no need to respond to the prepare request because it would not approve the bill with the number N. It can also ignore the prepare request for a bill that has already been approved .

With these optimizations,acceptor only needs to save the highest numbered motions (including numbers and resolutions) it has approved, as well as the highest number of all prepare requests it has responded to . Because in any case, you need to ensure that p2c,acceptor must remember this information, including after the failure and restart. Note thatproposer can arbitrarily abandon a motion-as long as it never uses the same number to make another motion.

Combining The behavior of proposer and acceptor, we will be able to divide the algorithm into two stages to execute.

Stage 1.

A) Proposer Select a bill number N and send a prepare request with a number of N to the acceptor majority .

b) Acceptor: If the received prepare request has a number n greater than any prepare request it has responded to , it responds to the highest number of approved motions (if any) and undertakes not to respond to any motion with a number less than N;

Stage 2.

A) Proposer: If you receive a response from most acceptor to the prepare request (number n), it sends the accept request for the motion {n, v} to these acceptor , where V is the resolution of the highest-numbered motion in all responses, or the value chosen by proposer, if the response says there is no motion.

b) Acceptor: If the accept request for the motion {n, v} is received , it approves the motion unless it has responded to a motion with a number greater than N.

Proposer can present multiple motions as long as it follows the algorithm above. It can give up a bill at any moment. (This will not undermine correctness, even if the motion's request or response arrives at the target after the bill has been abandoned) and if other proposer have already started proposing higher-numbered motions, it would be better to abandon the current bill. Therefore, if acceptor ignores a prepare or accept request (because a higher-numbered prepare request has been received ), it should inform proposer to abandon the motion. This is a performance optimization without affecting correctness.

2.3 informed of selected resolutions

Learner must find a bill approved by the majority of acceptor to know that a resolution has been chosen. An obvious algorithm is to have each acceptor notify all learner when approving a motion . So learner can know the resolution of choice as soon as possible, but requires each acceptor to notify each learner--the number of messages required equals the number of learner and acceptor.

Based on the non-Byzantine hypothesis, one learner can learn the chosen resolution from another learner. We can allow acceptor to respond to the approval situation to a master learner, which then notifies the other learner of the chosen resolution . This adds an additional message delivery and is unreliable because the primary learner may fail, but the number of messages required is only the sum of the learner and acceptor numbers.

More generally, there can be multiple master learner, each of which can notify all other acceptor. The more the master learner the more reliable, but the communication cost increases "the number of messages."

Since the message was lost, it may not be learner to know that a resolution was chosen. learner can ask Acceptor to approve the bill, but due to the failure of acceptor, it may be difficult to know whether the majority approved a bill. In this way,learner can only know the resolution of acceptor choice when the new motion is chosen . If learner needs to know whether a resolution has been chosen, it can allow proposer to propose a motion according to the above algorithm "to respond to the request, and the resolution of the new proposal is the current choice of resolution."

2.4 Processing Flow

It is easy to construct such a scene, and two proposer take turns proposing a series of numbered increments, but none are chosen. propoer P Select the bill number for N1 and end phase 1. Then, another proposer Q selected the bill number n2>n1 and ended phase 1. So the accept request for P in phase 2 will be ignored because acceptor has promised not to approve a motion with a number less than N2. So P went back to phase 1 and chose the number n3 > N2, which led to the Q second stage of the accept request being ignored ...

In order to guarantee the process, we must choose a main proposer, only the main proposer can move the motion. If the main proposer and most acceptor communicate successfully and present a higher-numbered motion, the bill will be approved. If it learns that there is already a higher-numbered bill, it will abandon the current bill and eventually be able to choose a number that is large enough.

If there are enough components in the system (proposer,acceptor, and network) to work properly, the system can remain responsive by selecting a master proposer. The famous conclusions of Fischer, Lynch and Patterson [1] indicate that a reliable algorithm for selecting proposer must be random or real-time-for example, using a timeout mechanism. However, regardless of the choice of success or not, security can be guaranteed.

2.5 Implement

paxos algorithm [5] assumes a set of network processes. In its conformance algorithm, each process simultaneously plays proposer, acceptor and learner. The algorithm chooses a leader, which is the main proposer and the main learner. paxos consistency algorithm is the one described above, the request and response are sent with a message (the response will be marked with the corresponding motion number to prevent confusion). Use persistent storage to ensure that acceptor fail to remember the necessary information. acceptor must persist the response before sending a response.

The next step is to describe a mechanism that guarantees that no two motions are numbered. The proposer selects the motion number from each disjoint collection, so two different proposer will never propose the same number of motions. "Assuming that there are 5 proposer, numbered 0~4, you can make the motion number selection sequence for proposer I:5*j + i (J >= 0), it is guaranteed to never repeat, and increments" each Proposer both persist the highest-numbered motions it has proposed, and use a higher motion number to start phase 1.

-zookeeper introduction of Auction AD system