Eureka,Zookeeper,Consul三者异同点以及CAP规则

三者之间的比较

组件名 语言 CAP 服务健康检查 服务健康检查对外暴露接口 SpringCloud集成
Eureka Java AP 可配支持 HTTP 已集成
Consul Go CP 支持 HTTP/DNS 已集成
Zookeeper Java CP 支持 客户端 已集成

CAP规则

鉴于现在的微服务架构,这个P,我们永远都要保证,系统要么是AP,要么是CP,三个里面不可能全占

image-20210206180124697

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求。

因此,根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:

  • CA:单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
  • CP:满足一致性,分区容忍必的系统,通常性能不是特别高。
  • AP:满足可用性,分区容忍性的系统,通常可能对—致性要求低一些。

典型案例

AP(Eureka)

当网络分区出现后,为了保证可用性,系统B可以返回旧值,保证系统的可用性。

image-20210206181337844

  • 当没有出网络分区时,系统A与系统B的数据一致,X=1
  • 将系统A的X修改为2,X=2
  • 当出现网络分区后,系统A与系统B之间的数据同步数据失败,系统B的X=1
  • 当客户端请求系统B时,为了保让可用性,此时系统B应返回旧值,X=1

结论:违背了一致性C的要求,只满足可用性和分区容错,即APEureka在服务断开连接以后,并不会将其清除出注册表,也就是自我保护机制,这个机制就是AP的一种体现(好死不如赖活着),当然我们也可以关闭自我保护机制开启无情模式。

CP(Zookeeper和Consul)

当网络分区出现后,为了保证一致性,就必须拒接请求,否则无法保证一致性

image-20210206182043040

  • 当没有出网络分区时,系统A与系统B的数据一致,X=1
  • 将系统A的X修改为2,X=2
  • 当出现网络分区后,系统A与系统B之间的数据同步数据失败,系统BX=1
  • 当客户端请求系统B时,为了保证一致性,此时系统B应拒绝服务请求,返回错误码或错误信息

结论:违背了可用性A的要求,只满足—致性和分区容错,即CP,Zookeeper中,当服务关闭以后,Zookeeper在给服务发送心跳没有回应,它就把服务给删了,等恢复了服务,重新再以新的id上线;Consul中,如果服务关闭了,会在管理界面看见健康检查一栏为x

猜你喜欢

转载自blog.csdn.net/qq_43509535/article/details/113729065