CAP理論與MongoDB一致性、可用性的一些思考

大約在五六年前，第一次接觸到了當(dāng)時已經(jīng)是hot topic的NoSql。不過那個時候?qū)W的用的都是mysql，Nosql對于我而言還是新事物，并沒有真正使用，只是不明覺厲。但是印象深刻的是這么一張圖片（后來google到圖片來自這里）：

    這張圖片是講數(shù)據(jù)庫（包括傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和NOSQL）與CAP理論的關(guān)系。由于并NoSql并沒有實(shí)踐經(jīng)驗(yàn)，也沒有去深入了解，對于CAP理論更是一知半解。因此，為什么某一款數(shù)據(jù)庫被劃分到哪一個陣營，并不清楚。

    工作之后對MongoDB使用得比較多，有了一定的了解，前段時間又看到了這張圖，于是想搞清楚，MongoDB是不是真的屬于CP陣營，又是為什么？懷疑這個問題的初衷是因?yàn)?，MongoDB的經(jīng)典（官方推薦）部署架構(gòu)中都會使用replica set，而replica set通過冗余和自動failover提供高可用性（Availability），那么為什么上圖中說MongoDB犧牲了Avalability呢？而我在MongoDB的官方文檔中搜索“CAP”，并沒有搜索到任何內(nèi)容。于是我想自己搞清楚這個疑問，給自己一個答案。

　　本文先闡明什么是CAP理論，以及關(guān)于CAP理論的一些文章，然后討論MongoDB在一致性與可用性之間的折中與權(quán)衡。

　　本文地址：http://www.cnblogs.com/xybaby/p/6871764.html

CAP理論

回到頂部

　　對CAP理論我只知道這三個單詞的意思，其解釋也是來自網(wǎng)上的一些文章，并不一定準(zhǔn)確。所以首先得追根溯源，搞清楚這個理論的起源和準(zhǔn)確的解釋。我覺得最好的開始就是wikipedia，從上面可以看到比較準(zhǔn)確的介紹，更為重要的是可以看到很多有用的鏈接，比如CAP理論的出處，發(fā)展演變過程。

　　CAP理論是說對于分布式數(shù)據(jù)存儲，最多只能同時滿足一致性（C，Consistency）、可用性（A， Availability）、分區(qū)容錯性（P，Partition Tolerance）中的兩者。

　　一致性，是指對于每一次讀操作，要么都能夠讀到最新寫入的數(shù)據(jù)，要么錯誤。

　　可用性，是指對于每一次請求，都能夠得到一個及時的、非錯的響應(yīng)，但是不保證請求的結(jié)果是基于最新寫入的數(shù)據(jù)。

　　分區(qū)容錯性，是指由于節(jié)點(diǎn)之間的網(wǎng)絡(luò)問題，即使一些消息對包或者延遲，整個系統(tǒng)能繼續(xù)提供服務(wù)（提供一致性或者可用性）。

　　一致性、可用性都是使用非常寬泛的術(shù)語，在不同的語義環(huán)境下具體所指是不一樣的，比如在cap-twelve-years-later-how-the-rules-have-changed一文中Brewer就指出“CAP中的一致性與ACID中的一致性并不是同一個問題”，因此后文中除非特別說明，所提到的一致性、可用性都是指在CAP理論中的定義。只有明確了大家都是在同樣的上下文環(huán)境，討論才有意義。

　　對于分布式系統(tǒng)，網(wǎng)絡(luò)分區(qū)（network partition）這種情況是難以避免的，節(jié)點(diǎn)間的數(shù)據(jù)復(fù)制一定存在延遲，如果需要保證一致性（對所有讀請求都能夠讀到最新寫入的數(shù)據(jù)），那么勢必在一定時間內(nèi)是不可用的（不能讀取），即犧牲了可用性，反之亦然。

　　按照維基百科上的描述，CAP之間的相互關(guān)系大約起源于1998年，Brewer在2000年的PODC（Symposium on Principles of Distributed Computing）上展示了CAP猜想[3]，在2002年，由另外兩名科學(xué)家Seth Gilbert、Nancy Lynch證明了Brewer的猜想，從而從猜想變成了定理[4]。

CAP理論起源

