- 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: 互联⽹业务,⽐如信息流架构,不要求数据强⼀致,更想要服务可⽤