阅读笔记（三）CAP理论相关

本文主要是介绍阅读笔记（三）CAP理论相关，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一. 简介

本文分享一些关于CAP原理介绍的文章和重点内容。

二. 通俗易懂的CAP事例

《A plain english introduction to CAP Theorem》一文用一个通俗易懂的事例讲述了CAP原理。下面是简单概括后的例子。

有一天，你发出广告为他人提供了一项服务：帮他人记录各种信息，并提供查询功能。（单服务器架构）
随着业务的增多，一个人渐渐忙不过来了，可能遇上生病、有事，也可能24小时工作也无法让所有用户满意，再加上排队、拥塞等情况会导致业务损失，因此让自己老婆帮忙一起来提供服务 （分布式架构） ：顾客依然是打老电话来记录或者查询信息，但是内部分线让自己和老婆谁有空谁接 （负载均衡）
在这种情况下，遇到了第一个问题：顾客打电话被自己接到了，要求查询之前存放的信息，但是在自己的笔记本上没有发现有存放过信息因此回复没有信息。实际上是因为顾客存储信息的时候接通的是老婆那边，因此没有存在自己这里，导致了信息的不一致，也就是Consistency。
通过思考，你提出了这样的解决办法：在用户打电话更新、记录信息的时候，我们告诉彼此新的信息，起到同步的作用。但是这种做法存在一个缺陷：如果有一天自己或者老婆有事/生病了，那就导致另一个人的存储无法得到更新，也就是无法保证可用性（Availability）
通过进一步思考，你提出了 同时可以保证一致性（Consistency）和可用性（Availability） 的解决方案 （CA） ：在4的方案基础上增加一个检测机制：当自己或者老婆回来工作时，首先会进行信息的校验和同步，保持一致之后再继续工作下去
5得出的方案的确可以保证了一致性和可用性，但是这带来了另一个问题：假如老婆不开心了，不乐意和自己进行这个信息的同步更新，那怎么办？（Partition Tolerance 分区容错） 如果想保证一致性，那就不能兼顾可用性，反之亦然，这就是CAP原理。

三. 再看CAP

《CAP Theorem: Revisited》一文通过绘图和简洁的讲解说明了为什么只有可能出现CP或者AP而不存在CA模型。其实从第二节的例子中已经很明显的可以看出来了，只要有分区容错问题，则CA一定是无法保持的。
首先大家需要意识到网络是不可靠的，经常会在意想不到的时候发生问题，而我们没有办法去选择什么时候发生问题或不发生。在此前提下，才出现了CAP原理，即我们随时都可能因为网络的不可靠出现分区问题，并由此需要解决分区容错，而对此，我们只能选择可靠性或者一致性二者其一。

CP（Consistency/Partition Tolerance ）
当N1和N2两个服务器突然断开了连接时，假设其中的同一数据x在N1中更新为了y。这是如果想要保持一致性，则访问N2服务器就会得到error回复或者因为分区同步失败等待过久导致timeour error，即失去了可靠性（Availability）。当我们需要保持高度一致的原子性读写时则必须损失一定的可用性
AP（Availability/Partition Tolerance）
与上例相反，如果我们需要保证高度可用性，则访问N1和N2服务器分别会得到x和y的数据回复。

四. CAP FAQ

《The CAP FAQ》是Henry Robinson在github上发表的一系列FAQ，这里前排推荐这位大牛的博客，有很多不错的文章，如《Distributed systems theory for the distributed systems engineer》。这里没有全文搬运，仅给出部分和上文不同的内容。

CAP问题的起源
CAP问题源于Eric Brewer博士的演讲“Towards Robust Distributed Systems”，后由MIT的Seth Gilbert 和 Professor Nancy Lynch在论文“Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services”中阐明。
什么是原子性（atomic or linearizable）
原子性，即一致性，是保证客户端发出get()请求时获取到的值得一致性。对客户端来说，分布式的服务器在他们看来仅仅是一台抽象的机器，这就是原子性的缘由。
什么时候系统必须放弃C或者A
CAP理论仅在某些情况下才会发生：首先网络出现错误导致了分区容错P的出现，然后对数据的严苛要求才会导致了必须舍弃C或者A。如果不是在这种严苛条件下，即某些情况下并没有请求导致必须舍弃C或者A，则我们可以同时保持着CA的状态。
C和A有各种等级吗？
我们看可以适当放松C和A的要求去搭建灵活的系统。例如很多系统选择放松可靠性的要求，保障一致性，如ZooKeeper。而亚马逊的Dynamo则放松了一致性的检测，保持更高度的可用性。在自己搭建架构时，切记根据需要来选择哪种方式更适合。