　　在Towards Robust Distributed Systems 中，CAP理論的提出者Brewer指出：在分布式系統(tǒng)中，計(jì)算是相對容易的，真正困難的是狀態(tài)的維護(hù)。那么對于分布式存儲或者說數(shù)據(jù)共享系統(tǒng)，數(shù)據(jù)的一致性保證也是比較困難的。對于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，優(yōu)先考慮的是一致性而不是可用性，因此提出了事務(wù)的ACID特性。而對于許多分布式存儲系統(tǒng)，則是更看重可用性而不是一致性，一致性通過BASE（Basically Available, Soft state, Eventual consistency）來保證。下面這張圖展示了ACID與BASE的區(qū)別：

　　簡而言之：BASE通過最終一致性來盡量保證服務(wù)的可用性。注意圖中最后一句話“But I think it‘s a spectrum”，就是說ACID BASE只是一個度的問題，并不是對立的兩個極端。

　　2002年，在Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services中，兩位作者通過異步網(wǎng)絡(luò)模型論證了CAP猜想，從而將Brewer的猜想升級成了理論（theorem）。但實(shí)話說，我也沒有把文章讀得很明白。

　　2009年的這篇文章brewers-cap-theorem，作者給出了一個比較簡單的證明：

　　如上圖所示，N1，N2兩個節(jié)點(diǎn)存儲同一份數(shù)據(jù)V，當(dāng)前的狀態(tài)是V0。在節(jié)點(diǎn)N1上運(yùn)行的是安全可靠的寫算法A，在節(jié)點(diǎn)N2運(yùn)行的是同樣可靠的讀算法B，即N1節(jié)點(diǎn)負(fù)責(zé)寫操作，N2節(jié)點(diǎn)負(fù)責(zé)讀操作。N1節(jié)點(diǎn)寫入的數(shù)據(jù)也會自動向N2同步，同步的消息稱之為M。如果N1，N2之間出現(xiàn)分區(qū)，那么就沒法保證消息M在一定的時間內(nèi)到達(dá)N2。

　　從事務(wù)的角度來看這各問題

 　　α這個事務(wù)由操作α1， α2組成，其中α1是寫數(shù)據(jù)，α2是讀數(shù)據(jù)。如果是單點(diǎn)，那么很容易保證α2能讀到α1寫入的數(shù)據(jù)。如果是分布式的情況的情況，除非能控制 α2的發(fā)生時間，否則無法保證 α2能讀到 α1寫入的數(shù)據(jù)，但任何的控制（比如阻塞，數(shù)據(jù)集中化等）要么破壞了分區(qū)容錯性，要么損失了可用性。

　　另外，這邊文章指出很多情況下 availability比consistency重要，比如對于facebook google這樣的網(wǎng)站，短暫的不可用就會帶來巨大的損失。

　　2010年的這篇文章brewers-cap-theorem-on-distributed-systems/，用了三個例子來闡述CAP，分別是example1：單點(diǎn)的mysql；example2：兩個mysql，但不同的mysql存儲不同的數(shù)據(jù)子集（類似sharding）；example3：兩個mysql，對A的一個insert操作，需要在B上執(zhí)行成功才認(rèn)為操作完成（類似復(fù)制集）。作者認(rèn)為在example1和example2上 都能保證強(qiáng)一致性，但不能保證可用性；在example3這個例子，由于分區(qū)（partition）的存在，就需要在一致性與可用性之間權(quán)衡。

　　于我看來，討論CAP理論最好是在“分布式存儲系統(tǒng)”這個大前提下，可用性也不是說整體服務(wù)的可用性，而是分布式系統(tǒng)中某個子節(jié)點(diǎn)的可用性。因此感覺上文的例子并不是很恰當(dāng)。

CAP理論發(fā)展

 　  到了2012年，CAP理論的發(fā)明人 Brewer就CAP理論再次撰文《CAP Twelve Years Later: How the "Rules" Have Changed》，這篇文章比較長，但思路清晰，高屋建瓴，非常值得一讀。網(wǎng)上也有對用的中文譯文《CAP理論十二年回顧："規(guī)則"變了》，翻譯還不錯。

　　文章中，最主要的觀點(diǎn)是CAP理論并不是說三者不需選擇兩者。首先，雖然只要是分布式系統(tǒng)，就可能存在分區(qū)，但分區(qū)出現(xiàn)的概率是很小的（否則就需要去優(yōu)化網(wǎng)絡(luò)或者硬件），CAP在大多數(shù)時候允許完美的C和A；只有在分區(qū)存在的時間段內(nèi)，才需要在C與A之間權(quán)衡。其次，一致性和可用性都是一個度的問題，不是0或者1的問題，可用性可以在0%到100%之間連續(xù)變化，一致性分為很多級別（比如在casandra，可以設(shè)置consistency level）。因此，當(dāng)代CAP實(shí)踐的目標(biāo)應(yīng)該是針對具體的應(yīng)用，在合理范圍內(nèi)最大化數(shù)據(jù)一致性和可用性的效力。

