CAP理論：Consistency，Availability，Partition tolerance

對於一個分布式數據系統，CAP三要素不可兼得，至多實現其二。要麽AP，要麽CP，不存在CAP。分布式系統往往要求必須滿足P。

傳統關系數據庫選擇CA，NoSQL更關註AP。

CAP Reloaded：

關系數據庫ACID原則：Atomicity，Consistency，Isolation，Durability；更強調數據一致性

NoSQL系統BASE原則：Basically Available，Soft state，Eventual consistency；更強調數據可用性

冪等性（Idempotent）：

一致性模型分類：

副本更新策略：

延時和一致性做權衡

策略1-同時更新：

A 同一時刻的兩個寫請求，無法保證各副本操作順序一致

B 通過某種一致性協議確定執行順序

策略2-主從更新：

一個主副本（master replica），多個從副本（slave replica）。寫主副本，主副本轉發寫給從副本，主副本決定寫順序。

A 同步方式：主副本等待所有從副本寫完，視作操作完成。請求延時大

B 異步方式：主副本通知從副本寫之前視作完成。應對主副本未通知前崩潰的情形：指定存儲記錄此次寫操作（比如log文件）

1.讀請求都轉發給主副本：代價是高延時。eg：Chubby

2.所有副本可讀：代價是弱一致。eg：PNUTS，Zookeeper

C 同異步混合：主副本同步寫部分從副本，視作完成，異步寫其他從副本

1.讀的數據必須來自同步寫的節點：強一致，高延遲

2.同1相反

策略3-任意節點更新：

A 同步通知：強一致，高延時

B 異步通知：弱一致，低延時

一致性協議：

兩階段提交（two-phrase commit，2PC）協議：

解決分布式事務問題：實現ACID中原子性（Atomicity）。eg：Raft一致性協議用其保證信息更新原子性。

存在3個阻塞態：協調者的WAIT態，參與者的INIT態、READY態

解決阻塞問題：

1 超時判斷：協調者WAIT態若超時發Global-abort，參與者INIT態超時發Vote-abort

2 參與者互詢：參與者READY態超時不能abort事務，因為不確定協調者下發表決信息，所以需要互詢。

參與者P問參與者Q：

if Q=COMMIT then P:=COMMIT

if Q=ABORT then P:=ABORT

if Q=INIT then P:=ABORT

if Q=READY then P問其他參與者；最壞情形是其他參與者也都出於READY態，即長時阻塞（還好較少發生）

解決長時阻塞：協調者和參與者將自身狀態寫入本地log，崩潰重啟根據log恢復。

向量時鐘（vector clock）協議：

將時間戳和事件綁定進而判定事件因果依賴關系。

規則：

判斷因果關系：

例子：

Dynamo使用向量時鐘管理數據版本。

如有數據一致性沖突經向量時鐘無法判定，則交給客戶端（應用端）判定。

RWN協議：

R或W越大延遲越高。

可根據實際情況配置R和W的數值。

必須結合向量時鐘配合達到強一致性。

Paxos協議：

1. 副本狀態機模型（replicated state machines）

典型實現：Log副本方式

一致性協議作用是保證各個Log副本數據的一致性：一致性模塊（consensus module）

2. Paxos基本概念

3. Paxos協議機制

學習者獲取倡議：

Raft協議：

目標：可理解性，實現實際系統的確定性

基本概念

1. 領導者選舉

2. Log復制

（註：項目即item）

3. 安全性

《大數據日知錄》讀書筆記-ch2數據復制與一致性