分佈式理論 PACELC 瞭解麼？

時間 2021-04-21

標籤算法網絡異步分佈式 ide 函數設計 code 中間件 blog 欄目系統架構简体版

原文原文鏈接

PACELC 基於 CAP 理論演進而來。算法

CAP 理論是一個分佈式系統中老生常談的理論了：網絡

C（Consistency）：一致性，全部節點在同一時間的數據徹底一致。
A（Availability）：可用性，服務一直可用。
P（Partition tolerance）：分區容錯性，遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性和可用性的服務

系統設計中，這三點只能取其二，通常的分佈式系統要求必須有分區容錯性。剩下的只能從 C 或者 A 中取捨。異步

可是這個理論並不能很好地應用於實際，首先， A 中是有必定爭議的，很長時間才返回，雖然可用，可是業務上可能不能接受。而且，系統大部分時間下，分區都是平穩運行的，並不會出錯，在這種狀況下，系統設計要均衡的實際上是延遲與數據一致性的問題，爲了保證數據一致性，寫入與讀取的延遲就會增高。這就引出了 PACELC 理論。分佈式

在出現分區錯誤的狀況下，取前半部分 PAC，理論和 CAP 內容一致。沒有出現分區錯誤的狀況下（PACELC 中的 E 表明 Else），取 LC，也就是 Latency（延遲）與 Consistency（一致性）。ide

如今，其實不少存儲，都已經實現了不一樣的 PACELC 的兼顧策略，而且交由用戶配置去靈活根據不一樣業務場景使用不一樣的策略。函數

DynamoDB，Riak，Cassandra 的 NWR 模型

例如 DynamoDB 和 Riak 還有 Cassandra 都是 Dynamo 理論論文的基於一致性哈希寫多份實現最終一致性的存儲，在默認狀況下，是 P+A 以及 E+L 的系統，可是能夠根據配置修改，主要基於NWR模型與同步和異步備份。N 表明 N 個備份，W 表明要寫入至少 W 份才認爲成功，R 表示至少讀取 R 個備份。配置的時候要求 W+R > N。由於 W+R > N，因此 R > N-W。這個是什麼意思呢?就是讀取的份數必定要比總備份數減去確保寫成功的倍數的差值要大。
也就是說，每次讀取，都至少讀取到一個最新的版本。從而不會讀到一份舊數據。當咱們須要高可寫的環境的時候(例如，amazon 的購物車的添加請求應該是永遠不被拒絕的)咱們能夠配置W = 1 若是N=3 那麼R = 3。這個時候只要寫任何節點成功就認爲成功，可是讀的時候必須從全部的節點都讀出數據。若是咱們要求讀的高效率，咱們能夠配置 W=N R=1。這個時候任何一個節點讀成功就認爲成功，可是寫的時候必須寫全部三個節點成功才認爲成功。
你們注意，一個操做的耗時是幾個並行操做中最慢一個的耗時。好比R=3的時候，其實是向三個節點同時發了讀請求，要三個節點都返回結果才能認爲成功。假設某個節點的響應很慢，它就會嚴重拖累一個讀操做的響應速度。設計

MongoDB

MongoDB 和上面的 Dynamo 相似，MongoDB關於一致性、可用性的權衡，取決於三者： code

write-concern: 表示當寫請求在value個MongoDB實例處理以後才向客戶端返回
read-concern: 設定是否必須從 primary 讀取最新的數據仍是能夠從 secondary 讀取最終一致性的數據。
read-preference: 對於replica set，是返回當前節點的最新數據，仍是返回寫入節點最多的數據，仍是根據一些函數計算出的數據。

MySQL 同步

MySQL主從複製包括異步模式、半同步模式、全同步複製中間件

默認狀況下是異步模式，MySQL 一主多從部署讀寫分離的狀況下，實現的爲最終一致性，若是考慮必定延遲能夠接受，通常能夠經過 show slave status來查看主從延遲從而決定數據是否能夠從 slave 讀取。 MyCat 等中間件就是用了這種機制。能夠經過對於這個時延的容忍性，控制 L 與 C 的取捨以及 A 與 C 的取捨。blog

全同步複製：指當主庫執行完一個事務，全部的從庫都執行了該事務才返回給客戶端。這樣保證了強一致性，可是響應時間變長了。

半同步複製：主庫在執行完客戶端提交的事務後不是馬上返回給客戶端，而是等待至少一個從庫接收到並寫到 relay log 中才返回給客戶端。這樣雖然仍是有延遲，可是延遲小了不少而且數據相比於異步複製更加不容易丟失。