共計(jì) 3147 個(gè)字符，預(yù)計(jì)需要花費(fèi) 8 分鐘才能閱讀完成。

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

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

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

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

通常來說在數(shù)據(jù)庫中的 MVCC 經(jīng)常表現(xiàn)為，查詢?cè)谕粋€(gè)事物內(nèi)，可以看到數(shù)據(jù)的是一致的，如果在事物進(jìn)行中，數(shù)據(jù)被另外的事物修改，則去讀取該數(shù)據(jù)的前鏡像數(shù)據(jù)，不會(huì)因?yàn)槠渌说男薷亩兴淖儭?/p>

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

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

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

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

2PC

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

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

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

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

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

CAP

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

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

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

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

BASE：

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

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

1.Basically availability:

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

2.soft state

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

3.eventually consistent

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

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

PASOX

Pasox 分為 basic 和 multi pasox.

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

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

每個(gè) proposer 發(fā)起的提議會(huì)以（ID,VALUE）來進(jìn)行標(biāo)識(shí)。

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

在解決唯一值問題時(shí)其中有幾個(gè)基本原則：

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

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

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

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

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

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

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

第二輪，acceptor ABCE, ID 是 5 的提議因?yàn)闆]有任何值被接受，所以可以是任何值 b.（D 缺席）

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

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

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

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

上述就是丸趣 TV 小編為大家分享的 MVCC，ACID,BASIC 和 Pasox 的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。