　　文章中還指出，分區(qū)是一個相對的概念，當(dāng)超過了預(yù)定的通信時限，即系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。

　　從收入目標(biāo)以及合約規(guī)定來講，系統(tǒng)可用性是首要目標(biāo)，因而我們常規(guī)會使用緩存或者事后校核更新日志來優(yōu)化系統(tǒng)的可用性。因此，當(dāng)設(shè)計(jì)師選擇可用性的時候，因?yàn)樾枰诜謪^(qū)結(jié)束后恢復(fù)被破壞的不變性約。

　　實(shí)踐中，大部分團(tuán)體認(rèn)為（位于單一地點(diǎn)的）數(shù)據(jù)中心內(nèi)部是沒有分區(qū)的，因此在單一數(shù)據(jù)中心之內(nèi)可以選擇CA；CAP理論出現(xiàn)之前，系統(tǒng)都默認(rèn)這樣的設(shè)計(jì)思路，包括傳統(tǒng)數(shù)據(jù)庫在內(nèi)。

　　分區(qū)期間，獨(dú)立且能自我保證一致性的節(jié)點(diǎn)子集合可以繼續(xù)執(zhí)行操作，只是無法保證全局范圍的不變性約束不受破壞。數(shù)據(jù)分片（sharding）就是這樣的例子，設(shè)計(jì)師預(yù)先將數(shù)據(jù)劃分到不同的分區(qū)節(jié)點(diǎn)，分區(qū)期間單個數(shù)據(jù)分片多半可以繼續(xù)操作。相反，如果被分區(qū)的是內(nèi)在關(guān)系密切的狀態(tài)，或者有某些全局性的不變性約束非保持不可，那么最好的情況是只有分區(qū)一側(cè)可以進(jìn)行操作，最壞情況是操作完全不能進(jìn)行。

　　上面摘錄中下選線部分跟MongoDB的sharding情況就很相似，MongoDB的sharded cluste模式下，shard之間在正常情況下，是無需相互通信的。

　　在13年的文章中《better-explaining-cap-theorem》，作者指出“it is really just A vs C！”，因?yàn)?/p>

　　（1）可用性一般是在不同的機(jī)器之間通過數(shù)據(jù)的復(fù)制來實(shí)現(xiàn)

　?。?）一致性需要在允許讀操作之間同時更新幾個節(jié)點(diǎn)

　　（3）temporary partion，即幾點(diǎn)之間的通信延遲是可能發(fā)生了，此時就需要在A 和 C之間權(quán)衡。但只有在發(fā)生分區(qū)的時候才需要考慮權(quán)衡。

　　在分布式系統(tǒng)中，網(wǎng)絡(luò)分區(qū)一定會發(fā)生，因此“it is really just A vs C！”

MongoDB與CAP

回到頂部

　　在《通過一步步創(chuàng)建sharded cluster來認(rèn)識MongoDB》一文中，對MongoDB的特性做了一些介紹，包括高性能、高可用、可擴(kuò)展（水平伸縮），其中，MongoDB的高可用性依賴于replica set的復(fù)制與自動failover。對MongoDB數(shù)據(jù)庫的使用有三種模式：standalone，replica set， shareded cluster，在前文中詳細(xì)介紹了shared cluster的搭建過程。

　　standalone就是單個mongod，應(yīng)用程序直接連接到這個Mongod，在這種情況下無分區(qū)容錯性可言，也一定是強(qiáng)一致性的。對于sharded cluster，每一個shard也都推薦是一個replica set。MongoDB中的shards維護(hù)的是獨(dú)立的數(shù)據(jù)子集，因此shards之間出現(xiàn)了分區(qū)影響不大（在chunk遷移的過程可能還是有影響），因此也主要考慮的是shard內(nèi)部replica set的分區(qū)影響。所以，本文中討論MongoDB的一致性、可用性問題，針對的也是MongoDB的replica set。

　　對于replica set，只有一個primary節(jié)點(diǎn)，接受寫請求和讀請求，其他的secondary節(jié)點(diǎn)接受讀請求。這是一個單寫、多讀的情況，比多讀、多寫的情況還是簡化了許多。后文為了討論，也是假設(shè)replica set由三個基點(diǎn)組成，一個primary，兩個secondary，且所有節(jié)點(diǎn)都持久化數(shù)據(jù)（data-bearing）

