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年身体健康,去体验新城市的套路。
-
新年愿望,你幸福,我幸福,大家都幸福!
-
愿时光为你定格,永远停在快乐的那—刻。
-
有志者自有千计万计,无志者只感千难万难。
-
不要皱眉,即使在伤心的时刻,因为你从不知道有谁会醉心于你的笑容。
-
再长的路,一步步也能走完,再短的路,不迈开双脚也无法到达。
-
所谓的成熟.其实就是在不断看开狠多事情之后.更好的生活着。
-
努力不—定改变人生,但改变人生必须努力。