Java生鮮電商平臺-CAP理論在大型互聯網系統中的應用
說明：本文介紹在大型Java生鮮電商中,CAP理論在大型互聯網系統中的應用
在計算機領域，如果是初入行就算了，如果是多年的老碼農還不懂CAP 定理，那就真的說不過去了。CAP 可是每一名技術架構師都必須掌握的基礎原則啊。
現在只要是稍微大一點的互聯網項目都是採用分佈式結構了，一個系統可能有多個節點組成，每個節點都可能需要維護一份數據。那麼如何維護各個節點之間的狀態，如何保
障各個節點之間數據的同步問題就是大家急需關注的事情了。
CAP 定理是分佈式系統中最基礎的原則。所以理解和掌握了CAP，對系統架構的設計至關重要。
CAP 定理（CAP theorem）又被稱作布魯爾定理(Brewer's theorem)，是加州大學伯克利分校的計算機科學家--埃裏克·布魯爾（Eric Brewer），在2000 年的ACM PODC 上提出的一個猜想。2002 年，麻省理工學院的賽斯·吉爾伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）發表了布魯爾猜想的證明，使之成爲分佈式計算領域公認的一個定理。CAP 定理，指的是在一個分佈式系統（指互相連接並共享數據節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲，如圖4-6 所示。
圖4-6 CAP 理論
CAP 分別表示的含義：
一致性（Consistency）， 對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作結
果。一致性又可分爲：弱一致性、強一致性、最終一致性，感興趣可以查看相關文檔。
可用性（Availability），非故障的節點在合理的時間內返回合理的響應（不是錯誤和超時
的響應）。可用性模式可分成：工作到備用切換（Active-passive）、雙工作切換（Active-active）
分區容錯性（Partition Tolerance），當出現網絡分區後，系統能夠繼續履行職責。
CAP 定理在互聯網大型分佈式系統中的應用
雖然CAP 理論定義是三個要素中只能取兩個，但放到分佈式環境下來思考的話，我們會發
現必須選擇P(分區容錯)要素，因爲網絡本身無法做到100%可靠，有可能出故障，所以分區是
一個必然的選項。
如果我們選擇了CA 而放棄了P，那麼當發生分區現象時，爲了保證C，系統需要禁止寫入，
當有寫入請求時，系統返回error，這又和A 衝突了，因爲A 要求返回no error 和no timeout。
因此，分佈式系統理論上不可能選擇CA 架構，只能選擇CP 或者AP 架構。
圖4-7 CP - Consistency/Partition Tolerance
如圖4-7 所示，爲了保證一致性，當發生分區現象後，N1 節點上的數據已經更新到y，但由於N1 和N2 之間的複製通道中斷，數據y 無法同步到N2，N2 節點上的數據還是這時客戶端C 訪問N2 時，N2 需要返回Error，提示客戶端面C：“系統現在發生錯誤”，
這種處理方式違背了可用性（Availability）的要求，因此CAP 三者只能滿足CP。
圖4-8 AP - Availability/Partition Tolerance
如圖4-8 所示，爲了保證可用性，當發生分區現象後，N1 節點上的數據已經更新到y，但
由於N1 和N2 之間的複製通道中斷，數據y 無法同步到N2，N2 節點上的數據還是x。
這時客戶C 訪問N2 時，N2 將當前自己擁有的數據x 返回給客戶端C 了，而實際上當前最
新的數據已經是y 了，這就不滿足一致性（Consistency）的要求了，因此CAP 三者只能滿足
AP。
注意：這裏N2 節點返回的x，雖然不是一個“正確”的結果，但是一個“合理”的結果，
因爲x 是舊的數據，並不是一個錯亂的值，只是不是最新的數據而已。
CAP 定理的應用，有哪些注意事項？
瞭解了CAP 定理後，對於開發者而言，當我們構建服務的時候，就需要根據業務特性進行
權衡考慮，哪些點是當前系統可以取捨的，哪些是應該重點保障的。
CAP 關注的粒度是數據，而不是整個系統。
C 與A 之間的取捨可以在同一系統內以非常細小的粒度反覆發生，而每一次的決策可能因
爲具體的操作，乃至因爲牽涉到特定的數據或用戶有所不同。
以一個商家管理系統爲例，商家管理系統包含商家賬號數據（商家ID、密碼）、商家信息
數據（行業類別、公司規模、營收規模等）。通常情況下，商家賬號數據會選擇CP，而商家信
息數據會選擇AP，如果限定整個系統爲CP，則不符合用戶信息的應用場景；如果限定整個系統
爲AP，則又不符合商家賬號數據的應用場景。
所以在CAP 理論落地實踐時，我們需要將系統內的數據按照不同的應用場景和要求進行分
類，每類數據選擇不同的策略（CP 或AP），而不是直接限定整個系統所有數據都是同一策略。
CAP 是忽略網絡延遲的。
這是一個非常隱含的假設，布魯爾在定義一致性時，並沒有將延遲考慮進去。即當事務提
交時，數據能夠瞬間複製到所有節點。但實際情況下，尤其是互聯網架構之下，從節點A 複製
數據到節點B，總是需要花費一定時間的。如果在相同機房可能是幾毫秒，如果跨機房，可能
是幾十毫秒。這也就是說，CAP 理論中的C 在實踐中是不可能完美實現的，在數據複製的過程
中，節點A 和節點B 的數據並不一致。
正常運行情況下，不存在CP 和AP 的選擇，可以同時滿足CA。
CAP 理論告訴我們分佈式系統只能選擇CP 或者AP，但其實這裏的前提是系統發生了“分區”
現象。如果系統沒有發生分區現象，也就是說P 不存在的時候（節點的網絡連接一切正常），我
們就沒有必要放棄C 或者A，應該C 和A 都可以保證，這就要求架構設計的時候即要考慮分區
發生時選擇CP 還是AP，也要考慮分區沒有發生時如何保證CA。
這裏我們還以用戶管理系統爲例，即使是實現CA，不同的數據實現方式也可能不一樣：用
戶賬號數據可以採用“消息隊列”的方式來實現CA，因爲消息隊列可以比較好地控制實時性，
但實現起來就複雜一些；而用戶信息數據可以採用“數據庫同步”的方式來實現CA，因爲數據
庫的方式雖然在某些場景下可能延遲較高，但使用起來簡單。
放棄並不等於什麼都不做，需要爲分區恢復後做準備。
CAP 理論告訴我們三者只能取兩個，需要“犧牲”（sacrificed）另外一個，這裏的“犧
牲”是有一定誤導作用的，因爲“犧牲”讓很多人理解成什麼也不做。實際上，CAP 理論的“犧
牲”只是說在分區過程中我們無法保證C 或者A，但並不意味着什麼都不做。分區期間放棄C
或者A，並不意味着永遠放棄C 和A，我們可以在分區期間進行一些操作，從而讓分區故障解決
後，系統能夠重新達到CA 的狀態。
最典型的就是在分區期間記錄一些日誌，當分區故障解決後，系統根據日誌進行數據恢復，
使得重新達到CA 狀態。
CAP 是非常重要的架構理論，有志於成爲架構師的朋友，對於CAP、ACID、BASE 等定理，
一定要有比較深的理解和認識，把基礎打紮實。
結語
覆盤與總結.
總結：
做Java生鮮電商平臺的互聯網應用，無論是生鮮小程序還是APP，系統中臺的CAP系統設計的思路是非常重要的，本文只是起一個拋磚引玉的作用，
希望用生鮮小程序的系統CAP的概念架構思路實戰經驗告訴大家一些實際的項目經驗，希望對大家有用.
QQ:137071249
共同學習QQ羣：793305035