　　MongoDB關(guān)于一致性、可用性的權(quán)衡，取決于三者：write-concern、read-concern、read-preference。下面主要是MongoDB3.2版本的情況，因?yàn)閞ead-concern是在MongoDB3.2版本中才引入的。

write-concern：

　　write concern表示對于寫操作，MongoDB在什么情況下給予客戶端響應(yīng)。包括下面三個字段：

　　{ w: <value>, j: <boolean>, wtimeout: <number> }

　　w: 表示當(dāng)寫請求在value個MongoDB實(shí)例處理之后才向客戶端返回。取值范圍：

　　　　1：默認(rèn)值，表示數(shù)據(jù)寫入到standalone的MongoDB或者replica set的primary之后返回

　　　　0：不用寫入就直接向客戶端返回，性能高，但可能丟數(shù)據(jù)。不過可以配合j：True來增加數(shù)據(jù)的可持久性（durability）

　　　　>1: 只有在replica set環(huán)境下才有用，如果value大于的replica set中節(jié)點(diǎn)的數(shù)目，那么可能導(dǎo)致阻塞

　　　　‘majority’： 當(dāng)數(shù)據(jù)寫入到replica set的大多數(shù)節(jié)點(diǎn)之后向客戶端返回，對于這種情況，一般是配合read-concern使用：

　　　　After the write operation returns with a w: "majority" acknowledgement to the client, the client can read the result of that write with a "majority" readConcern

　　j：表示當(dāng)寫請求在寫入journal之后才向客戶端返回，默認(rèn)為False。兩點(diǎn)注意：

　　　　如果在對于未開啟journaling的MongoDB實(shí)例使用j:True，會報錯

　　　　在MongoDB3.2及之后，對于w>1, 需要所有實(shí)例都寫到j(luò)ournal之后才返回

　　wtimeout：表示寫入的超時時間，即在指定的時間（number），如果還不能向客戶端返回（w大于1的情況），那么返回錯誤

　　　　默認(rèn)為0，相當(dāng)于沒有設(shè)置該選項(xiàng)

　　在MongoDB3.4中，加入了writeConcernMajorityJournalDefault.這么一個選項(xiàng)，使得w，j在不同的組合下情況下不同:

read-reference:

　　在前文已經(jīng)講解過，一個replica set由一個primary和多個secondary組成。primary接受寫操作，因此數(shù)據(jù)一定是最新的，secondary通過oplog來同步寫操作，因此數(shù)據(jù)有一定的延遲。對于時效性不是很敏感的查詢業(yè)務(wù)，可以從secondary節(jié)點(diǎn)查詢，以減輕集群的壓力。

　　MongoDB指出在不同的情況下選用不同的read-reference，非常靈活。MongoDB driver支持一下幾種read-reference：

　　primary：默認(rèn)模式，一切讀操作都路由到replica set的primary節(jié)點(diǎn)

　　primaryPreferred：正常情況下都是路由到primary節(jié)點(diǎn)，只有當(dāng)primary節(jié)點(diǎn)不可用（failover）的時候，才路由到secondary節(jié)點(diǎn)。

　　secondary：一切讀操作都路由到replica set的secondary節(jié)點(diǎn)

　　secondaryPreferred：正常情況下都是路由到secondary節(jié)點(diǎn)，只有當(dāng)secondary節(jié)點(diǎn)不可用的時候，才路由到primary節(jié)點(diǎn)。

　　nearest：從延時最小的節(jié)點(diǎn)讀取數(shù)據(jù)，不管是primary還是secondary。對于分布式應(yīng)用且MongoDB是多數(shù)據(jù)中心部署，nearest能保證最好的data locality。

　　如果使用secondary或者secondaryPreferred，那么需要意識到：

　　(1) 因?yàn)檠訒r，讀取到的數(shù)據(jù)可能不是最新的，而且不同的secondary返回的數(shù)據(jù)還可能不一樣；

　　(2) 對于默認(rèn)開啟了balancer的sharded collection，由于還未結(jié)束或者異常終止的chunk遷移，secondary返回的可能是有缺失或者多余的數(shù)據(jù)

　　(3) 在有多個secondary節(jié)點(diǎn)的情況下，選擇哪一個secondary節(jié)點(diǎn)呢，簡單來說是“closest”即平均延時最小的節(jié)點(diǎn)，具體參加Server Selection Algorithm 

read-concern:

