4.4.2　應用場景

既然CAP三種特性不可同時得到保障，則設計系統時必然要弱化對某個特性的支持。

1.弱化一致性

對結果一致性不敏感的應用，可以允許在新版本上線后過一段時間才最終更新成功，期間不保證一致性。

例如，網站靜態頁面內容，實時性較弱的查詢類數據庫，簡單分布式同步協議（如Gossip），以及CouchDB、Cassandra數據庫等，都為此設計。

2.弱化可用性

對結果一致性很敏感的應用，例如銀行取款機，當系統故障時候會拒絕服務。MongoDB、Redis、MapReduce等為此設計。

Paxos、Raft等共識算法，主要處理這種情況。在Paxos類算法中，可能存在著無法提供可用結果的情形，同時允許少數節點離線。

3.弱化分區容忍性

現實中，出現網絡分區的概率較小，但很難完全避免。

兩階段的提交算法，某些關系型數據庫，以及ZooKeeper主要考慮了這種設計。

實踐中，網絡可以通過雙通道等機制增強可靠性，實現高穩定的網絡通信。