CAP定理的理解

第一篇文章，一直将知识点和笔记记录在印象笔记里面，只是自己对一些模糊区域知识点的理解和看法，
不知是错还是对，本着学习的态度将所有的知识点分享到网络上，大家共同学习进步。
今天上来就要说的是分布式系统中的CAP定理，先上图来一波简单的理解

C（一致性）全称（Consistency）：分布式系统中，当A服务调用B服务都有写库操作时，要么同时成功，要么同时失败
A（可用性）全称（Availability）：分布式系统中，当A服务挂掉后，不会影响到非依赖A服务的其他服务的正常运行
P（分区容错性）全称（Partition tolerance）：分布式系统中，不可能是单机部署项目了，可能存在多台服务器部署，那么可能存在网络通信失败的情况存在，它们之间可能不能相互通信。

  从图中我们可以容易的知道它们是两两交集，那么就存在AP、PC、CA三种情况。在这里我要说的是，CAP是分布式
系统的基础理论，但是CA的情况就不满足分布式系统的概念，如果舍弃掉P（分区容错性），单机部署服务将不叫
分布式系统。所以在这里P可以认定为恒成立的（个人的理解，如果有不同的意见可以提出）。
  我在Dubbo项目中（非特大型项目），我通过PC模式来搭建的框架，即使用TCC模式（类似2PC模式）保证一致性。
在使用Dubbo搭建的框架中使用zookeeper作为注册中心，其实使用搭建的框架在设计初已经保证了可用性（微服务
拆分）。例如在一个要被说烂的电商项目中，如果用户支付功能挂掉，但是查看商品的功能可以继续使用。
如果要实现各个微服务模块的高可用性，可以使用容器（Docker Kubernetes）技术来解决相关的问题。
  其实在框架搭建的时候需要根据相关业务来权衡是用那种模式的，就像我上面的项目中（非特大型项目），服务之
  间的依赖不会过多。如果这个时候相互依赖过多，一个服务依赖了多个服务，前面的都成功了，到最后一个失败了，
  那么前面的多个服务都需要进行回滚，那么这样的成本就相当的高。
  
下面是一些AP的解决方案：
1.Eureka----> AP
2.RocketMQ中间件----> AP
知识点可能过于浅，也有可能存在错误的理解，欢迎大佬指正！