這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)MVCC， ACID,BASIC 和Pasox的示例分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都做網(wǎng)站、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的茂南網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

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

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

但在現(xiàn)實中并不存在這樣的樂觀情況，比如說事物1修改了row1，事物2 修改了row1，事物1修改ROW2失敗。那么將回滾row1.但由于事物2已經(jīng)修改過row1，所以回滾的話，將導(dǎo)致事物2失效。所以純粹的MVCC的架構(gòu)并不適用于在數(shù)據(jù)庫中的設(shè)計。

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

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

ACID中的I的實現(xiàn)方法。

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

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

2PC

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

協(xié)調(diào)者如果收到not commit,則會記入日志并發(fā)送abort 信號。所有參與者撤銷數(shù)據(jù)庫更改。

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

如果協(xié)調(diào)者遲遲未收到某些參與者的消息，則會認(rèn)為該參與者發(fā)送了vote_abort的信號，從而對其他參與者發(fā)送ABORT信號。

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

CAP

CAP 是指在分布式環(huán)境中的一致性，可用性和分區(qū)容災(zāi)性，而強行保留三項中的全部項會導(dǎo)致任意一項中的其他的兩項無法證明。

業(yè)內(nèi)通常的做法是犧牲一致性，但是即使?fàn)奚艘恢滦砸膊灰欢梢员ＷC可用性及分區(qū)容災(zāi)性，因為還有延遲的存在。

下面這一條總結(jié)的很好：

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

BASE：

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

基于CAP理論，但核心思想是基于一致性與可用性進行權(quán)衡的結(jié)果，根據(jù)需求不同來設(shè)定不同的計劃，如火車票系統(tǒng)與網(wǎng)購商品對一致性和可用性的要求就幾乎相反。所以即使在無法做到強一致性的前提下，但應(yīng)用可以根據(jù)自身特點采用適當(dāng)?shù)姆绞絹硎窍到y(tǒng)達到最終一致性。

1.Basically availability:

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

2.soft state

指允許系統(tǒng)中數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性，這一點與CAP中的C概念完全相悖。即系統(tǒng)的數(shù)據(jù)在同步過程中允許存在延遲

3.eventually consistent

最終一致性的意思是在一段時間后，整個系統(tǒng)的數(shù)據(jù)全部副本會成為一致的狀態(tài)，而不需要保證數(shù)據(jù)實時一致。

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

PASOX

Pasox分為basic和multi pasox.

Basic paxso主要是設(shè)計來如何解決在分布式環(huán)境下的唯一值問題。

在分布式環(huán)境中一般會多個proposer 和多個acceptor 。

每個proposer發(fā)起的提議會以（ID,VALUE）來進行標(biāo)識。

每個acceptor可以接受多個提議，當(dāng)多數(shù)的acceptor接受一項提議的時候，該提議被chosen。

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

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

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

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

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

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

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

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

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

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

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

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

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

上述就是小編為大家分享的MVCC， ACID,BASIC 和Pasox的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。