CAP理论
CAP理论，这篇文章的标题我已经写了很久了，想学习什么是CAP理论，但是这段时间一直在巩固关于JVM的知识，没有加入其他知识点的文章。
今天我们来了解什么是CAP理论吧！
对于这些合理的知识点，必须利用维基百科的定义作为参考文献：
CAP定理在理论计算机科学中，也被称为http://www.Sina.com/(captheorem )，也称为http://www.Sina.com/(brewer ' s theorem ) [
一致性(CAP定理onsistency ) (与所有节点访问同一最新数据副本相同)。
可用性(布鲁尔定理vailability )；每个请求都可以获取正确的响应——，但不保证获取的数据是最新的数据) ) )。
分区容限(英文： Network partition ) http://www.Sina.com/artition tolerance )在实际效果中，分区相当于对通信的时限要求。 如果系统在时限内无法实现数据完整性，就意味着出现了分区情况，必须在c和a之间选择当前操作[3]。 ）
根据定理，分布式系统只能满足3项中的2项，不能全部满足3项[4]。 理解CAP理论最简单的方法是想象两个节点分为分区的两侧。 如果至少允许一个节点更新状态，则数据不一致(即c的性质)将会丢失。 为了确保数据完整性，如果将分区端的节点设置为不可用，则a的性质将会丢失。 除非两个节点不能相互通信，否则不能同时保证c和a，这将失去p的性质。
综上所述，分布式计算系统不能同时满足一致性、可用性和分区容错要求
我们需要用这句话来分析。
1 .开展分析的前提条件，需要知道什么是分布式系统吗？ 举个生活中的例子，我们的小饭馆，通常是老板，一个人经营着整个商店。 上司早上请先购买当天需要的食材，然后做饭、切。 而且，客人进来后，需要点菜、算账、然后炒菜等。
我们能理解。 在小酒店里，基本上一个人就能解决。
但是，当规模变大的时候，如果一个人想解决所有的事情，即使这个人能干，也会出现问题。 上司一个人这样那样做的话，一个上司就会最大限度地站在崩溃的边缘，如果上司吃不下去了，整个酒店的经营就会停止。
那么，达到一定规模后，大多数情况下，业主会委托专业工作。 例如，让厨师切蔬菜、让厨师炒、让厨师去收银台打工等。 这样，就有了各自发挥作用、从事专业工作的人。 这样，每个人都可以找到自己的工作，可以做自己的工作，而不是一次工作。 这就是团队合作。
但是，我们想想，似乎还有一个问题没有解决。 假设厨师当天休假了呢？ 怎么办？ 那么，酒店整体的经营还不行。
我们可以想到的是，聘用了多个厨师，即使有一天一个厨师请了假。 另一个可以支持，给你缓冲的时间。 那样的话，首先是保证酒店能开门运营。
上述例子实际上是从单APP应用服务到分布式系统服务的转换。 我们将上司一个人的职责划分为多个方向的职责，交给各自独立的系统来运行，员工之间通过远程过程调用等通信方式进行沟通。 原上司知道自己一个人收了餐费，要去炒菜，就这样走了。 现在不是了。 收银台收到钱后，把菜单作为便条交给厨师。 然后收款员继续专注于收款。 不关别的事。 然后厨师收到菜单后做。 完成后告诉服务员做饭。 厨师与这道菜后的动作无关。 该方案通过分布式系统方案将一个完整的操作划分为多个大的操作，从而使系统更加集中。 而且，此时上司想增加活动的业务，如果是上菜时我们需要搭话一声，那么只要修改“传递料理的人”这个系统就可以了。 不需要影响“收银台”、“厨师”系统的正常工作。
随之，当前互联网的系统架构分布式后，对各系统之间的作用进行模块化划分，增加了系统的可扩展性、可靠性、可控性、可用性等优点。 但随之而来的是一些问题
什么问题？
那么，关于各系统之间的同步问题，带着问题进行以下共享。
2 .首先分析一下cap(1)一致性(Consistency )。
怎么理解？ 分布式系统中的所有节点必须访问相同的最新数据副本。 例如，假设北京店的厨师再卖一碗炸酱面，那么当你数海南店的厨师卖了多少碗时，这一碗可能算不上。 那么，问问两位师傅一共卖了多少杯，就会有两个结果。 那么怎么解决？ 需要使用到“地块的容错性”。 北京店的厨师告诉海南店的厨师，他刚卖了一杯。 一致了。
)2)可用性(可用性) :
请每次获取正确的响应---但不保证获取的数据是最新的。 这一点似乎与第一连贯性相矛盾。 例如，虽然不是所有节点都检索数据，所有节点都报告错误，并且不返回数据，但节点1检索的数据可能为2秒
前的最新数据，而节点2获取的数据是1秒前的最新数据，两者就不会相同。（3）分区容错性（Partition tolerance）：
实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，那么就必须就当前操作在C和A中做出选择。
这句话怎么理解？就是一个分布式中的两个节点相互通信，可能会失败。就好比，我们北京店的厨师通知海南店的厨师，说他刚刚做了一个辣椒炒蛋。那么有可能这个通知就是失败的，到头来，海南店的厨师是不知道北京店的厨师做了“辣椒炒蛋”的。这种场景，我们认为，一定存在这样的概率（概率>0即为一定）；
3.总结
上方的三个三角理论：所谓CAP理论，就是三者条件，只能存在2种同时成立。也就是我们选择满足其他两种，就会有一种不满足，而我们刚刚说的分区容错性，是必须要考虑的，就是节点间相互通信，我们必须要考虑其通信失败的情况。
那为什么说一致性和可用性不能同时满足呢？
假设我们强烈要求满足一致性，也就是说，我们北京店系统卖出的炸酱面，+1了后，通知海南店系统之前，如果有人问卖了多少碗，是不能告诉他的，只能在两个店都达成最新的数据共识后，才能准确的告诉别人。这个时候就违背了可用性的定理。
同理可得，可用性的定理就是违背了一致性的定理了，因为如果我们要优先保证系统的可用性，那么就会出现数据不一致的情况发生。
4.实例拓展一下思考：
看到cap定理是一个三角存在的定理，也就是说只能满足两者，那么我们怎么去实例中理解他呢？
假设一个系统强要求可用性。可以理解为一个“微博热搜实时排行榜”，我想问一下，如果两台手机同时刷新一下，获取最新的热搜数量的排行榜，两个内容会是完全一模一样的吗？如果是北美洲的用户和亚洲的用户同时刷新一下全球热搜排行榜，两个结果就是一致的吗？
很显然，不可能是一致的，但是作为这个业务而言，也不需要做到毫秒级别，秒级以内的一致性。那么这时候我们就会抛弃CAP定理中的c一致性，更多的满足可用性，不能说两个用户刷新一下，一个用户就失败了。我们需要优先保证系统的可用性。但是最终的结果，两个用户会刷新到最新的数据。
那么什么业务场景需要优先保证一致性呢？就好比存取钱。
之前在网络上看到这样一则帖子；
他说：我同时在银行存取款机取钱，然后同时用微信发个红包，那么是不是可以不断的刷钱？？
先说明背景，微信红包系统，和银行存取款系统是两个完全独立的系统，是属于分布式系统中的范畴，那么是符合背景。那这个网友这种操作可行吗？当然不现实，两个动作，总归有先后，当第一个操作进入，第二个操作进只能被阻塞等待，这样当第一个操作完成后，第二个操作获取到数据，就是没钱了，那么这个时候，第二个操作必然是失败的。
这种场景就是需要要求强一致性，而我们就需要抛弃可用性，会在第二个操作的时候，返回错误给用户，达到一致性的目的。
那么我们能不需要保证分区容错性吗？从而达到CA的效果呢？
也就是说，我们需要达到一致性和可用性？
那可以理解为，我们抛弃了分区容错性，就是抛弃了分布式系统的架构模式，因为我们不想出现分区容错性的问题发生，那么就只能不出现分区，这样，在单体应用服务中，就不会出现这种问题，那么我们就可以保证一致性和可用性的。
但是这样是不是有违背我们上面的初衷？引入分布式的意义？
实际应用场景？我可能会想到一个工厂内部的系统运作，可能会抛弃系统的高并发压力优势，选择数据的强一致性和可用性。但是此处的可用性不是高可用。
5.总结笔者的心声
关于上述的CAP定理，是分布式计算领域的公认定理。是我们对于分布式架构的一种指明灯的设计思路的基本定理了。那么对于笔者所从事的互联网系统中，更多的是倾向于AP模式，也就是达到可用目的。
用户可能不在乎当前的文章的浏览量是10002次，还是10003次，但是用户在乎能不能正常浏览，我们程序设计者也在乎系统的分布式化能力。
6.贴上cap定理实现图示