Sentinel故障排查：Redis Sentinel assert错误分析与解决

"redis sentinel故障排查过程记录" 在Redis Sentinel系统中，当遭遇异常退出或错误时，需要进行详细的故障排查来找到问题根源。本案例中，Sentinel在批量加入Redis集群的Master节点过程中遇到了一个断言错误，发生在`async.c`的特定位置，显示出Sentinel服务的状态不一致，既未处于监控状态，也未处于订阅状态。 首先，尝试通过网络上的建议解决，即增加批量添加Sentinel节点的时间间隔，从1秒逐步调整到5秒和10秒，但这种方法并未解决问题，错误依然发生。 接着，进行系统调用跟踪(strace)以获取更多线索。在程序崩溃前，发现与`chunk_mmap.c`中的某个函数调用有关，这引发了对jemalloc内存管理器的怀疑。尝试将Redis的编译选项改为使用glibc作为内存管理，这一改变在一台机器上暂时成功，但在另一台机器上出现问题。检查所有机器上的jemalloc组件版本，并无差异，因此这个方案虽然在单机测试中有效，但未能彻底解决问题。 进一步，通过创建coredump并分析堆栈信息，发现在`__redisShiftCallback`函数返回值异常，可能是触发错误的原因。由于上下文信息不足，无法确定进入这段代码的具体路径。 为了补充上下文信息，对代码进行了调试增强。调试结果显示，处理事件的回调函数只有一个，但`redisGetReply`函数却产生了两个回复消息，导致在获取第二个回调时出错。源码分析显示，`redisGetReply`主要负责接收和发送消息，可能存在多条消息处理不协调的情况。 最后，通过追踪`redisGetReply`的执行情况，记录每次接收和发送的消息，发现错误发生前的最后一个操作涉及某个特定的Redis集群。因此，推测问题可能出在这个集群上，尝试在添加Sentinel监控的集群列表中移除这个集群，结果发现其他集群的Sentinel添加成功。 这个排障过程体现了Redis Sentinel故障排查的关键步骤：理解源码、系统调用跟踪、coredump分析、调试信息收集以及有针对性地隔离问题。在实际运维中，面对类似的复杂问题，应具备耐心和细心，通过多角度分析和实验来定位并解决故障。