base理论（分布式架构理论）

分布式应用核心CAP知识

CAP定理: 指的是在⼀个分布式系统中，Consistency（⼀致性）、 Availability（可⽤性）、Partitiontolerance（分区容错性），三者不可同时获得

⼀致性（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，如电商系统 APCP ： 适合⽀付、交易类，要求数据强⼀致性，宁可业务不可⽤，也不能出现脏数据AP: 互联⽹业务，⽐如信息流架构，不要求数据强⼀致，更想要服务可⽤

⼀致性和可⽤性的权衡结果BASE理论

什么是Base理论

CAP 中的⼀致性和可⽤性进⾏⼀个权衡的结果，核⼼思想就是：我们⽆法做到强⼀致，但每个应⽤都可以根据⾃身的业务特点，采⽤适当的⽅式来使系统达到最终⼀致性, 来⾃ ebay 的架构师提出

Basically Available(基本可⽤)

假设系统，出现了不可预知的故障，但还是能⽤, 可能会有性能或者功能上的影响

Soft state（软状态）

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可⽤性，即允许系统在多个不同节点的数据副本存在数据延时

Eventuall consistent（最终⼀致性）

系统能够保证在没有其他新的更新操作的情况下，数据最终⼀定能够达到⼀致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值

参考原文：cyz