CAP理论以及注册中心选择

---

一、CAP定理

• CAP定理：指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得
  其中：
  一致性（C）：所有节点都可以访问到最新的数据
  可用性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败
  分区容错性（P）：除了全部整体网络故障，其他故障都不能导致整个系统不可用

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

CA： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的
​
CP: 如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统
​
AP：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

二、常见的分布式核心CAP理论介绍

常见注册中心：zk、eureka、nacos

	Nacos	Eureka	Consul	Zookeeper
一致性协议	CP+AP	AP	CP	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	心跳	TCP/HTTP/gRPC/Cmd	Keep Alive
雪崩保护	有	有	无	无
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
SpringCloud集成	支持	支持	支持	支持

• Zookeeper：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足

• Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化

• 结论：
  分布式系统中P,肯定要满足，所以只能在CA中二选一
  没有最好的选择，最好的选择是根据业务场景来进行架构设计
  如果要求一致性，则选择zookeeper/Nacos，如金融行业 CP
  如果要求可用性，则Eureka/Nacos，如电商系统 AP
  CP ： 适合支付、交易类，要求数据强一致性，宁可业务不可用，也不能出现脏数据
  AP: 互联网业务，比如信息流架构，不要求数据强一致，更想要服务可用

• 愿我三旬时，理想依然在，孤独别醒来。

• 新的—年，仍有阳光满，路上温暖如初。

• 愿20xx年身体健康，去体验新城市的套路。

• 新年愿望，你幸福，我幸福，大家都幸福!

• 愿时光为你定格，永远停在快乐的那—刻。

• 有志者自有千计万计，无志者只感千难万难。

• 不要皱眉，即使在伤心的时刻，因为你从不知道有谁会醉心于你的笑容。

• 再长的路，一步步也能走完，再短的路，不迈开双脚也无法到达。

• 所谓的成熟.其实就是在不断看开狠多事情之后.更好的生活着。

• 努力不—定改变人生，但改变人生必须努力。