Redis集群扩容时节点崩溃问题分析与解决方案

问题背景

在Redis 7.2.4版本的集群环境中，当执行集群扩容和重新分片操作时，特别是在使用redis-cli cluster rebalance命令进行数据再平衡过程中，出现了源节点崩溃的情况。这种崩溃不仅导致迁移失败，还造成了集群槽位状态异常，且无法通过常规的cluster fix命令修复。

崩溃现象分析

从日志中可以观察到，崩溃发生时Redis服务器正在进行AOF重写操作，随后触发了断言失败：

=== ASSERTION FAILED ===
==> networking.c:2066 'c->duration == 0' is not true

这个断言失败表明在networking.c文件的2066行，Redis期望某个客户端连接的持续时间为0，但实际上不为0。随后，所有的后台工作线程和IO线程都相继终止。

根本原因

根据Redis开发者的反馈，这个问题很可能与Redis的阻塞操作(block)相关。在集群重新平衡过程中，如果同时有大量的流(stream)和阻塞操作在进行，就可能触发这个断言失败。

具体来说，当Redis处理客户端连接时，会跟踪每个连接的持续时间。在某些情况下，特别是涉及阻塞操作时，这个持续时间可能没有被正确重置，导致断言失败。

解决方案

对于这个特定问题，Redis开发者建议可以暂时注释掉serverAssert(c->duration == 0)这行断言代码。从理论上讲，这样做不会产生副作用，因为：

1. 这个断言主要用于调试目的
2. 持续时间不为0通常不会影响Redis的核心功能
3. 在集群重新平衡过程中，这个检查不是关键性的

预防措施

为了避免在集群扩容和重新分片过程中出现类似问题，建议：

1. 在业务低峰期执行集群扩容操作
2. 减少或避免在重新平衡过程中执行大量的阻塞操作
3. 监控集群状态，确保所有节点健康后再开始迁移
4. 考虑分批次执行迁移，而不是一次性迁移大量数据

总结

Redis集群在扩容和重新分片过程中可能会遇到各种边缘情况，特别是在高并发和大量阻塞操作的环境下。理解这些问题的根本原因有助于我们采取适当的预防措施和解决方案。对于这个特定的断言失败问题，临时禁用相关检查是一个可行的应急方案，但长期来看，可能需要等待Redis官方发布修复版本。