注册中心 ZooKeeper、Eureka、Consul 、Nacos

• CAP理论 一致性 可用性 分区容错性 三者只能同时两个 不可能三个兼顾 在分布式中必须保证P 所以只看A和P
• ZK
  • 不能保证服务可用性
    • Leader选举 时间过长30~120s
    • Zookeeper 集群中半数以上服务器节点不可用
  • 数据存储
  • 不适用淘宝的双十一，京东的618就是紧遵AP的最好参照
• Eureka
  • Peer to Peer 互相注册
  • Eureka Server 将会注销该实例(默认为90秒 可配置)
  • Eureka Server 节点在短时间内丢失过多的心跳，节点进入自我保护模式
    • Eureka不再从注册表中移除长时间没收到心跳的服务
    • Eureka仍接受新服务注册和查询，但是不会被同步到其它节点上（即保证当前节点依然可用）
    • 当网络稳定时，当前实例新注册的信息会被同步到其它节点中
  • Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的
  • 适用淘宝的双十一，京东的618就是紧遵AP的最好参照
• Consul
  • Go语言
  • Raft算法，比zookeeper使用的Paxos算法更加简单
  • 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
  • Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性
• Nacos
  • 支持动态配置服务 Nacos = Spring Cloud注册中心 + Spring Cloud配置中心