溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
大約在五六年前，第一次接觸到了當時已經是hot topic的NoSql。不過那個時候學的用的都是mysql，Nosql對于我而言還是新事物，并沒有真正使用，只是不明覺厲。但是印象深刻的是這么一張圖片（后來google到圖片來自這里）：
這張圖片是講數據庫（包括傳統的關系型數據庫和NOSQL）與CAP理論的關系。由于并NoSql并沒有實踐經驗，也沒有去深入了解，對于CAP理論更是一知半解。因此，為什么某一款數據庫被劃分到哪一個陣營，并不清楚。
工作之后對MongoDB使用得比較多，有了一定的了解，前段時間又看到了這張圖，于是想搞清楚，MongoDB是不是真的屬于CP陣營，又是為什么？懷疑這個問題的初衷是因為，MongoDB的經典（官方推薦）部署架構中都會使用replica set，而replica set通過冗余和自動failover提供高可用性（Availability），那么為什么上圖中說MongoDB犧牲了Avalability呢？而我在MongoDB的官方文檔中搜索“CAP”，并沒有搜索到任何內容。于是我想自己搞清楚這個疑問，給自己一個答案。
本文先闡明什么是CAP理論，以及關于CAP理論的一些文章，然后討論MongoDB在一致性與可用性之間的折中與權衡。
本文地址：http://www.cnblogs.com/xybaby/p/6871764.html
回到頂部
對CAP理論我只知道這三個單詞的意思，其解釋也是來自網上的一些文章，并不一定準確。所以首先得追根溯源，搞清楚這個理論的起源和準確的解釋。我覺得最好的開始就是wikipedia，從上面可以看到比較準確的介紹，更為重要的是可以看到很多有用的鏈接，比如CAP理論的出處，發展演變過程。
CAP理論是說對于分布式數據存儲，最多只能同時滿足一致性（C，Consistency）、可用性（A， Availability）、分區容錯性（P，Partition Tolerance）中的兩者。
一致性，是指對于每一次讀操作，要么都能夠讀到最新寫入的數據，要么錯誤。
可用性，是指對于每一次請求，都能夠得到一個及時的、非錯的響應，但是不保證請求的結果是基于最新寫入的數據。
分區容錯性，是指由于節點之間的網絡問題，即使一些消息對包或者延遲，整個系統能繼續提供服務（提供一致性或者可用性）。
一致性、可用性都是使用非常寬泛的術語，在不同的語義環境下具體所指是不一樣的，比如在cap-twelve-years-later-how-the-rules-have-changed一文中Brewer就指出“CAP中的一致性與ACID中的一致性并不是同一個問題”，因此后文中除非特別說明，所提到的一致性、可用性都是指在CAP理論中的定義。只有明確了大家都是在同樣的上下文環境，討論才有意義。
對于分布式系統，網絡分區（network partition）這種情況是難以避免的，節點間的數據復制一定存在延遲，如果需要保證一致性（對所有讀請求都能夠讀到最新寫入的數據），那么勢必在一定時間內是不可用的（不能讀取），即犧牲了可用性，反之亦然。
按照維基百科上的描述，CAP之間的相互關系大約起源于1998年，Brewer在2000年的PODC（Symposium on Principles of Distributed Computing）上展示了CAP猜想[3]，在2002年，由另外兩名科學家Seth Gilbert、Nancy Lynch證明了Brewer的猜想，從而從猜想變成了定理[4]。
在Towards Robust Distributed Systems 中，CAP理論的提出者Brewer指出：在分布式系統中，計算是相對容易的，真正困難的是狀態的維護。那么對于分布式存儲或者說數據共享系統，數據的一致性保證也是比較困難的。對于傳統的關系型數據庫，優先考慮的是一致性而不是可用性，因此提出了事務的ACID特性。而對于許多分布式存儲系統，則是更看重可用性而不是一致性，一致性通過BASE（Basically Available, Soft state, Eventual consistency）來保證。下面這張圖展示了ACID與BASE的區別：
簡而言之：BASE通過最終一致性來盡量保證服務的可用性。注意圖中最后一句話“But I think it‘s a spectrum”，就是說ACID BASE只是一個度的問題，并不是對立的兩個極端。
2002年，在Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services中，兩位作者通過異步網絡模型論證了CAP猜想，從而將Brewer的猜想升級成了理論（theorem）。但實話說，我也沒有把文章讀得很明白。
2009年的這篇文章brewers-cap-theorem，作者給出了一個比較簡單的證明：
如上圖所示，N1，N2兩個節點存儲同一份數據V，當前的狀態是V0。在節點N1上運行的是安全可靠的寫算法A，在節點N2運行的是同樣可靠的讀算法B，即N1節點負責寫操作，N2節點負責讀操作。N1節點寫入的數據也會自動向N2同步，同步的消息稱之為M。如果N1，N2之間出現分區，那么就沒法保證消息M在一定的時間內到達N2。
從事務的角度來看這各問題
α這個事務由操作α1， α2組成，其中α1是寫數據，α2是讀數據。如果是單點，那么很容易保證α2能讀到α1寫入的數據。如果是分布式的情況的情況，除非能控制 α2的發生時間，否則無法保證 α2能讀到 α1寫入的數據，但任何的控制（比如阻塞，數據集中化等）要么破壞了分區容錯性，要么損失了可用性。
另外，這邊文章指出很多情況下 availability比consistency重要，比如對于facebook google這樣的網站，短暫的不可用就會帶來巨大的損失。
2010年的這篇文章brewers-cap-theorem-on-distributed-systems/，用了三個例子來闡述CAP，分別是example1：單點的mysql；example2：兩個mysql，但不同的mysql存儲不同的數據子集（類似sharding）；example3：兩個mysql，對A的一個insert操作，需要在B上執行成功才認為操作完成（類似復制集）。作者認為在example1和example2上 都能保證強一致性，但不能保證可用性；在example3這個例子，由于分區（partition）的存在，就需要在一致性與可用性之間權衡。
于我看來，討論CAP理論最好是在“分布式存儲系統”這個大前提下，可用性也不是說整體服務的可用性，而是分布式系統中某個子節點的可用性。因此感覺上文的例子并不是很恰當。
到了2012年，CAP理論的發明人 Brewer就CAP理論再次撰文《CAP Twelve Years Later: How the "Rules" Have Changed》，這篇文章比較長，但思路清晰，高屋建瓴，非常值得一讀。網上也有對用的中文譯文《CAP理論十二年回顧："規則"變了》，翻譯還不錯。
文章中，最主要的觀點是CAP理論并不是說三者不需選擇兩者。首先，雖然只要是分布式系統，就可能存在分區，但分區出現的概率是很小的（否則就需要去優化網絡或者硬件），CAP在大多數時候允許完美的C和A；只有在分區存在的時間段內，才需要在C與A之間權衡。其次，一致性和可用性都是一個度的問題，不是0或者1的問題，可用性可以在0%到100%之間連續變化，一致性分為很多級別（比如在casandra，可以設置consistency level）。因此，當代CAP實踐的目標應該是針對具體的應用，在合理范圍內最大化數據一致性和可用性的效力。
文章中還指出，分區是一個相對的概念，當超過了預定的通信時限，即系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。
從收入目標以及合約規定來講，系統可用性是首要目標，因而我們常規會使用緩存或者事后校核更新日志來優化系統的可用性。因此，當設計師選擇可用性的時候，因為需要在分區結束后恢復被破壞的不變性約。
實踐中，大部分團體認為（位于單一地點的）數據中心內部是沒有分區的，因此在單一數據中心之內可以選擇CA；CAP理論出現之前，系統都默認這樣的設計思路，包括傳統數據庫在內。
分區期間，獨立且能自我保證一致性的節點子集合可以繼續執行操作，只是無法保證全局范圍的不變性約束不受破壞。數據分片（sharding）就是這樣的例子，設計師預先將數據劃分到不同的分區節點，分區期間單個數據分片多半可以繼續操作。相反，如果被分區的是內在關系密切的狀態，或者有某些全局性的不變性約束非保持不可，那么最好的情況是只有分區一側可以進行操作，最壞情況是操作完全不能進行。
上面摘錄中下選線部分跟MongoDB的sharding情況就很相似，MongoDB的sharded cluste模式下，shard之間在正常情況下，是無需相互通信的。
在13年的文章中《better-explaining-cap-theorem》，作者指出“it is really just A vs C！”，因為
（1）可用性一般是在不同的機器之間通過數據的復制來實現
（2）一致性需要在允許讀操作之間同時更新幾個節點
（3）temporary partion，即幾點之間的通信延遲是可能發生了，此時就需要在A 和 C之間權衡。但只有在發生分區的時候才需要考慮權衡。
在分布式系統中，網絡分區一定會發生，因此“it is really just A vs C！”
回到頂部
在《通過一步步創建sharded cluster來認識MongoDB》一文中，對MongoDB的特性做了一些介紹，包括高性能、高可用、可擴展（水平伸縮），其中，MongoDB的高可用性依賴于replica set的復制與自動failover。對MongoDB數據庫的使用有三種模式：standalone，replica set， shareded cluster，在前文中詳細介紹了shared cluster的搭建過程。
standalone就是單個mongod，應用程序直接連接到這個Mongod，在這種情況下無分區容錯性可言，也一定是強一致性的。對于sharded cluster，每一個shard也都推薦是一個replica set。MongoDB中的shards維護的是獨立的數據子集，因此shards之間出現了分區影響不大（在chunk遷移的過程可能還是有影響），因此也主要考慮的是shard內部replica set的分區影響。所以，本文中討論MongoDB的一致性、可用性問題，針對的也是MongoDB的replica set。
對于replica set，只有一個primary節點，接受寫請求和讀請求，其他的secondary節點接受讀請求。這是一個單寫、多讀的情況，比多讀、多寫的情況還是簡化了許多。后文為了討論，也是假設replica set由三個基點組成，一個primary，兩個secondary，且所有節點都持久化數據（data-bearing）
MongoDB關于一致性、可用性的權衡，取決于三者：write-concern、read-concern、read-preference。下面主要是MongoDB3.2版本的情況，因為read-concern是在MongoDB3.2版本中才引入的。
write concern表示對于寫操作，MongoDB在什么情況下給予客戶端響應。包括下面三個字段：
{ w: <value>, j: <boolean>, wtimeout: <number> }
w: 表示當寫請求在value個MongoDB實例處理之后才向客戶端返回。取值范圍：
1：默認值，表示數據寫入到standalone的MongoDB或者replica set的primary之后返回
0：不用寫入就直接向客戶端返回，性能高，但可能丟數據。不過可以配合j：True來增加數據的可持久性（durability）
>1: 只有在replica set環境下才有用，如果value大于的replica set中節點的數目，那么可能導致阻塞
‘majority’： 當數據寫入到replica set的大多數節點之后向客戶端返回，對于這種情況，一般是配合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：表示當寫請求在寫入journal之后才向客戶端返回，默認為False。兩點注意：
如果在對于未開啟journaling的MongoDB實例使用j:True，會報錯
在MongoDB3.2及之后，對于w>1, 需要所有實例都寫到journal之后才返回
wtimeout：表示寫入的超時時間，即在指定的時間（number），如果還不能向客戶端返回（w大于1的情況），那么返回錯誤
默認為0，相當于沒有設置該選項
在MongoDB3.4中，加入了writeConcernMajorityJournalDefault.這么一個選項，使得w，j在不同的組合下情況下不同:
在前文已經講解過，一個replica set由一個primary和多個secondary組成。primary接受寫操作，因此數據一定是最新的，secondary通過oplog來同步寫操作，因此數據有一定的延遲。對于時效性不是很敏感的查詢業務，可以從secondary節點查詢，以減輕集群的壓力。
MongoDB指出在不同的情況下選用不同的read-reference，非常靈活。MongoDB driver支持一下幾種read-reference：
primary：默認模式，一切讀操作都路由到replica set的primary節點
primaryPreferred：正常情況下都是路由到primary節點，只有當primary節點不可用（failover）的時候，才路由到secondary節點。
secondary：一切讀操作都路由到replica set的secondary節點
secondaryPreferred：正常情況下都是路由到secondary節點，只有當secondary節點不可用的時候，才路由到primary節點。
nearest：從延時最小的節點讀取數據，不管是primary還是secondary。對于分布式應用且MongoDB是多數據中心部署，nearest能保證最好的data locality。
如果使用secondary或者secondaryPreferred，那么需要意識到：
(1) 因為延時，讀取到的數據可能不是最新的，而且不同的secondary返回的數據還可能不一樣；
(2) 對于默認開啟了balancer的sharded collection，由于還未結束或者異常終止的chunk遷移，secondary返回的可能是有缺失或者多余的數據
(3) 在有多個secondary節點的情況下，選擇哪一個secondary節點呢，簡單來說是“closest”即平均延時最小的節點，具體參加Server Selection Algorithm
read concern是在MongoDB3.2中才加入的新特性，表示對于replica set（包括sharded cluster中使用復制集的shard）返回什么樣的數據。不同的存儲引擎對read-concern的支持情況也是不一樣的
read concern有以下三個level：
local：默認值，返回當前節點的最新數據，當前節點取決于read reference。
majority：返回的是已經被確認寫入到多數節點的最新數據。該選項的使用需要以下條件： WiredTiger存儲引擎，且使用election protocol version 1；啟動MongoDB實例的時候指定 --enableMajorityReadConcern選項。
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， 返回的也不一定是最新的數據，這個和NWR理論并不是一回事。究其根本原因，在于最終返回的數值只來源于一個MongoDB節點，該節點的選擇取決于read reference。
在這篇文章中，對readconcern的引入的意義以及實現有詳細介紹，在這里只引用核心部分：
readConcern 的初衷在于解決『臟讀』的問題，比如用戶從 MongoDB 的 primary 上讀取了某一條數據，但這條數據并沒有同步到大多數節點，然后 primary 就故障了，重新恢復后 這個primary 節點會將未同步到大多數節點的數據回滾掉，導致用戶讀到了『臟數據』。
當指定 readConcern 級別為 majority 時，能保證用戶讀到的數據『已經寫入到大多數節點』，而這樣的數據肯定不會發生回滾，避免了臟讀的問題。
回顧一下CAP理論中對一致性 可用性的問題：
一致性，是指對于每一次讀操作，要么都能夠讀到最新寫入的數據，要么錯誤。
可用性，是指對于每一次請求，都能夠得到一個及時的、非錯的響應，但是不保證請求的結果是基于最新寫入的數據。
前面也提到，本文對一致性 可用性的討論是基于replica set的，是否是shared cluster并不影響。另外，討論是基于單個客戶端的情況，如果是多個客戶端，似乎是隔離性的問題，不屬于CAP理論范疇。基于對write concern、read concern、read reference的理解，我們可以得出以下結論。
默認情況（w：1、readconcern：local）如果read preference為primary，那么是可以讀到最新的數據，強一致性；但如果此時primary故障，那么這個時候會返回錯誤，可用性得不到保證
默認情況（w：1、readconcern：local）如果read preference為secondary（secondaryPreferred、primaryPreferred），雖然可能讀到過時的數據，但能夠立刻得到數據，可用性比較好
writeconern：majority保證寫入的數據不會被回滾; readconcern：majority保證讀到的一定是不會被回滾的數據
若（w：1、readconcern；majority）即使是從primary讀取，也不能保證一定返回最新的數據，因此是弱一致性
若（w: majority、readcocern：majority），如果是從primary讀取，那么一定能讀到最新的數據，且這個數據一定不會被回滾，但此時寫可用性就差一些；如果是從secondary讀取，不能保證讀到最新的數據，弱一致性。
回過來來看，MongoDB所說的高可用性是更普世意義上的可用性：通過數據的復制和自動failover，即使發生物理故障，整個集群還是能夠在短時間內回復，繼續工作，何況恢復也是自動的。在這個意義上，確實是高可用的。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
