Brewer’s CAP Theorem

概念

什么领域？解决什么问题or涉及什么问题？

• Consistency

一个服务是一致的完整操作或完全不操作（A service that is consistent operates fully or not at all，精确起见列出原文，也有人将其简称为数据一致性，我的理解这条是强调一个动作要么遵照约束完美的完成要么就什么也不做）。Gilbert 和Lynch在他们的证明中使用“atomic”而不是consistent，技术上来讲更准确，因为严格来说，当用在数据库事务的属性中时，consistent是指ACID中的C，其含义是如果数据违反了某些预设的约束（preset constraints）就不能被持久化（persisted）。

但可以这样来理解，

将其认为是分布式系统中的一个预设约束：不允许同一数据有不同的值，那么我认为这个抽象概念的漏洞就被堵住了。all nodes see the same data at the same time

在前面购书的例子中，你将书加入购物车或无法加入。支付成功或不成功。你无法部分加入或部分支付一本书。库存中只有一本书，当天只有一个人能得到它。如果2个客户都可以完成订单流程（如完成支付），那么仓库中的和系统中的不一致性就会导致问题。有时候这种不一致性可能问题不大，但如果将其扩大到数千个不一致性，并且涉及到金钱（例如：金融交易中关于买卖的东西和交易记录的内容不一致）就会是个大问题。

也许我们可以利用数据库来解决一致性问题。在（购书的）订单流程中的某个点减少《战争与和平》的库存记录。当其他的客户到达这个点的时候，书架空了，订单流程将会通知客户，而不会进行到支付环节（相比这是一个比较关键的环节）。这样第一个操作顺利完成，第二个操作则不会完成。数据库非常适合这种情况，因为数据库关注ACID属性，并且通过隔离性（Isolation）来保证一致性，这样当第一个客户会使得库存记录减1，同时购物车的记录加1，任何中间状态同第二个客户都是隔离的，当然第二个客户必须等待几百毫秒以便数据存储达到一致状态。

• Availability

可用性只是意味着服务是可用的（a guarantee that every request receives a response about whether it was successful or failed）。当你购书时期望得到反馈，而不是浏览器报告网站无法连接的信息。Gilbert 和Lynch在其CAP定理的证明中很好地指出了，可用性通常在你最需要的时刻背弃你。网站通常在业务最繁忙的时刻挂掉，因为网站压力最大。一个他人无法访问的服务对任何人都没有价值。

• Partition Tolerance

如果你的应用和数据库运行在一个机器上（忽略规模的问题并假定你的代码都没问题），你的服务器是作为一种原子处理单元（atomic processor）：要么工作要么不工作（例如：如果down机就不可用，但也不会造成数据不一致问题）。

the system continues to operate despite arbitrary message loss。

一旦开始将数据和逻辑分布在不同的节点上，就有形成partition的风险。假定网线被切断，partition就形成了，节点A无法和节点B通讯。由于Web提供的这种分布式能力，临时的partition是一个常见的情况，如之前说所的，在全球化的有多个数据中心的公司中这并不罕见。

Gilbert 和Lynch是这样定义partition tolerance的

除了整个网络的故障外，其他的故障（集）都不能导致整个系统无法正确响应。(No set of failures less than total network failure is allowed to cause the system to respond incorrectly)

请注意Brewer的注释，单节点partition就等同于服务器crash，因为如果无法连接它，那它就和不存在一样。

参考及扩展阅读

1. http://pt.alibaba-inc.com/wp/dev_related_728/brewers-cap-theorem.html