CAP理论

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：[1][2]

一致性（Consistency）： （等同于所有节点访问同一份最新的数据副本）
可用性（Availability）:（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[3]。）
根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

结论:他们在这篇论文中证明了：在任意的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition-tolerance）这三种属性最多只能同时存在两个属性。

一致性

分布式系统的一致性，这里的一致性一般指的是线性一致性（Linearizability Consistency) ,所谓的线性一致性，也就是强一致性（Strong Consistency),或者原子一致性（atomic consistency),其特点如下：

• 在一个线性一致性的系统里面，任何操作都可能在调用或者返回之间原子和瞬间执
• 在一个线性一致性的系统里面，任何操作都可能在调用或者返回之间原子和瞬间执行>在一个线性一致性的系统里面，任何操作都可能在调用或者返回之间原子和瞬间执行

也就是通常所说的 CAP 理论中的 C

在线性一致性的分布式环境下，所有的操作像是在单机上完成一样，也就是多台服务器的状态都是一致的。
比如：现在对系统有两部操作A,B, A作用在系统上的时候，作用后的状态(State)我们成为A State。如果操作B的时候，作用后的状态(State)我们成为B state ,如果操作A是在操作B之前发生的，并且A成功了。那么系统状态B 必须要比 AState 更加的新。
分布式购物系统，其架构如下：

商品的存货状态分别存在Server A和Server B中，我们把存货状态定义为“有货状态”和“无货状态”。在开始的时候，AB服务器的都是显示诱惑状态，等过完一段时间后，商品卖完了，后台就必须将这两台服务器上的商品状态更改为无货状态。因为在分布式的环境下，如果A服务器上更新成了无货状态，但是由于服务器B因为网络延迟的原因并没有更新，还是显示有货状态，假如这个时候，有两个用户恰好使用这个购物系统，先后发送了一查询操作（Query Operation) 到后台服务器，假如A先查询的并且查询的时候服务器A,那么系统会返回商品是无货的状态。用户B也发出像A一样的查询，这个B的查询被发送到B服务器上，并且成功返回了商品是有货状态，如下：

按照业务的要求，这个系统对于这个物品，系统应该返回的是无货状态。而用户A又是在用户B之前，如果系统有一致性的这个属性，用户B查询的时候，系统理论上返回的状态应该是无货状态。
但是在这个案例中，用户B却返回了诱惑状态，所以这个系统并没有满足论文里所提到的线性一致性。如下图：

可用性

分布式中，可用性可以这样理解在分布式系统中，任意非故障的服务器都必须对客户的请求产生相应。
当分布式满足系统的可用性的时候，不管出现什么状况（除非所有的服务器全部崩溃），都要返回响应。如下图：

当客户端向系统发送请求的时候，只要系统背后的服务器有一台还没有崩溃，那么这个未崩溃的服务器必须最终响应客户端

分区容错性

分区容错性，分成两部分：“分区”和“容错”
何为分区容错？
在一个分布式系统中，如果出现一些故障，可能会使的部分节点之间无法通信，由于这些故障节点无法联通，整个系统的网络就可能会被分成几块区域。而数据分散在这些无法联通的区域中的情况，就被叫做“分区”。

上面这个图，可以看到client所在网络和Server B在请求上属于同一个网络，但是Server B,Server A, Server C不在同一个网络上，这是因为其不能通信
如果你的数据只是保存在Server A，当系统出现网络分区的时候，Server C ，Server B 就无法获取数据，如果我们要满足”分区”（其实就是异常或者错误），系统就需要容错。也就是说，说白就是，既是系统出现内部因为网络导致的分区，系统也必须能够返回消息。
从上面我们可以知道，分区容错性，系统允许网络丢失从一个节点发送到另一个节点的任意多条消息
系统节点出现故障或者网络出现丢包的情况在现在的网络仍旧是时常发生的，如果没有分区容错性，也就是说系统不允许网络丢失从一个节点发送到另一个节点的任意一条 信息的话，那我们日常所使用的很多系统就不能再继续工作了。
在大部分情况下，系统设计的都会保留P属性，而在C和A中二选一
在上述提到的论文中，主要论证了在任意的系统中，我们最多可以保留CAP属性中的两种，也就是CP和AP或者CA。

下面列举了一些开发框架中所使用到的属性：

• CP系统: Google BigTable,Hbase,MongoDB,Redis,MemCacheDB，这些存储架构都放弃了高可用性（High Availablity)
• AP系统:Amazon Dynamo 系统以及它的衍生存储系统Apache Cassandra 和Voldemort
• CA系统:Aapche Kafka是典型的CA系统

现在的架构师，在近代网络的设计中，基本P属性基本上都属于一个必选项，那么CA系统(Apache Kafka)为什么选择了CA属性呢？
Kafka Replication 的概念，8.0以后，Kafka Relocation 通过将不同的数据复制到不同的节点上，从而增强了数据在系统中的持久性(Durability)和可用性，在Kafka Replication 的系统设计中，所有的数据日志存储是设计在同一个数据中心里面，在同一个数据中心里网络出现问题的可能性是十分的小的。
在Kafka数据副本的设计中，先通过Zookeeper 选举出一个领导者节点。这个领导节点负责维护一组被称作同步数据副本的节点，所有的数据写入都必须在这个领导节点中记录。
我来举个例子，假设现在数据中心有三台服务器，一台被选为作为领导者节点，另外两台服务器用来保存数据副本，分别是 Replication1 和 Replication2，它们两个节点就是被领导者节点维护的同步数据副本了。领导者节点知道它维护着两个同步数据副本。
比如：如果用户想写入一个数据”DarryKinger”,会发生如下：
1）.用户会发送请求到领导节点中，写入“DarryKinger”
2）.领导者节点收到请求后，现在本地节保存好，然后也同时发送消息通知Replication1和Replication2
3）.Replication1和Replication2接受到消息以后保存这条消息，并且回复领导节点写入数据成功。
4）.领导节点 收到回复以后，记录节点Replication1和Replication2都是健康的，并且回复用户写入成功
看下图，红色的部分是领导者节点本地日志，记录着哪些同步数据副本是健康的。

如果用户在以后想要查询写入的数据，无论是领导节点或者是副本（Replication1,Replication2…..)都可以返回正确的结果。那如果分区出现的问题的时候怎么办？比如领导节点与Repliaction1没有办法通讯了，这个时候流程就会变成如下：
1）.用户发送请求到领导节点中想写入”DarryKinger”
2）.领导节点在收到请求以后先保存到本地，然后也同时发送消息通知Replication1和Replication2
3）.只有Replication2 收到消息以后，也保存这条消息，并且回复领导者节点写入成功
4）.领导者节点记录Replication2是健康的，并且回复用户写入成功
其架构如下图：

如果所有的副本都无法通讯的时候，Apache Kafka 允许系统只有一个节点工作，就是那个领导者节点。这个时候的写入都只保存在领导者节点了。
1）.用户发送请求到领导者节点写入”Darrykinger”
2）.领导者节点收到请求后保存到本地，然后也同时发送消息通知Replication1和Replication2
3）.没有任何的副本节点回复领导者写入，领导者节点记录无副本节点是健康的，并且回复用户写入成功

在最坏的情况下，就是领导节点也挂了，Zookeeper会通过选举制度，重新去寻找健康的服务器节点来当选新的领导者节点

如果让你重新设计微博系统中的发微博功能，你会选择 CAP 的哪两个属性呢？为什么呢？