4.4.2　应用场景

既然CAP三种特性不可同时得到保障，则设计系统时必然要弱化对某个特性的支持。

1.弱化一致性

对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才最终更新成功，期间不保证一致性。

例如，网站静态页面内容，实时性较弱的查询类数据库，简单分布式同步协议（如Gossip），以及CouchDB、Cassandra数据库等，都为此设计。

2.弱化可用性

对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce等为此设计。

Paxos、Raft等共识算法，主要处理这种情况。在Paxos类算法中，可能存在着无法提供可用结果的情形，同时允许少数节点离线。

3.弱化分区容忍性

现实中，出现网络分区的概率较小，但很难完全避免。

两阶段的提交算法，某些关系型数据库，以及ZooKeeper主要考虑了这种设计。

实践中，网络可以通过双通道等机制增强可靠性，实现高稳定的网络通信。