如何在系統設計中使用CAP定理？

banq發表於2017-12-13
什麼是CAP定理？在Consistency一致性, Availability可用性, Partition-tolerance分割槽容忍性三者之中只能選兩。

CP: 高一致性C和分割槽容忍性P的系統，放棄可用性A。
AP: 可用性A和分割槽容忍性P的系統，放棄高一致性C。
AC: 可用性A和高一致性C系統，放棄分割槽容忍性P。

根據CAP定理，存在網路分割槽的情況下，只能在可用性和一致性之間選擇。

以下面一個簡單案例為例，寫操作在主節點伺服器，讀操作在從節點伺服器：

CLient ----> Web-API -----> 分散式快取/DB(寫操作在主節點+讀操作在從節點)

假設有一個網路分割槽：

CLient ----> Web-API -----> 分散式快取/DB(主節點+ 這裡增加了網路分割槽 +從節點)

如果因為網路分割槽通訊出錯，導致主從伺服器節點無法同步資料，寫入主節點的資料，無法在從節點伺服器讀出。

我們只能做兩件事，在事務完成後傳送500錯誤響應給使用者，放棄了可用性，破壞使用者體驗，這是一種悲觀做法，另外一個樂觀做法是早點傳送200正確響應給使用者，放棄一致性，保住可用性，保住了使用者體驗。

哪個更好？沒有哪個更好，完全取決於場景情況決定。

那麼誰在兩個方案中做決定呢？如果是開發團隊，也許不太對，任何一種方法選擇需要根據以下因素決定：
1. 實現高一致性C的成本是多少？或者不一致性的成本是多少？
2.達到高可用性有多重要?還是仍出一個錯誤資訊更合適？
3.可以容忍多長的延遲？接近無窮大∞的高延遲等於沒有可用性。
4.方案複雜性如何？

那麼除了以上方案，有沒有可選的設計思路？

PACELC定理

PACELC定理如下：

If there is Partition,
       how does the system trade-off 
       between Availability and Consistency
Else
       how does the system trade-off
       between Latency and Consistency
<p class="indent">


如果有分割槽P，那就是在可用性和一致性之間平衡選擇。
否則，就是在延遲Latency和一致性之間平衡選擇。

高可用性和高一致性是我們完美的追求，但是存在網路分割槽情況下，魚和熊掌是不可兼得的。

變通方法：放棄一點高一致性，獲得一點高可用性(低延遲)，也就是最終一致性方式。

如何針對我們這個案例實現最終一致性？

1. 針對耗時的API呼叫使用非同步響應給使用者。
2. 在後臺做所有的寫操作工作。
3. 在資料庫叢集和快取達成共識，同時不讓使用者等待。

這樣做的結果是開發與業務兩個方面雙贏。

結論
在系統設計中考慮CAP定理是重要的。必須考慮整個系統的所有故障點。Casandra，Zoo Keeper，Kafka等技術可以在資料層面實現最終一致性。在AP和CP之間選擇並不容易。在大多數情況下，它取決於業務要求。



How we used CAP theorem in our system design? – Je

banq補充：CAP中P是網路分割槽容忍性的意思，實際中兩個資料中心就存在網路分割槽，因為資料中心之間的網路通訊很大部分不可靠，會出現網路故障，在出現網路通訊故障導致兩個資料中心之間訊息丟失，那麼這兩個分割槽是否還能各自獨立可用，如果可用，產生新的資料，就會不一致。網路分割槽P也可以存在於資料同步中，如果後臺有一個程式進行資料同步，那麼這個同步經常如果遭遇網路失敗是否重試，重試次數多少次？如果無限次重試，那麼就是選擇一致性C高於可用性A,反之，如果重試幾次以後就放棄希望人工介入，那麼就是一致性要求不那麼高，可用性A高於一致性了。

[該貼被admin於2018-01-04 17:46修改過]

相關文章