Shulou(Shulou.com)06/01 Report--

The problem solved by Paxos algorithm is how a distributed system can agree on a certain value (resolution). This algorithm is considered to be the most effective of its kind. The combination of Paxos and MySQL can achieve strong consistency of distributed MySQL data.

The problem to be solved by Paxos is the problem of consistency in distributed systems. So what exactly is the "consistency problem in distributed systems"? In a distributed system, in order to ensure the high availability of data, we usually keep multiple data

Copies (replica), which are placed on different physical machines. If the replicas are to be consistent, the update sequence of all replicas must be consistent. Because there are generally multiple client concurrent operations in the operation of adding, deleting, modifying and querying data.

In the end, which client does it first and which client does it later, the update order should be guaranteed. If it is not distributed, then through the method of locking, whoever applies for the lock first will operate first, but there is a single point of problem. There are two main uses of the Paxos protocol:

One use is to implement global locking services or naming and configuration services, such as Google Chubby and Apache ZooKeeper. Another use is to copy user data to multiple data centers, such as Google Megastore and Google Spanner.

In the Paxos algorithm, there are three main roles:

Proposer: proponent

Acceptor: decision maker

Learner: the final decision Learner

It is often implemented with a fixed number of Server, and each Server plays the above three roles at the same time.

The Paxos algorithm is divided into three stages:

1. Prepare stage

(1) Proposer initiates a Prepare request for Proposal (epochNo,value) to most Acceptor.

(2) if Acceptor receives a Prepare request, if the epochNo is smaller than the previous one, it directly rejects it; if the epochNo is larger than the previously received one, it returns the largest Proposal of the received epochNo to Proposer.

(3) the Proposal initiated by Proposer must at least receive Prepare responses from most of the Acceptor before entering the next Accept phase, otherwise it is necessary to re-conduct the Prepare phase to initiate Prepare requests to most Acceptor.

2. Accept stage:

(1) after Proposer receives most Prepare responses from Acceptor, see if Acceptor already has an accepted Proposal. If there is no accepted Proposal, propose a Proposal and initiate the Accept request; if there is already an accepted Proposal, select the largest Proposal of the epochNo to initiate the Accept request for the Proposal.

(2) after Acceptor receives the request, if the epochNo of the Proposal is larger than the epochNo of its last reply to the Prepare request, then it accepts the request; otherwise, it rejects the request.

3. Learn stage:

All Proposal accepted by Acceptor should be constantly notified to Learner, or Learner should take the initiative to query. Once Learner confirms that Proposal is accepted by most Acceptor, then the Value of this Proposal can be learned from the Value of this Proposal by Chosen,Learner, and Proposor's request will no longer be accepted on its own Sever.

What is the difference between the data synchronization mode of Paxos protocol and the traditional synchronization method based on 1 master N backup?

In general, the high availability of traditional databases is based on master / slave, with 1 master, 1 standby and 2 replicas. After crash, the master database is switched by HA tool to upgrade the standby database to the master database. In a strong consistent scenario, replication can enable strong synchronization, and Oracle and Mysql are similar replication modes. However, if the slave network jitter, or crash, will cause log synchronization failure, the service is not available. For this reason, we can introduce the multi-replica form of 1 master N standby, and we compare it with 3 replicas, one is based on the traditional 1 master 2 standby, the other is based on paxos 1 master 2 backup. In the traditional one-master and two-slave log synchronization, as long as one copy receives the log and persists successfully, it can be returned, which solves the problem of network jitter and slave crash to some extent. However, if there is something wrong with the main library, we still have to switch with the help of HA tools, so how to ensure the availability of HA switching tools has become a problem. Paxos-based multi-replica synchronization actually introduces a consistency protocol on the basis of one master N standby, so that the availability of the whole system is completely controlled by three replicas, and no additional HA tools are needed. In fact, in order to ensure the consistency of multi-node HA tools to obtain active and standby information, many systems use third-party interfaces such as zookeeper to implement distributed locks. In fact, they are also based on Paxos.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.