第六章 分布式架构CAP理论

• CAP定理: 指的是在⼀个分布式系统中，Consistency（⼀致性）、 Availability（可⽤性）、Partitiontolerance（分区容错性），三者不可同时获得
  ⼀致性（C）：所有节点都可以访问到最新的数据
  可⽤性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败
  分区容错性（P）：除了全部整体⽹络故障，其他故障都不能导致整个系统不可⽤
• CAP理论就是说在分布式存储系统中，最多只能实现上⾯的两点。⽽由于当前的⽹络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在⼀致性和可⽤性之间进⾏权衡
  CA： 如果不要求P（不允许分区），则C（强⼀致性）和A（可⽤性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署⼦节点，这是违背分布式系统设计的初衷的
  CP: 如果不要求A（可⽤），每个请求都需要在服务器之间保持强⼀致，⽽P（分区）会导致同步时间⽆限延⻓(也就是等待数据同步完才能正常访问服务)，⼀旦发⽣⽹络故障或者消息丢失等情况，就要牺牲⽤户的体验，等待所有数据全部⼀致了之后再让⽤户访问系统
  AP：要⾼可⽤并允许分区，则需放弃⼀致性。⼀旦分区发⽣，节点之间可能会失去联系，为了⾼可⽤，每个节点只能⽤本地数据提供服务，⽽这样会导致全局数据的不⼀致性
• 常⻅注册中⼼：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: 互联⽹业务，⽐如信息流架构，不要求数据强⼀致，更想要服务可⽤