　　read concern是在MongoDB3.2中才加入的新特性，表示對于replica set（包括sharded cluster中使用復(fù)制集的shard）返回什么樣的數(shù)據(jù)。不同的存儲引擎對read-concern的支持情況也是不一樣的

　　read concern有以下三個level：

　　local：默認(rèn)值，返回當(dāng)前節(jié)點(diǎn)的最新數(shù)據(jù)，當(dāng)前節(jié)點(diǎn)取決于read reference。

　　majority：返回的是已經(jīng)被確認(rèn)寫入到多數(shù)節(jié)點(diǎn)的最新數(shù)據(jù)。該選項(xiàng)的使用需要以下條件： WiredTiger存儲引擎，且使用election protocol version 1；啟動MongoDB實(shí)例的時候指定 --enableMajorityReadConcern選項(xiàng)。

　　linearizable：3.4版本中引入，這里略過了，感興趣的讀者參考文檔。

　　在文章中有這么一句話：

Regardless of the read concern level, the most recent data on a node may not reflect the most recent version of the data in the system.

　　就是說，即便使用了read concern：majority， 返回的也不一定是最新的數(shù)據(jù)，這個和NWR理論并不是一回事。究其根本原因，在于最終返回的數(shù)值只來源于一個MongoDB節(jié)點(diǎn)，該節(jié)點(diǎn)的選擇取決于read reference。

　　在這篇文章中，對readconcern的引入的意義以及實(shí)現(xiàn)有詳細(xì)介紹，在這里只引用核心部分：

readConcern 的初衷在于解決『臟讀』的問題，比如用戶從 MongoDB 的 primary 上讀取了某一條數(shù)據(jù)，但這條數(shù)據(jù)并沒有同步到大多數(shù)節(jié)點(diǎn)，然后 primary 就故障了，重新恢復(fù)后 這個primary 節(jié)點(diǎn)會將未同步到大多數(shù)節(jié)點(diǎn)的數(shù)據(jù)回滾掉，導(dǎo)致用戶讀到了『臟數(shù)據(jù)』。

當(dāng)指定 readConcern 級別為 majority 時，能保證用戶讀到的數(shù)據(jù)『已經(jīng)寫入到大多數(shù)節(jié)點(diǎn)』，而這樣的數(shù)據(jù)肯定不會發(fā)生回滾，避免了臟讀的問題。

 一致性 or 可用性？

　　回顧一下CAP理論中對一致性 可用性的問題：
　　一致性，是指對于每一次讀操作，要么都能夠讀到最新寫入的數(shù)據(jù)，要么錯誤。
　　可用性，是指對于每一次請求，都能夠得到一個及時的、非錯的響應(yīng)，但是不保證請求的結(jié)果是基于最新寫入的數(shù)據(jù)。

　　前面也提到，本文對一致性 可用性的討論是基于replica set的，是否是shared cluster并不影響。另外，討論是基于單個客戶端的情況，如果是多個客戶端，似乎是隔離性的問題，不屬于CAP理論范疇?；趯rite concern、read concern、read reference的理解，我們可以得出以下結(jié)論。

• 默認(rèn)情況（w：1、readconcern：local）如果read preference為primary，那么是可以讀到最新的數(shù)據(jù)，強(qiáng)一致性；但如果此時primary故障，那么這個時候會返回錯誤，可用性得不到保證

• 默認(rèn)情況（w：1、readconcern：local）如果read preference為secondary（secondaryPreferred、primaryPreferred），雖然可能讀到過時的數(shù)據(jù)，但能夠立刻得到數(shù)據(jù)，可用性比較好

• writeconern：majority保證寫入的數(shù)據(jù)不會被回滾; readconcern：majority保證讀到的一定是不會被回滾的數(shù)據(jù)

• 若（w：1、readconcern；majority）即使是從primary讀取，也不能保證一定返回最新的數(shù)據(jù)，因此是弱一致性

• 若（w: majority、readcocern：majority），如果是從primary讀取，那么一定能讀到最新的數(shù)據(jù)，且這個數(shù)據(jù)一定不會被回滾，但此時寫可用性就差一些；如果是從secondary讀取，不能保證讀到最新的數(shù)據(jù)，弱一致性。

　　回過來來看，MongoDB所說的高可用性是更普世意義上的可用性：通過數(shù)據(jù)的復(fù)制和自動failover，即使發(fā)生物理故障，整個集群還是能夠在短時間內(nèi)回復(fù)，繼續(xù)工作，何況恢復(fù)也是自動的。在這個意義上，確實(shí)是高可用的。