`references:` 1. http://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
2. http://en.wikipedia.org/wiki/CAP_theorem
3. http://www.royans.net/arch/brewers-cap-theorem-on-distributed-systems/
4. http://tianhailong.com/cap%e7%90%86%e8%ae%ba.html **Brewers CAP Theorem on distributed systems** Large distributed systems run into a problem which smaller systems don’t usually have to worry about. >It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time. 
 - `Consistency` : 所有节点在同一时间具有相同的数据 Example1: 只有单独一个节点，自然满足一致性
Example2: 假设要存放的数据的keys为A-Z，将key为A-M的数据存放在节点1，将key为N-Z的数据存放在节点2，这样系统也能保证一致性
Example3: Master-Master replicas, 每一个节点存放的是相同的副本。当要插入一条数据时，必须两个节点都完成该插入操作，这个插入才算完成。在这种存在副本的系统里，为了保证100%的一致性，节点之间的通信就十分重要，整个系统的性能也会随着副本的增加而降低。
- `Availability` : 保证每个请求不管成功还是失败都有响应 Example1: not hightly **Available**，如果节点宕机，100%的数据将会unavailable
Example2: not hightly **Available**，如果有一个节点宕机， 50%的数据将unavailable
Example3: 单独一个节点就能保证100%的**availability**，增加备份节点数，将直接增加系统的**availability**
- `Partition tolerance` : 系统中任意信息的丢失或失败不会影响系统的继续运作 我们选择Example3中的架构来得到**Consistency**和**Availability**，假设Example3中的两个节点存在两个不同的数据中心，并且假设两个数据中心之间的网络连接中断，也即两个数据中心无法同步它们之间的状态。在这种情况下，如果系统允许读写操作，那么在这两个数据中心之间的数据就无法保持**Consistency**，如果系统不允许读写操作，那么虽然系统保持了**Consistency**，但却失去了**Availability** 举个例子：对于银行系统来说，数据的一致性显示十分重要。比如某个客户在广州取钱，那么在北京必须在限定时间内正确的反映该客户的余额数。那么如果广州的数据节点和北京的数据节点出现网络不顺畅时，系统必须禁止写入操作来保证Consistency，这就失去了Availability **Usage of CAP Theorem in Today's Distributed Storage Systems** 因为CAP理论中的三点只能同时满足两点，而在现实世界中，由于机器故障是一直存在着的，所以必须满足Partition tolerance，那么就只有在剩下的Consistency和Availability根据不同应用的需求做权衡了。当然选择其中的一个，并不意味着彻底放弃另一个。 1. 如果某个应用更重视Availability，比如说购物车。那么它应该先优化Availability，然后再解决Consistency问题（eventually consistent）
2. 如果某个应用更重视Consistency，比如说银行取款机。那么它应该优先考虑Consistency，而放弃Availability © `Senlie Zheng` 转载请注明出处