《區塊鏈技術指南》筆記-CAP原理

定義

分散式運算系統不可能同時確保一致性（Consistency）、可用性（Availability）和分區容忍性（Partition），設計中往往需要弱化對某個特性的保證。 一致性（Consistency）：任何操作應該都是原子的，發生在後面的事件能看到前面事件發生導致的結果，注意這裡指的是強一致性； 可用性（Availability）：在有限時間內，任何非失敗節點都能應答請求； 分區容忍性（Partition）：網路可能發生分區，即節點之間的通訊不可保障。

比較直觀地理解，當網路可能出現分區時候，系統是無法同時保證一致性和可用性的。要麼，節點收到請求後因為沒有得到其他人的確認就不應答，要麼節點只能應答費一致的結果。
好在大部分時候網路都被認為是可靠的，因此系統可以提供一致可靠的服務；當網路不可靠時，系統要麼犧牲掉一致性（大部分時候都是如此），要麼犧牲掉可用性。 應用情境

既然CAP不可同時滿足，則設計系統時候必然要弱化對某個特性的支援。 弱化一致性

對結果一致性不敏感的應用，可以允許在新版本上線後過一段時間才更新成功，期間不保證一致性。
例如網站靜態頁面內容、即時性較弱的查詢類資料庫等，CouchDB、Cassandra等為此設計。 弱化可用性

對結果一致性很敏感的應用，例如銀行取款機，當系統故障時候會拒絕服務。MongoDB、Redis等為此設計。
Paxos、Raft等演算法，主要處理這種情況。 弱化分區容忍性

現實中，網路磁碟分割出現機率較小，但較難避免。某些關係型資料庫、ZooKeeper即為此設計。
實踐中，網路通過雙通道機制增強可靠性，達到高穩定性的網路通訊。