ZooKeeper 避坑指南: ZooKeeper 3.4.6 版本 BUG 导致的数据不一致问题

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。

背景


ZooKeeper 作为分布式系统的元数据中心,对外服务的数据一致性需要得到很好的保证,但是一些老版本的 ZooKeeper 在一些情况下可能无法保证数据的一致性,导致依赖 ZooKeeper 的系统出现异常。


某用户使用 3.4.6 版本 ZooKeeper 做任务调度,ZooKeeper 实例的 tps 和 qps 都比较高,事务日志产生的速率很快,即使此用户配置了自动清理的参数,但是自动清理的最小间隔还是赶不上数据产生的速度,导致磁盘爆满。

image.png

在此用户清理了旧日志之后,重启节点,部分业务机器就报出 NodeExist,NoNode 的异常,并且报错只集中在部分机器,此次异常导致用户任务调度系统出现任务重复调度以及任务丢失问题,产生重大损失。


原因分析


仔细检查了这些客户端发现这些客户端都连接在同一台 ZooKeeper 节点上,通过 zkCli 手动排查节点上的数据,对比其他未清理磁盘的 ZooKeeper 节点,清理了磁盘的 ZooKeeper 节点中的数据和其他节点具有差异,此时确定此节点由于一些原因出现了数据不一致问题,导致连接到此节点的客户端读到了脏数据。

image.png

但是排查日志,没有发现异常日志。由于此节点之前清理过日志,并且重启过,磁盘上的数据被重新加载过,因此怀疑是 ZooKeeper 在启动加载数据的过程中出现了一些异常情况。通过分析 ZooKeeper 启动中加载数据的代码,继续排查具体原因。

public long restore(DataTree dt, Map<Long, Integer> sessions,
            PlayBackListener listener) throws IOException {
        snapLog.deserialize(dt, sessions);
        FileTxnLog txnLog = new FileTxnLog(dataDir);
        TxnIterator itr = txnLog.read(dt.lastProcessedZxid+1);
        long highestZxid = dt.lastProcessedZxid;
        TxnHeader hdr;
        try {
            while (true) {
        ...
                try {
                    processTransaction(hdr,dt,sessions, itr.getTxn());
                } catch(KeeperException.NoNodeException e) {
                   throw new IOException("Failed to process transaction type: " +
                         hdr.getType() + " error: " + e.getMessage(), e);
                ...
        return highestZxid;
    }

此处是 ZooKeeper 加载磁盘数据的代码,此方法的主要作用是,首先将磁盘中的 snapshot 文件加载进内存,初始化 ZooKeeper 内存中的数据结构,之后将加载事务日志应用日志中对数据的修改,最终还原磁盘中数据的状态。

image.png

但是在 3.4.6 版本的代码中 snapLog.deserialize(dt, sessions);这行加载 snapshot 文件的代码有一个返回值,此处没有进行返回值校验,导致在 ZooKeeper 本身找不到有效的 snapshot 文件的情况下还是会继续加载事务日志,从而导致 ZooKeeper 在空数据的状态下直接应用事务日志,最终导致此节点的数据和其他节点的数据不一致。

image.png

此问题已经在 ZooKeeper 社区有对应的 issue,在加载 snapshot 的文件列表为空的情况下,此问题已经得到了修复,但是由于磁盘爆满导致的 snapshot 文件不完整的其他的一些特殊情况下,此问题依然存在。解决此问题还需要从磁盘使用的角度解决。

issue:

https://issues.apache.org/jira/browse/ZOOKEEPER-2325


解决方案


为了避免 ZooKeeper 节点的磁盘被快速打满,可以增加磁盘的容量,配合 ZooKeeper 本身的清理机制,可以在一定范围内的 tps 下避免磁盘被写满的情景,但是增大磁盘容量会带来显著的使用成本的提高,并且即使磁盘容量提高了,也可能因为 ZooKeeper 本身清理机制不及时清理,导致磁盘被打满,最终需要通过人工的方式进行磁盘清理,运维起来很复杂,耗费人力物力,并且集群稳定性得不到显著提升。

image.png

MSE ZooKeeper 提供 ZooKeeper 实例的全托管,MSE ZooKeeper 实例的磁盘使用对用户完全透明,用户无需担心磁盘爆满问题,以及磁盘使用过程中的复杂运维。MSE ZooKeeper 通过定时清理,触发使用阈值清理等手段保证 ZooKeeper 实例在使用过程中磁盘始终处于安全水位,避免由于磁盘问题导致的数据不一致,实例不可用等问题。

image.png

MSE ZooKeeper 默认集成 Promethus 监控,提供丰富的指标信息,并且针对写多的场景,MSE ZooKeeper 提供 TopN 大盘,能够快速看到业务热点数据,以及高 tps 的客户端情况,能够通过这些统计数据快速定位业务使用过程中的问题。

image.png


相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
Dubbo Cloud Native Java
ZooKeeper 避坑实践:由于jute.maxbuffer 设置问题导致的集群不可用
微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。
ZooKeeper 避坑实践:由于jute.maxbuffer 设置问题导致的集群不可用
分布式系列教程(25) -解决Zookeeper启动失败的问题
分布式系列教程(25) -解决Zookeeper启动失败的问题
394 0
zookeeper查看版本的一些基本信息
zookeeper查看版本的一些基本信息
739 0
|
7月前
|
Java
zookeeper安装部署 zookeeper都需要修改
zookeeper安装部署 zookeeper都需要修改
46 0
|
运维 监控 安全
ZooKeeper 避坑指南: ZooKeeper 3.4.6 版本 BUG 导致的数据不一致问题
ZooKeeper 避坑指南: ZooKeeper 3.4.6 版本 BUG 导致的数据不一致问题
|
消息中间件 Kafka
kafka和zookeeper安装使用踩坑记录
kafka和zookeeper安装使用踩坑记录
|
存储 监控 网络协议
测试理论--zookeeper相关
ZooKeeper相关内容讲解与基本操作方法
135 0
测试理论--zookeeper相关
|
Oracle Java 关系型数据库
Zookeeper入门到精通02——zookeeper的本地安装操作
2.zookeeper的本地安装操作 2.1 本地安装
|
消息中间件 存储 算法
知其然而知其所以然,为什么Kafka在2.8版本中会“抛弃”Zookeeper
知其然而知其所以然,为什么Kafka在2.8版本中会“抛弃”Zookeeper
知其然而知其所以然,为什么Kafka在2.8版本中会“抛弃”Zookeeper
|
消息中间件 安全 Java
ZooKeeper 不行了?居然被 Kafka 抛弃了!
分布式发布与订阅系统Apache Kafka在即将发布的2.8版本,使用Kafka内部的Quorum控制器来取代ZooKeeper。
ZooKeeper 不行了?居然被 Kafka 抛弃了!

相关产品

  • 微服务引擎