【理论】CAP理论 - Brewer's CAP Theorem

先来看看CAP的具体含义是什么，这里是Browne本人的描述(http://www.julianbrowne.com/article/viewer/brewers-cap-theorem)
以下是我个人的理解:

CAP是theorem，不是model。CAP告诉我们的是解决问题的方法。

Consistency(一致性)
在系统内部，读和写的操作都是由多个步骤完成的。但对于系统外部的使用者来说，读和写操作应该原子性的(atomic)
使用者会认为:
1. 所有的读，数据都应该一样
2. 写之后的读，应该是最新的数据。
对于一个单机系统，一致性的保证是很简单的。但对于一个分布式系统，要做到这一点，代价是相当昂贵的。

Availability(可用性)
对请求(request)能够有应答(response)，就算是可用的。Browne举的是买书的例子，作为中国人，我就拿铁道部的售票网站做个例子。
我要买一张火车票，系统告诉我有票，或者没票，这样都属于Availability
但是售票网站打不开;或者打开了网站，但是查询了半天一直在等待，就是没有结果。这样就属于Not Availability
通俗的讲，就是不管行不行，都痛快点，不要把我凉在旁边。

Partition-tolerance
这个不知道该怎么翻译(分区容忍度? 感觉不好)
作为分布式系统，不同的节点通过网络进行通讯。不可避免的，会受到网络的影响。
这里指的是对于节点间通讯失败的容忍程度。换句话说，如果所有节点都在一台机器上，就不会有这样的问题。

CAP理论就是说，三者只能取其二。三者均完美的系统是不存在的。
要保证C, 最好就是只用一个节点来处理读和写
要保证A, 就是要尽可能多的节点能响应请求
要保证P，最好把所有节点放在一台机器上

举个例子，看看如果通过CAP理论解决问题:
一个master - slave架构的系统，为了防止master 和 slave之间的网络失效所带来的问题，我们可以怎么办
drop P: 把master和slave放在一台机器上
drop A: 如果master-slave之间的网络失效，则认为系统失效
drop C: 不去理会，继续提供服务。

再扩展一下自己的思维:
1. 对于一个银行系统, 对于C要求是最高的，P也是必须的(如果放在一个机房，火灾什么的就完蛋了)。所以可以做一个CP系统。
对于读写都是3,3(即3台写入成功才认为成功，读取3台的数据，都读取成功且一致才认为读取成功)
并且节点分布在各地。任何一个节点出了问题，系统中止服务(牺牲A)

2. 对于QQ的开心农场, C是最次要的因素(19个苹果，两人都偷了一个，结果剩下18个，这样完全没有问题)。可以做一个AP系统，提高用户体验和相应速度(把节点分布到各地，电信网通的都有)

3. 对于铁路订票系统，查询的时候，C是次要的；对于订票成功，写入的时候，C是重要的(不然就会出现扣款成功但没有出票)。A也是必要的(春节旅客们的抱怨，主要就集中在A这里)。P是次要的。
所以可以建一个CA系统，将主机都放在同一个机房，并提高并发处理能力。