sentinel排障记1

在 Sentinel 排障记1中，我们遇到了一个关于 Redis Sentinel 在生产环境中遇到的故障问题，主要涉及 Redis Sentinel 的状态不一致、assert 错误以及内存分配的问题。以下是对这个故障的详细分析和解决过程： Sentinel 服务在运行过程中出现了状态不一致的情况，即它既没有处于监控状态也没有处于订阅状态，这可能是由于内部状态管理或网络通信问题导致的。尝试通过增大批量添加 Sentinel 节点的时间间隔来解决，但无论设置为1秒、5秒还是10秒，错误仍然发生。 接着，进行了进程的系统调用跟踪(strace)，发现程序在特定的系统调用处崩溃，该调用与内存分配有关。进一步研究后，怀疑问题可能与使用的内存分配器 jemalloc 有关。尝试将 Redis 的编译选项改为使用 libc 作为内存分配器，这一改动在一台机器上成功部署了 Sentinel，但在另一台机器上失败，排除了 jemalloc 的一致性问题。 为了更深入地理解问题，对崩溃程序进行了 core dump 分析，通过堆栈信息和变量状态发现关键在于 __redisShiftCallback 函数的返回值不正确。然而，仅凭此信息无法确定问题的具体原因。 进一步的调试工作集中在 redisGetReply 函数上，因为这个函数在处理事件回调时产生了两个 reply 消息，导致了错误。追踪源码了解到，redisGetReply 负责接收和发送消息，当接收到的消息数量不匹配时，问题可能发生。 通过追踪 redisGetReply 的消息交互，发现在出错前与某个特定的 Redis 集群通信，这个集群是 3.0 版本，可能存在命令不兼容的问题。将这个集群从 Sentinel 监控列表中移除后，其他集群的 Sentinel 添加操作恢复正常，证实了问题确实与该旧版本集群的不兼容性有关。 Redis Sentinel 的故障主要源于状态管理异常、内存分配问题以及不同版本的 Redis 集群之间的命令不兼容。解决策略包括调整批量添加 Sentinel 节点的间隔时间、更换内存分配器、进行 core dump 分析以及对 redisGetReply 的深入追踪。最终，通过识别和隔离不兼容的 Redis 集群，成功解决了 Sentinel 的故障。这也提醒我们在部署 Redis Sentinel 时要注意集群间的版本一致性，以及合理调整系统参数以确保服务的稳定运行。