分散式系統設計權衡之CAP
寫在最前：
1.為什麼學習並記錄分散式設計理念一系列相關的東西
在日常工作中系統設計評審的時候，經常會有一些同事丟擲一些概念,高可用性，一致性等等字眼，他們用這些最基本的概念去反駁系統最初的設計，但是很多人理解的可用性,一致性等等問題，都是自己拍腦袋想的，或者根本和最原始表達的意思就不是一個東西，在這種情況下PK，就像不再一個頻段的人在交流，除了爭論，沒有任何實質性的進展，所以有必要熟悉其理論基礎，以免貽笑大方。（其實類似的例子還有很多，國內的技術人員都喜歡把一些此詞模糊化，混淆而談。例如XX雲，實際賣的就是vps 和一小部分saas,這就叫cloud computing?）
2.準備說哪些東西
分散式系統設計在評審時，爭論得最多的地方，其實也就是著名的cap理論，本文也主要對CAP理論加以自己的理解和應用
CAP理論
什麼是分散式系統
部分在不同的節點上，通過網路協同工作的系統叫做分散式系統
CAP分別代表什麼
• Consistency
• (all nodes see the same data at the same time)
• Availability
• Reads and writes always succeed.
• Partition tolerance
• (the system continues to operate despite arbitrary message loss or failure of part of the system)
一致性： 更新操作成功並返回客戶端完成後,分散式的所有節點在同一時間的資料完全一致
可用性: 讀和寫操作都能成功
分割槽容錯性：再出現網路故障導致分散式節點間不能通訊時，系統能否繼續服務
CAP的是什麼關係
It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time.
在分散式系統的設計中，沒有一種設計可以同時滿足一致性，可用性，分割槽容錯性 3個特性
注意：不要將弱一致性，最終一致性放到CAP理論裡混為一談（混淆概念的坑真多）
弱一致性，最終一致性 你可以認為和CAP的C一點關係也沒有，因為CAP的C是更新操作完成後，任何節點看到的資料完全一致, 弱一致性。最終一致性本身和CAP的C一致性是違背的，所以你可以看到那些謊稱自己系統同時具備CAP 3個特性是多麼的可笑，可能國內更多的場景是：一個開放人員一旦走上講臺演講，就立馬轉變為了營銷人員，連最基本的理念也不要了。
這裡有一篇標題很大的文章 cap-twelve-years-later-how-the-rules-have-changed ，實際上本文的changed更多的是在思考方式上，而本身CAP理論是沒有changed的
為什麼會是這樣
我們來看一個簡單的問題, 一個DB服務 搭建在兩個機房（北京,廣州)，兩個DB例項同時提供寫入和讀取
1. 假設DB的更新操作是同時寫北京和廣州的DB都成功才返回成功
在沒有出現網路故障的時候，滿足CA原則，C 即我的任何一個寫入，更新操作成功並返回客戶端完成後,分散式的所有節點在同一時間的資料完全一致， A 即我的讀寫操作都能夠成功，但是當出現網路故障時，我不能同時保證CA，即P條件無法滿足
2. 假設DB的更新操作是隻寫本地機房成功就返回，通過binlog/oplog回放方式同步至側邊機房
這種操作保證了在出現網路故障時,雙邊機房都是可以提供服務的，且讀寫操作都能成功，意味著他滿足了AP ，但是它不滿足C，因為更新操作返回成功後，雙邊機房的DB看到的資料會存在短暫不一致，且在網路故障時，不一致的時間差會很大（僅能保證最終一致性）
3. 假設DB的更新操作是同時寫北京和廣州的DB都成功才返回成功且網路故障時提供降級服務
降級服務，如停止寫入，只提供讀取功能，這樣能保證資料是一致的，且網路故障時能提供服務，滿足CP原則，但是他無法滿足可用性原則
選擇權衡
通過上面的例子，我們得知，我們永遠無法同時得到CAP這3個特性，那麼我們怎麼來權衡選擇呢？
選擇的關鍵點取決於業務場景
對於大多數網際網路應用來說（如網易門戶），因為機器數量龐大，部署節點分散，網路故障是常態，可用性是必須需要保證的，所以只有設定一致性來保證服務的AP，通常常見的高可用服務吹噓5個9 6個9服務SLA穩定性就本都是放棄C選擇AP
對於需要確保強一致性的場景，如銀行，通常會權衡CA和CP模型，CA模型網路故障時完全不可用，CP模型具備部分可用性，實際的選擇需要通過業務場景來權衡（並不是所有情況CP都好於CA，只能檢視資訊不能更新資訊有時候從產品層面還不如直接拒絕服務）
延伸
BASE(Basically Available, Soft State, Eventual Consistency 基本可用、軟狀態、最終一致性) 對CAP AP理論的延伸, Redis等眾多系統構建與這個理論之上
ACID 傳統資料庫常用的設計理念, ACID和BASE代表了兩種截然相反的設計哲學，分處一致性-可用性分佈圖譜的兩極。
擴充套件閱讀
Daniel Abadi認為 CAP 應該叫 PACELC http://dbmsmusings.blogspot.jp/2010/04/problems-with-cap-and-yahoos-little.html
Brewer's CAP Theorem http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
Foundationdb 的CAP權衡選擇 https://foundationdb.com/white-papers/the-cap-theorem
相關推薦
分散式系統設計權衡之CAP
寫在最前： 1.為什麼學習並記錄分散式設計理念一系列相關的東西 在日常工作中系統設計評審的時候，經常會有一些同事丟擲一些概念,高可用性，一致性等等字眼，他們用這些最基本的概念去反駁系統最初的設計，但是很多人理解的可用性,一致性等等問題，都是自己拍腦袋想的，或者根本和最原始表達的意思就不是一個東西，在這種情
分散式系統設計權衡之CAP(一致性,可用性,分割槽容錯性)
寫在最前： 1.為什麼學習並記錄分散式設計理念一系列相關的東西 在日常工作中系統設計評審的時候，經常會有一些同事丟擲一些概念,高可用性，一致性等等字眼，他們用這些最基本的概念去反駁系統最初的設計，但是很多人理解的可用性,一致性等等問題，都是自己拍腦袋想的，或者根本和最
分散式系統設計的求生之路
在這個資訊爆炸的時代，人們已然被大量、快速並且簡短的資訊所包圍。然而，我們相信：過多“快餐”式的閱讀只會令人“虛胖”，缺乏實質的內涵。伯樂線上內容團隊正試圖以我們微薄的力量，把優秀的原創文章和譯文分享給讀者，為“快餐”新增一些“營養”元素。
分散式系統設計：批處理模式之事件驅動的批處理
在前面一篇文章中，我們看到了一個通用的作業處理框架，以及一些簡單的作業佇列處理的程式。作業佇列非常適合將一個輸入轉化為一個輸出，但是，有許多批處理應用程式需要執行多個操作，或者需要將單個數據輸入生成為多種不同的輸出。在這種情況下，我們開始將作業佇列連線在
分散式系統設計：批處理模式之協調批處理
前面的章節描述了一系列將佇列拆分和連線在一起以實現更復雜批處理的模式，複製和生成多個不同的輸出是批處理的重要組成部分，但有時將多個輸出合併到一起以生成某種聚合輸出也同樣很重要，如圖1所示。 這種聚合最典型的例子是MapReduce模式中的Reduc
一文帶你重新審視CAP理論與分散式系統設計
這是一篇來自微信公眾號的文章，如果圖片看不到，可直接跳轉到文章出處檢視：https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650765365&idx=1&sn=75c9b2050c31
分散式系統設計：批處理模式之作業佇列系統
之前的文章講述了關於可靠的、長時間執行的應用（long-running server applications）的設計模式，本篇介紹批處理的模式。與先前介紹的長時間執行應用所不同的是，批處理的過程預計只能執行很短的時間。例如，通過彙總使用者的資料來分析每
程式設計師修神之路--分散式系統設計理念這麼難學？
### 分散式系統 身為二十一世紀的一名程式設計師，沒聽說過分散式系統就顯得自己好像沒有女票一樣尷尬。無論是出去面試跟面試官吹水，還是在工作中和同事吹水，分散式系統永遠是你顯得高人一等的籌碼。分散式系統已經誕生了好幾十年，說起來比我們八零後程序員好要老成，隨著現代網際網路的崛起，對於系統在效能，可靠性上的要求
圖解分散式系統架構演進之路
介紹 分散式和叢集的概念經常被搞混，現在一句話讓你明白兩者的區別。 分散式：一個業務拆分成多個子業務，部署在不同的伺服器上 叢集：同一個業務，部署在多個伺服器上 例如：電商系統可以拆分成商品，訂單，使用者等子系統。這就是分散式，而為了應對併發，同時部署好幾個使用者系統，這就是
ceph儲存分散式系統設計系列 -- 基本原理及高可用策略
“分散式系統設計”系列第一篇文章，這篇文章主要介紹一些入門的概念和原理，後面帶來一些高可用、資料分佈的實踐方法！！ ==> 分散式系統中的概念 ==> 分散式系統與單節點的不同 ==> 分散式系統特性 ==> 分散式系統設計策略 ==>
《機器學習系統設計》之應用scikit-learn做文字分類（上）
前言： 本系列是在作者學習《機器學習系統設計》（[美] WilliRichert）過程中的思考與實踐，全書通過Python從資料處理，到特徵工程，再到模型選擇，把機器學習解決問題的過程一一呈現。書中設計的原始碼和資料集已上傳到我的資源：http://download
分散式系統設計理念
首先，分散式系統的首要目的是提升系統的整體效能和吞吐量。如果最終設計出來的分散式系統佔用了10臺機器才勉強達到單機系統的兩倍效能，那麼這個分散式系統還有存在的價值嗎？另外，即使採用了分散式架構，也仍然需要盡力提升單機上的程式效能，使得整體效能達到最高。所以，我們
《機器學習系統設計》之應用scikit-learn做文字分類（下）
# inspired by http://scikit- # learn.org/dev/auto_examples/cluster/plot_kmeans_digits.html#example- # cluster-plot-kmeans-digits-py import os import scipy
高併發服務端分散式系統設計概要（上）
又是快一年沒寫部落格了，2013年也只剩尾巴，也不知道今年都忙了些什麼。寫這篇文章的目的，主要是把今年以來學習的一些東西積澱下來，同時作為之前文章《高效能分散式計算與儲存系統設計概要》的補充與提升，然而本人水平非常有限，回頭看之前寫的文章也有許多不足，甚至是
轉載：淺析海量使用者的分散式系統設計
我們常常會聽說，某個網際網路應用的伺服器端系統多麼牛逼，比如QQ、微信、淘寶。那麼，一個網際網路應用的伺服器端系統，到底牛逼在什麼地方？為什麼海量的使用者訪問，會讓一個伺服器端系統變得更復雜？本文就是想從最基本的地方開始，探尋伺服器端系統技術的基礎概念。
分散式系統設計系列 -- 基本原理及高可用策略
”分散式系統設計“系列第一篇文章，這篇文章主要介紹一些入門的概念和原理，後面帶來一些高可用、資料分佈的實踐方法！！ 各位親，如果你們覺得本文有還不錯的地方，請點選“投一票”支援本文，多謝！ ==> 分散式系統中的概念 ==> 分散式系統與單節點
高併發服務端分散式系統設計概要（中）
上篇我們完成了在此分散式系統中，一個group的設計。那麼接下來，我們設計系統的其他部分。如前文所述，我們的業務及其資料以group為單位，顯然在此係統中將存在many many的groups（別告訴我你的網站總共有一個業務，像我們的“山推”，那業務是一堆一堆地），那麼由誰來管理這些groups呢？由Web
分散式系統事務一致性到CAP,BASE理論
首先，要聊的就是資料庫事務四大特性(簡稱ACID) 1、原子性(Atomicity)：事務的原子性是指事務中的程式作為資料庫的邏輯工作單元，要麼全部成功，要麼全部失敗。 2、一致性（Consistency）：事務一致性是指事務執行之前和執行之後資料保持一
分散式系統設計原則
一、分散式系統基礎理論CAP為分散式應用提供了理論基礎，C：Consistency（一致性），A：Availability（可用性），P：Partition tolerance（分割槽容錯性），但C代表強一致性，注意：不要將弱一致性，最終一致性放到CAP理論裡混
《機器學習系統設計》之k-近鄰分類演算法
前言： 本系列是在作者學習《機器學習系統設計》（[美] WilliRichert）過程中的思考與實踐，全書通過Python從資料處理，到特徵工程，再到模型選擇，把機器學習解決問題的過程一一呈現。書中設計的原始碼和資料集已上傳到我的資源：http://downloa