CAP定理设计者二十年后再谈CAP

Eric Brewer目前正在推动Kubernetes和容器建设，在这篇采访中：

Google systems guru explains why containers are th，他认为容器是云计算的未来。

Docker之类容器你可以在本地笔记本或电脑上运行，然后你同样部署到云上运行，当在云上运行时，Kubernetes能够以一种可控的方式升级容器从而实现运行管理一批容器，如同一个大型船队或舰队一样，你可以控制它们的流量访问量，可以指定多少个容器来扩展支撑一个服务的运行，随着访问量提升，你通过增加容器数量能够整个系统的负载能力。

当前云计算的App引擎并不通用，Heroku适合与Salesforce相关的网站系统；而Yard引擎适合Ruby on Rails方面的开发应用。而Google的App引擎视图通过可管理的VM变得通用，App引擎正确的抽象应该是一个容器，

下面谈到了CAP，CAP定理三个属性只能取得两个：

2.可用性，系统应当是在线运行，可以与用户形成交互。(banq注：有一些人认为CAP定理不包含延迟，其实可用性中有延迟的概念，如果系统等待半天没有响应，延迟很长，用户不知道是服务器死机了还是没有缓过来，可能就离开不用了，这种系统当然没有可用性。)

3.为了容错而进行的分区，(banq注：为了保证可靠性，你会将数据分成两个或更多组实现分区，这样，其中一台服务器当机时，数据不会丢失。)，当你将数据分区到几个服务器上时，你以为一份数据有两份或多份，很可靠了，但是服务器之间的网络连接会断线，那么这时你就不能又要一致性，又要可用性了，只能在这两者之间选择一个。

举例，ATM机有时会和银行主机房失联，问题是，在失联状态如果有用户等待吐钱取款，它到底吐不吐钱出来呢？如果它吐钱，那它是可用的，但是会不一致，因为ATM机器内账户钱少了，但是由于失联，银行主机数据库对应的账户钱没有少，也就是说，实际上你的银行账户中钱并没有因为ATM吐钱出来了而减掉这一笔钱。在实际运行中，ATM也是选择可用性，在失联状态吐钱会有一个上限，比如200美金，第一次可以这样，第二次ATM就不会傻到再吐钱了。

这里关键来了，我们是允许事件变得不一致的，然后在其发生以后，会找到一种途径对这个错误进行补偿。（亡羊补牢为时未晚），这些与试图阻止错误的预防模式一起解决问题。

让不一致发生，事后通过校订Auditing探测发现它们，你如，你下订单时出现错误，下了两次订单，忘记取消了，厂商也将货物发送给你了，那么纠正补偿还是很容易的，厂商只要将货物拿回即可。

所以，通常情况是，允许数据变得不一致，你需要发现纠正的方法，实际上，财务系统这样注重数据一致性的系统，其实不是基于真正一致性，而是基于校订auditing和纠正补偿，他们以前是不知道CAP理论的，所以，这是一种实践中正确的方式。

点评：Eric Brewer这篇访谈可谓是文章Please stop calling databases CP or AP请停止称呼数据库CP或AP)的反击，该文如同以前其他文章一样不断质疑CAP理论，而人们在这些质疑中愈加深入了对CAP理论的理解，进而更加广泛地用CAP理论对分布式系统进行定义描述。

================================================

感谢 Coding 和 UPYUN 对本微信的支持。Coding.net 是一个面向开发者的云端开发平台，目前提供代码托管、运行空间、质量控制、项目管理等功能。

upyun.com是国内领先的云服务提供商，专注于提供静态文件的云存储、云处理和CDN加速服务。现在注册，即可免费体验！