zk不适合注册中心原因

阿尼亚谁油

于 2023-04-24 09:58:51 发布

阅读量595

点赞数 1

文章标签：网络 java 开发语言

本文链接：https://blog.csdn.net/weixin_44447809/article/details/130336272

版权

Zookeeper因其CP特性，在面对网络分区时牺牲可用性以保证一致性，这使其不适合大规模服务注册。高TPS需求、弱服务健康检查、无数据缓存、复杂客户端交互和异常处理，都限制了它在服务发现场景的应用。ZAB协议和强一致性设计更适合分布式协调，而非服务发现对可用性的高要求。

摘要由CSDN通过智能技术生成

Zookeeper不适合做注册中心

在 CAP 模型中，zookeeper 是 CP，意味着面对网络分区时，为了保持一致性，他是不可用的。

因为 zookeeper 是一个分布式协调系统，他的核心算法是 Zab，所有设计都是为了一致性。

1、当注册中心的服务规模超过一定数量的时候，zk不能很好的工作，不能支持很高的tps和TCP长连接

2、zk的写请求是不是可扩展的

3、zk提供的Service Health Check功能很弱，基于zk的session活性检查和临时节点监听机制上，不能真正反应服务的健康状态

4、zk原生客户端没有提供数据缓存机制，当注册中心宕机的时候，会造成服务不可用

5、zk原生客户端不好用，难以掌握Client/Session状态机，zk的客户端和服务端交互协议不简单，比如：TCP长连接Session管理，Ephemeral Znode（临时节点），Event&Notification（事件订阅通知）,ping（心跳检测）

6、复杂的异常处理，ConnectionLossException和Disconnected事件

ZooKeeper应该 “The King Of Coordination for Big Data”！大数据协调之王

ZAB协议（zookeeper原子广播协议），崩溃恢复模式（群首选举协议，），原子广播模式（消息广播协议，类似于两阶段提交协议）

作为一个分布式协同服务，ZooKeeper 非常好，

但是对于 Service 发现服务来说就不合适了，因为对于 Service 发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好。

所以当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

所以说，作为注册中心，可用性的要求要高于一致性！

在 CAP 模型中，Zookeepe 整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。

那为什么 Zookeeper 不使用最终一致性（AP）模型呢？

因为这个依赖 Zookeeper 的核心算法是 ZAB，所有设计都是为了强一致性。这个对于分布式协调系统，完全没没有毛病，但是你如果将 Zookeeper为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不合适。

关注