Shulou(Shulou.com)05/31 Report--

In this issue, Xiaobian will bring you an example analysis of MVCC, ACID,BASIC and Pasox. The article is rich in content and analyzed and described from a professional perspective. After reading this article, I hope you can gain something.

MVCC is the abbreviation of Multi-Version Concurrency Control, Chinese is Multi-Version Concurrency Control

Simply put, the purpose of MVCC is to allow arbitrary modification of mirrors in different things and to determine the latest successful thing by comparing the form of version numbers.

But in reality there is no such optimistic situation, for example, thing 1 modifies row1, thing 2 modifies row1, thing 1 modifies ROW2 fails. But since thing 2 has already modified row1, rolling back will cause thing 2 to fail. So pure MVCC architecture does not apply to design in databases.

Generally speaking, MVCC in databases often shows that queries within the same thing can see that the data is consistent, and if the data is modified by another thing in progress, the pre-mirror data of the data will be read, which will not change due to the modification of others.

The process of modification remains exclusive. And not the optimistic lock of MVCC.

I in ACID.

When things modify data, there are hidden columns in the data row, ID, thing ID, and mirror ID before rollback, and. When row data is modified, the original data is copied into the rollback segment, and the pre-rollback mirror ID of the current row is set to the ID in the rollback segment.

MYSQL will only find data whose version number is older than the version number of the current transaction. So when a transaction starts, there is data that has been modified, and you look forward through the rollback log to find the unmodified value of that data.

2PC

2PC will generally have a coordinator to operate, first coordinator will write a log of themselves. Then send a prepare message to all participants, asking if everyone including themselves can commit this transaction. Participants will preprocess things first. If they can commit, they will write logs on themselves and send ready messages to coordinators. They will enter a committable state. If they cannot commit, they will send a not commit state and undo the changes.

The coordinator logs and sends an abort signal if he receives a not commit. All participants undo database changes.

If the coordinator receives a ready message from all participants, it writes commit to the log and sends a commit message to all participants. If all participant messages are received, the food submission is logged.

If the coordinator does not receive messages from certain participants for a long time, it will assume that the participant sent a vote_abort signal, thus sending ABORT signals to other participants.

In MySQL there are actually two kinds of participants: binlog ,redo log. When a transaction is initiated, binlog sends prepare, which doesn't actually do anything, and then innodb sends prepare, sets the transaction's state to TRX_PREPARED, and starts flushing redo log to disk. When all storage engines prepare successfully, write SQL statement to binlog. If things roll back, bin log will not be written. Finally commit of storage engine is called to complete the commit of things, binlog_commit will do nothing because binlog is finished. Innodb commit will do redo log, clear undo information, set the current thing to TRX_NOT_STARTED state

CAP

CAP refers to consistency, availability, and partition disaster recovery in a distributed environment, and forcing all three items to remain unproven results in any two of the other items.

It is common practice in the industry to sacrifice consistency, but even if consistency is sacrificed, it does not necessarily guarantee availability and partition disaster recovery, because there is also latency.

Here's a good summary:

CAP theory states that there is no algorithm in a system that satisfies Consistency, Availability, Partition-tolerance. Note that the most important and overlooked of these is the qualifier "There is no algorithm for some data." That is to say, in a system, CP can be done for some data and AP can be done for other data. Even for the same data, the caller can specify different algorithms. Some algorithms can do CP and some algorithms can do AP.

BASE：

BASE is an abbreviation for Basically availability ,soft state, and eventually consistent.

Based on CAP theory, but the core idea is based on the result of trade-off between consistency and availability, different plans are set according to different needs, such as train ticket system and online shopping goods, which have almost opposite requirements for consistency and availability. Therefore, even if strong consistency cannot be achieved, the application can adopt appropriate methods according to its own characteristics to achieve final consistency of the system.

1.Basically availability:

In order to guarantee basic usability, some performance can be lost, such as when the search engine fails, the response time can be increased from 0.023 seconds to 2 seconds, although slow but not 404. When promoting website products, if the traffic is too large, in order to ensure that the function can be used, consumers may be directed to a degraded page.

2.soft state

It refers to allowing intermediate states of data in the system and assuming that the existence of intermediate states does not affect the overall availability of the system, which is completely contrary to the concept of C in CAP. That is, the system's data allows for delays in synchronization

3.eventually consistent

Ultimate consistency means that after a period of time, all copies of the data throughout the system will become consistent, without the need to ensure that the data is consistent in real time.

Base theory is a theory for large distributed systems where data need not be consistent in real time, which is inconsistent with the strong consistency requirement in ACID, but ACID features and BASE designs are often used together.

PASOX

Pasox is divided into basic and multi pasox.

Basic paxso is primarily designed to solve the problem of unique values in distributed environments.

In a distributed environment, there are usually multiple proposers and multiple acceptors.

Each proposer proposal is identified by (ID,VALUE).

Each acceptor can accept multiple offers, and when a majority of acceptors accept an offer, the offer is chosen.

There are several basic principles for solving unique value problems:

P1 Principle: Acceptor accepts the first offer he receives.

P2 Principle If a value V is accepted, then only proposals with a value V are subsequently determined.

P2a principle: If a value of V is chosen, then the acceptor accepts only subsequent proposals with values of V.

4. P2b Principle: If a proposal of value V is chosen, then subsequent proposer values initiate proposals of value V

5. P2c principle: For proposal (n,v), in the majority of acceptors, if there is a proposal accepted by acceptor last time (ID maximum), V=V'is required, otherwise V can be any value.

Suppose there are 5 acceptors A~E, -means that the acceptor is absent from the current resolution due to downtime, x means that the acceptor does not accept the proposal, o means that the proposal is accepted; the proposal is confirmed after the majority acceptor accepts the proposal. The resolution process corresponding to the above table is as follows:

In the first round, proposal 2 is the first proposal to be initiated, and he can initiate any value a.

The second round, acceptor ABCE, ID is 5 proposals because no value is accepted, so can be any value b. (D absent)

Third round, acceptor BDE Since D accepts the value a, the proposal with ID 14 must propose the value a according to the P2 principle.

In the fourth round, acceptor ACD because C accepts the value b ,A,D accepts the value a , according to the P2c principle, the proposal ID of the value b is greater than the value a, so the proposal ID of ID27 must be b.

The fifth round, acceptor BCD, BCD, has accepted the offer, in contrast, CD has accepted the offer No. 27 with the largest ID, so the offer in round 29 must be b.

To implement p2c, the acceptor needs to guarantee 1, recording the largest offer ID number ever accepted so that the proposer queries to determine its offer value. 2. After responding to ID n, you need to ensure that no more offers with ID less than n are accepted.

The above is an example analysis of MVCC, ACID,BASIC and Pasox shared by Xiaobian. If you happen to have similar doubts, you may wish to refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

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.