CAP理论以及注册中心选择

CAP理论

  • 一、CAP定理
  • 二、常见的分布式核心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年身体健康,去体验新城市的套路。

  • 新年愿望,你幸福,我幸福,大家都幸福!

  • 愿时光为你定格,永远停在快乐的那—刻。

  • 有志者自有千计万计,无志者只感千难万难。

  • 不要皱眉,即使在伤心的时刻,因为你从不知道有谁会醉心于你的笑容。

  • 再长的路,一步步也能走完,再短的路,不迈开双脚也无法到达。

  • 所谓的成熟.其实就是在不断看开狠多事情之后.更好的生活着。

  • 努力不—定改变人生,但改变人生必须努力。

你可能感兴趣的:(SpringCloud微服务,面试,zookeeper)