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

banq 15-05-17
    

CAP定理设计者Eric Brewer作为Google基础设施副总裁在时隔二十年后重谈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定理三个属性只能取得两个:
1. 一致性,意味着系统中所有服务器能达成数据值的一致性,比如你有一个银行账户,每个服务器都应该同意银行账户的数值是多少,也就是说,银行账户的数值应该在所有服务器上是一样的。

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理论对分布式系统进行定义描述。

    

3