微服务中的CAP定律

说到微服务，先给大家提一下CAP分布式应用知识吧，无论你微服务使用的是阿里云开源的Dubbo还是基于Springboot的一整套实现微服务的Springcloud都必须遵循CAP定理不然你所实现的分布式是达不到高可用（一般指服务的冗余,一个服务挂了,可以自动切换到另外一个服务上,不影响整个服务的运行）高性能（服务响应时间快,特别是在高并发下响应时间不会急剧增加）的，而且还容易宕机

下面来说说什么是CAP：

CAP定理：
            指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。

接下来我们来说说什么是一致性？？

首先我们熟知在微服务中所有的模块都是一个服务， 从上图可以看出，上图进行了主从分离和主从复制，为什么这么做呢，因为我们微服务的模块中所有的信息数据都是要达到一致的（特殊功能除外），这么做就是为了防止用户浏览错误的信息，给用户造成不好的体验

但是同步是需要时间的，在机器数量特别多的情况下进行同步，会消耗很多时间  于是就有了：一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时）
接下来说说可用性？？

看上图（1），正常情况下，负载量不高的情况下能正常的响应的读写客户端的请求，正常的进行运转，而在淘宝天猫当双十一，国庆节，年货的时候，商品的流量会非常的大，读写次数非常的频繁，看上图（2）在下单的人数数量多的情况下如果负载过高或者不当，就会产生迟缓，不能在正常的响应时间内进行数据的返回，严重时即使我们进行熔断后过段时间也连接不上此机器，影响用户体验 ，所以我们就在考虑，在高峰期的时候，是不是还能控制我们的响应时间呢？所以，可用性就诞生了！

注：qps(每秒访问量)

这就是  可用性（A）：负载过大后，集群整体是否还能响应客户端的读写请求。（服务一直可用，而且是正常响应时间）

下面我们来说说分区容错性？？

么分区容错性呢？我们在做小的项目的时候，不会部署太多的节点，就能保证正常的运行，但是当这个项目某几个节点出现了问题，那么我总共就五台机器，两个都出现了错误，这个项目还怎么运行呢？？这只是举个比方，小的项目排查不需要太多的时间，找到错误并没有那么麻烦，那么，如果是一个特别大的电商项目，我只部署10个节点，那出问题就麻烦了，由于项目规模庞大，排查困难，而且如果我那10个节点3，4个都出了问题，那么我这个项目想正常运行时不可能的吧？那么怎么样在节点挂了几个的情况下保证服务的运行呢？这时候分区容错性就出现了！

分区容错性（P）：分区容忍性，就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好）所以在项目中部署多个节点是很有必要的

接下来我们说一下CAP的具体的三条定律吧

1.C A 满足的情况下，P不能满足的原因：
            数据同步(C)需要时间，也要正常的时间内响应(A)，那么机器数量就要少，所以P就不满足
        
     2.   CP 满足的情况下，A不能满足的原因：
            数据同步(C)需要时间, 机器数量也多(P)，但是同步数据需要时间，所以不能再正常时间内响应，所以A就不满足

3.   AP 满足的情况下，C不能满足的原因：
            机器数量也多(P)，正常的时间内响应(A)，那么数据就不能及时同步到其他节点，所以C不满足

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