* CAP定理: 指的是在⼀个分布式系统中,Consistency(⼀致性)、
Availability(可⽤性)、Partitiontolerance(分区容错性),三者不可同时获得
⼀致性(C):所有节点都可以访问到最新的数据
可⽤性(A):每个请求都是可以得到响应的,不管请求是成功还是失败
分区容错性(P):除了全部整体⽹络故障,其他故障都不能导致整个系统不可⽤
*
CAP理论就是说在分布式存储系统中,最多只能实现上⾯的两点。⽽由于当前的⽹络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在⼀致性和可⽤性之间进⾏权衡
CA:
如果不要求P(不允许分区),则C(强⼀致性)和A(可⽤性)是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署⼦节点,这是违背分布式系统设计的初衷的
CP:
如果不要求A(可⽤),每个请求都需要在服务器之间保持强⼀致,⽽P(分区)会导致同步时间⽆限延⻓(也就是等待数据同步完才能正常访问服务),⼀旦发⽣⽹络故障或者消息丢失等情况,就要牺牲⽤户的体验,等待所有数据全部⼀致了之后再让⽤户访问系统
AP:要⾼可⽤并允许分区,则需放弃⼀致性。⼀旦分区发⽣,节点之间可能会失去联系,为了⾼可⽤,每个节点只能⽤本地数据提供服务,⽽这样会导致全局数据的不⼀致性
* 常⻅注册中⼼:zk、eureka、nacos
 NacosEurekaConsulZookeeper
⼀致性协议CP+APAPCPCP
健康检查TCP/HTTP/MYSQL/Client Beat⼼跳TCP/HTTP/gRPC/CmdKeep Alive
雪崩保护有有无无
访问协议HTTP/DNSHTTPHTTP/DNSTCP
SpringCloud集成⽀持⽀持⽀持⽀持
*
Zookeeper:CP设计,保证了⼀致性,集群搭建的时候,某个节点失效,则会进⾏选举⾏的leader,或者半数以上节点不可⽤,则⽆法提供服务,因此可⽤性没法满⾜
* Eureka:AP原则,⽆主从节点,⼀个节点挂了,⾃动切换其他节点可以使⽤,去中⼼化
* 结论
分布式系统中P,肯定要满⾜,所以只能在CA中⼆选⼀
没有最好的选择,最好的选择是根据业务场景来进⾏架构设计
如果要求⼀致性,则选择zookeeper/Nacos,如⾦融⾏业 CP
如果要求可⽤性,则Eureka/Nacos,如电商系统 AP
CP : 适合⽀付、交易类,要求数据强⼀致性,宁可业务不可⽤,也不能出现脏数据
AP: 互联⽹业务,⽐如信息流架构,不要求数据强⼀致,更想要服务可⽤

技术
©2019-2020 Toolsou All rights reserved,
在算法研究过程中如何进行算法创新七大排序算法(java代码)MYSQL中的索引与事务———javaweb(8)(面试必考)2022蓝桥杯JavaB组省赛试题网络安全-wifi攻防网络层协议——ICMP协议MySQL查询表中指定条件下的最新记录JavaSE笔记(一)Java基础语法mysql 查询条件之外的数据_mysql 查询符合条件的数据qt使用数据库sqlite