《分佈式服務架構：原理、設計與實戰》第二章完全解決分佈式系統一致性的問題

時間 2019-11-06

原文原文鏈接

一、什麼是一致性

一致性指分佈式服務化系統之間的弱一致性，包括應用系統的一致性和數據的一致性。不管是水平拆分仍是垂直拆分，都解決了特定場景下的特定問題，但拆分後的系統或者服務化的系統的最大問題就是一致性問題：如何保這麼多單一功能的模塊的信息、工做進度、狀態一致而且協調有序地工做？數據庫

二、一致性問題

下訂單和扣庫存緩存
同步調用超時網絡
異步回調超時數據結構
掉單架構
系統間狀態不一致併發
緩存和數據庫不一致異步
本地緩存節點間不一致分佈式
緩存數據結構不一致微服務

三、解決一致性問題的模式和思路

3.1 酸鹼平衡理論

ACID（酸）

A: Atomicity，原子性高併發

C: Consistency，一致性

I: Isolation，隔離性

D: Durability，持久性

關係型數據庫天生用於解決具備復瑣事務場景的問題，徹底知足ACID的特性。

具備ACID特性的數據庫支持強一致性，強一致性表明數據庫自己不會出現不一致，每一個事務都是原子的，或者成功或者失敗，事務間是隔離的，互相徹底不受影響，並且最終狀態是持久落盤的。

NoSQL徹底不適合交易場景，主要用來作數據分析、ETL、報表、數據挖掘、推薦、日誌處理、調用鏈跟蹤等非核心交易場景。

如今咱們來看看下訂單和扣庫存一致性問題，若是是在數據量較小的狀況下，能夠利用關係型數據庫的強一致性解決，也就是把訂單表和庫存表放在同一個關係型數據庫中，利用關係型數據庫進行下訂單和扣庫存兩個緊密相關的操做，達到訂單和庫存實時一致的結果。若是是大規模高併發的狀況，因爲業務規則的限制，沒法將相關數據分到同一個數據庫分片，這時就須要實現最終一致性。

CAP（帽子原理）

因爲對系統或者數據進行了拆分，咱們的系統再也不是單機系統，而是分佈式系統。

C: Consistency，一致性。在分佈式系統中的全部數據備份，在同一時刻具備一樣的值，全部節點在同一時刻讀取的數據都是最新的數據副本。

A: Availability，可用性，好的響應性能。徹底的可用性指的是在任何故障模型下，服務都會在有限的時間內處理完成並進行響應。

P: Partition tolerance，分區容忍性。儘管網絡上有部分消息丟失，但系統仍然可繼續工做。

CAP原理證實，任何分佈式系統只可同時知足以上兩點，沒法三者兼顧。因爲關係型數據庫是單節點無複製的，所以不具備分區容忍性，可是具備一致性和可用性，而分佈式的服務化系統都須要知足分區容忍性，那麼咱們必須在一致性和可用性之間進行權衡。

因此分佈式系統理論上不可能選擇CA架構，只能選擇CP或者AP架構。對於CP來講，放棄可用性，追求一致性和分區容錯性，咱們的zookeeper其實就是追求的強一致。對於AP來講，放棄一致性(這裏說的一致性是強一致性)，追求分區容錯性和可用性，這是不少分佈式系統設計時的選擇，後面的BASE也是根據AP來擴展。

BASE（鹼）

BASE思想解決了CAP提出的分佈式系統的一致性和可用性不可兼得的問題。BASE思想與ACID原理大相徑庭，它知足CAP原理，經過犧牲強一致性得到可用性，通常應用於服務化系統的應用層或者大數據處理系統中，經過達到最終一致性來儘可能知足業務的絕大多數需求。

酸鹼平衡理論，簡單來講就是在不一樣的場景下，能夠分別利用ACID和BASE來解決分佈式服務化系統的一致性問題。

BA: Basically Available，基本可用

S: Soft State，軟狀態，狀態能夠在一段時間內不一樣步

E: Eventually Consistent，最終一致，在必定的時間窗口內，最終數據達成一致便可

軟狀態是實現BASE思想的方法，基本可用和最終一致是目標。以BASE思想實現的系統因爲不保證強一致性，全部系統在處理請求的過程當中存在短暫的不一致，在短暫的不一致的時間窗口內，請求處理處於臨時狀態中，系統在進行每步操做時，經過記錄每一個臨時狀態，在系統出現故障時能夠從這些中間狀態繼續處理未完成的請求或者退回到原始狀態，最終達到一致狀態。