DragonflyDB 中 CondVarAny::notify_all 导致的 Master 崩溃问题分析

问题背景

在 DragonflyDB 的最新版本中，开发团队发现了一个严重的稳定性问题：Master 节点在执行 CondVarAny::notify_all 操作时会发生崩溃。这个问题主要出现在连接处理流程中，特别是在处理异步光纤(AsyncFiber)和连接光纤(Connection Fiber)之间的同步时。

崩溃现象

当系统尝试通过 CondVarAny::notify_all 通知被阻塞的连接光纤时，会出现以下崩溃现象：

1. 崩溃发生在 WaitQueue::NotifyAll 函数中
2. 核心转储分析显示，通知方和被通知方的调度器(scheduler)不一致
3. 崩溃点位于 Boost 的侵入式链表操作中，具体是在设置链表节点指针时

技术分析

线程调度问题

最初怀疑是连接迁移(connection migration)导致的问题，即异步光纤和连接光纤运行在不同的线程上。然而，进一步的核心转储分析显示，在某些情况下，即使调度器显示为同一线程，崩溃仍然会发生。

根本原因

深入分析后发现，问题的根本原因在于：

1. 连接光纤在等待管道操作时被阻塞
2. 异步光纤尝试通过条件变量通知连接光纤
3. 在通知过程中，Boost 的侵入式链表操作出现异常
4. 链表节点指针被错误地设置为空值，导致后续操作崩溃

代码层面

在 dragonfly_connection.cc 文件的第1640行附近，notify_all 被调用来唤醒被阻塞的连接光纤。这个操作本应在同一线程上下文中安全执行，但由于某种原因，线程调度状态出现了不一致。

解决方案

开发团队已经确认这是一个从1.26.x版本引入的回归问题。为了解决这个问题：

1. 已经准备了修复补丁
2. 计划发布1.27.3版本专门修复此问题
3. 修复方案主要涉及确保条件变量通知时的线程一致性

影响范围

这个问题会影响所有使用异步光纤处理连接的场景，特别是在高负载情况下可能导致Master节点不稳定甚至崩溃。对于生产环境，建议尽快升级到包含修复的版本。

预防措施

为了避免类似问题，开发团队建议：

1. 加强对跨线程同步机制的测试
2. 在条件变量操作前后增加状态验证
3. 对关键路径添加更多的日志记录，便于问题诊断

总结

DragonflyDB 中这个 Master 崩溃问题展示了即使在看似简单的同步操作中，线程调度和状态管理也可能带来复杂的挑战。通过这次问题的分析和解决，开发团队进一步强化了对光纤和线程交互的理解，为系统的长期稳定性打下了更好的基础。