MVCC， ACID,BASIC 和Pasox的示例分析

這期內容當中小編將會給大家帶來有關MVCC， ACID,BASIC 和Pasox的示例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

MVCC是Multi-Version Concurrency Control 的縮寫，中文是多版本并發控制

簡單來說，MVCC的目的就是可以讓在不同的事物中任意修改鏡像，并通過比較版本號的形式來決定最新成功的事物。

但在現實中并不存在這樣的樂觀情況，比如說事物1修改了row1，事物2 修改了row1，事物1修改ROW2失敗。那么將回滾row1.但由于事物2已經修改過row1，所以回滾的話，將導致事物2失效。所以純粹的MVCC的架構并不適用于在數據庫中的設計。

通常來說在數據庫中的MVCC經常表現為，查詢在同一個事物內，可以看到數據的是一致的，如果在事物進行中，數據被另外的事物修改，則去讀取該數據的前鏡像數據，不會因為其他人的修改而有所改變。

修改的過程依然是排他。而并非MVCC的樂觀鎖定。

ACID中的I的實現方法。

當事物進行修改數據時，在數據行中有隱藏的列，分別是ID,事物ID以及回滾前鏡像ID，以及。在行數據被修改的時候，原數據會被copy到回滾段中，當前行的回滾前鏡像ID，設置為回滾段中的ID。

MYSQL 只會查找數據版本號早于當前事物版本號的數據。所以當一個事物開始時，有被修改的數據，則會通過向前翻看回滾日志找到該數據的未修改改前的數值。

2PC

2PC 一般會有一個協調者進行操作，首先協調者會對自己進行寫日志。然后給所有參與者發送prepare消息，詢問包括自己在內的全部人是否可以commit本次transaction，參與者會先對事物進行預處理，如果可以提交，則會在自己身上寫入日志，并會發給協調者 ready信息，并且自身進入可提交狀態，如果不可提交則發送一個not commit的狀態，同時撤銷更改。

協調者如果收到not commit,則會記入日志并發送abort 信號。所有參與者撤銷數據庫更改。

協調者如果收到全部參與者的ready消息，則會將commit寫入日志，并向所有參與者發送commit消息。如果收到所有的參與者消息，則會將食物提交 計入日志。

如果協調者遲遲未收到某些參與者的消息，則會認為該參與者發送了vote_abort的信號，從而對其他參與者發送ABORT信號。

在MySQL中其實有2種事物參與者，binlog ,redo log. 當事物發起時，binlog先發送prepare，其實什么都不會做，然后innodb引擎發送prepare,將事物的狀態設置為TRX_PREPARED，開始刷新redo log到磁盤中。當所有存儲引擎的prepare都成功，則將SQL語句寫入到binlog.如果事物回滾，則不會寫入bin log.最后調用存儲引擎的commit完成事物的提交，binlog_commit什么都不會做因為binlog已經寫完了。Innodb commit 則會進行刷redo log,清空undo的信息，將當前事物設置為TRX_NOT_STARTED狀態

CAP

CAP 是指在分布式環境中的一致性，可用性和分區容災性，而強行保留三項中的全部項會導致任意一項中的其他的兩項無法證明。

業內通常的做法是犧牲一致性，但是即使犧牲了一致性也不一定可以保證可用性及分區容災性，因為還有延遲的存在。

下面這一條總結的很好：

CAP 理論說在一個系統中對某個數據不存在一個算法同時滿足 Consistency, Availability, Partition-tolerance。注意，這里邊最重要和最容易被人忽視的是限定詞“對某個數據不存在一個算法”。這就是說在一個系統中，可以對某些數據做到 CP, 對另一些數據做到 AP，就算是對同一個數據，調用者可以指定不同的算法，某些算法可以做到 CP，某些算法可以做到 AP。

BASE：

BASE是Basically availability ,soft state, eventually consistent三個短語的縮寫。

基于CAP理論，但核心思想是基于一致性與可用性進行權衡的結果，根據需求不同來設定不同的計劃，如火車票系統與網購商品對一致性和可用性的要求就幾乎相反。所以即使在無法做到強一致性的前提下，但應用可以根據自身特點采用適當的方式來是系統達到最終一致性。

1.Basically availability:

為了保障基本可用性，可以損失一部分性能，如搜索引擎出現故障時，可以從0.023秒的響應時間增加到2秒，雖然慢了 但不會404.當進行網站商品促銷時，如果流量過大，為了保障功能可以用，消費者可能會被引導到一個降級頁面。

2.soft state

指允許系統中數據存在中間狀態，并認為中間狀態的存在不會影響系統的整體可用性，這一點與CAP中的C概念完全相悖。即系統的數據在同步過程中允許存在延遲

3.eventually consistent

最終一致性的意思是在一段時間后，整個系統的數據全部副本會成為一致的狀態，而不需要保證數據實時一致。

Base理論的是針對大型分布式系統的理論，數據無需保持實時一致，這與ACID中的強一致要求是不一致的，但ACID特性和BASE設計往往會參合在一起使用。

PASOX

Pasox分為basic和multi pasox.

Basic paxso主要是設計來如何解決在分布式環境下的唯一值問題。

在分布式環境中一般會多個proposer 和多個acceptor 。

每個proposer發起的提議會以（ID,VALUE）來進行標識。

每個acceptor可以接受多個提議，當多數的acceptor接受一項提議的時候，該提議被chosen。

在解決唯一值問題時其中有幾個基本原則：

1.P1原則，acceptor 接受他收到的第一個提議

2.P2原則如果一個值V被接受，那么后續只確定值為V的提議。

3.P2a原則，如果一項值為V被chosen，那么acceptor后續只接受值為V的提議。

4.P2b原則，如果一項值為V的提議被chosen,那么后續proposer值發起值為V的提議

5.P2c原則，對于提議(n,v)，acceptor的多數派中，如果存在acceptor最近一次(ID最大）接受的提議值為V'，那么要求V=V’，否則V可以為任意值。

假設有A~E 5個acceptor，- 表示acceptor因宕機等原因缺席當次決議，x 表示acceptor不接受提議，o 表示接受提議；多數派acceptor接受提議后提議被確定，以上表格對應的決議過程如下：

第一輪，提議2為最先發起的提議，他可以發起任何值a.

第二輪，acceptor ABCE, ID是5的提議因為沒有任何值被接受，所以可以是任何值b.（D缺席）

第三輪 ，acceptor BDE因為D接受了值a，所以ID為14的提議根據P2原則，則必須提議值a.

第四輪，acceptor ACD 因為C接受了值b ,A,D 接受了值a ,根據P2c原則，值b的提議ID大于值a 所以ID27的提議必須為b.

第五輪, acceptor BCD，BCD,都接受過了提議，相比之下CD曾接受的27號提議ID最大，所以29輪的提議必須為b.

為了實現p2c ，acceptor需要保證1，記錄曾經接受的最大的提議ID號以便proposer查詢以決定其提議值。2.在回應ID n之后，需要保證不再接受ID小于n的提議。

上述就是小編為大家分享的MVCC， ACID,BASIC 和Pasox的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。