Valkey项目中TLS测试期间引擎崩溃问题分析

问题背景

在Valkey项目进行TLS测试时，发现了一个在双通道复制模式下导致引擎崩溃的问题。该问题发生在从节点(replica)侧，当主从节点之间的网络连接出现问题时，会导致从节点在加载RDB数据时发生崩溃。

崩溃堆栈分析

从崩溃堆栈可以看出，问题发生在SSL读取操作期间。具体调用路径显示：

1. 从libssl库的SSL_read函数开始
2. 经过Valkey的rdbLoadRioWithLoadingCtx函数
3. 最终在readSyncBulkPayload函数中触发崩溃

这表明问题与TLS加密通信和RDB数据加载过程密切相关。

根本原因分析

经过深入调查，发现问题源于Valkey双通道复制机制的特殊工作方式：

1. 双通道连接机制：在双通道复制模式下，从节点会与主节点建立两个连接：

   • repl_transfer_s：用于读取PSYNC数据
   • repl_rdb_transfer_s：专门用于RDB数据传输

2. RDB加载过程：从节点在加载RDB数据时，会进入rdbLoadRioWithLoadingCtx函数中的紧密循环。

3. 网络中断处理：

   • 正常情况下，网络中断会在repl_rdb_transfer_s连接上通过rioRead操作被检测到
   • 但在某些情况下，中断可能首先在repl_transfer_s连接上被检测到，特别是在rdbLoadProgressCallback回调函数释放CPU处理epoll事件时

4. 资源清理问题：

   • 当repl_transfer_s连接中断被检测到时，系统会调用cancelReplicationHandshake清理所有复制连接和状态
   • 这会通过replicationAbortDualChannelSyncTransfer关闭并清理repl_rdb_transfer_s连接
   • 然而，程序随后会返回到rdbLoadRioWithLoadingCtx循环，并尝试在未被置空或标记为已释放的rio连接上执行rioRead操作

解决方案

针对这个问题，提出了以下解决方案：

1. RIO连接状态标记：在rio结构中添加一个标志位，用于指示连接应该尽快中止。这样可以在下一次IO操作时安全地终止连接，避免在已关闭的连接上继续操作。

2. 连接状态同步机制：确保在清理复制连接时，所有相关的IO操作都能及时感知到连接状态的变化，避免出现状态不一致的情况。

技术启示

这个问题揭示了分布式系统中连接管理和状态同步的重要性：

1. 多连接协调：当系统使用多个连接协同工作时，需要特别注意它们之间的状态同步和错误处理。

2. 资源清理顺序：在清理资源时，必须确保所有相关的操作都能感知到资源状态的变化，避免出现悬垂指针或无效操作。

3. 异步事件处理：在紧密循环中处理异步事件时，需要特别注意可能出现的竞态条件和状态不一致问题。

总结

Valkey在双通道复制模式下遇到的这个TLS相关问题，展示了分布式存储系统中网络通信和数据处理流程的复杂性。通过分析这个问题，我们不仅找到了具体的解决方案，也加深了对复制机制和连接管理的理解。这类问题的解决有助于提高Valkey在高负载和复杂网络环境下的稳定性。