CAP定理: 指的是在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可同时获得

# CAP理论

  • 一致性(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原则,无主从节点,一个节点挂了,自动切换其他节点可以使用,去中心化

# CAP下的注册中心选择的结论

  • 分布式系统中P,肯定要满足,所以只能在CA中二选一
  • 没有最好的选择,最好的选择是根据业务场景来进行架构设计
  • 如果要求一致性,则选择zookeeper/Nacos,如金融行业 CP
  • 如果要求可用性,则Eureka/Nacos,如电商系统 AP
  • CP:适合支付、交易类,要求数据强一致性,宁可业务不可用,也不能出现脏数据
  • AP:互联网业务,比如信息流架构,不要求数据强一致,更想要服务可用

# BASE理论:一致性和可用性的权衡结果

  • 什么是Base理论

CAP 中的一致性和可用性进行一个权衡的结果,核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性, 来自 ebay 的架构师提出

  • Basically Available(基本可用):假设系统,出现了不可预知的故障,但还是能用, 可能会有性能或者功能上的影响

  • Soft state(软状态):允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时

  • Eventually consistent(最终一致性):系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态,因此所有客户端对系统的数据访问最终都能够获取到最新的值