brpc/braft 中 arm64 架构下 replicator 停止发送日志问题的分析与解决

问题背景

在分布式系统中，brpc/braft 是一个广泛使用的 Raft 共识算法实现。近期在 arm64 架构下发现了一个稳定性问题：由 leader 创建的 replicator 在运行一段时间后有概率停止向 follower 发送日志，导致 follower 的日志索引落后且不再更新。

问题现象

在由 3 个节点组成的 Raft 组中，系统运行 1-2 天后会出现以下现象：

1. 其中一个 follower 的日志索引落后于 leader 且不再更新
2. leader 仅向该 follower 发送心跳包，不再发送带有日志内容的 AppendEntries RPC
3. 日志分析显示，leader 的两个 replicator 在等待新日志时出现异常：一个 replicator 的回调未被调用，另一个则被调用了两次

深入分析

通过添加调试日志，发现问题的核心在于 log_manager 的 _wait_map flatmap 操作。更具体的发现包括：

1. 对象指针重复问题：在 wake_up_waiter 函数中，获取到的两个 wait meta 指针相同，这表明存在对象管理问题
2. 线程局部存储问题：butil::get_object 使用了 thread_local 变量，如果在两次 butil::get_object/return_object 调用之间有 bthread 切换（如调用 bthread_start_urgent），就会导致对象管理混乱
3. 编译器优化影响：问题可能与编译器优化有关，特别是在 arm64 架构下

根本原因

问题的根本原因可以追溯到 brpc 中对象池的实现方式。在特定条件下（特别是涉及 bthread 切换时），对象池的管理会出现混乱，导致：

• 同一个对象被多次获取
• 对象状态不一致
• 回调函数调用次数异常

这种问题在 arm64 架构下更为明显，可能与架构特定的内存模型或编译器优化策略有关。

解决方案

经过验证，有以下几种解决方案：

1. 编译器选项调整：添加 -fno-gcse、-fno-cse-follow-jumps 和 -fno-move-loop-invariants 编译参数可以解决此问题
2. 升级编译器版本：使用更高版本的编译器（如 GCC 8+）也可能避免此问题
3. 代码修复：从根本上修复对象池的管理逻辑，确保在 bthread 切换时也能正确处理对象生命周期

最佳实践建议

对于使用 brpc/braft 的开发者和运维人员，建议：

1. 在 arm64 架构下部署时，特别注意此问题的监控
2. 考虑在构建时添加上述编译器选项
3. 保持 brpc 版本的及时更新，关注相关修复
4. 在生产环境部署前，进行充分的长时稳定性测试

总结

这个问题展示了在跨平台开发中可能遇到的微妙问题，特别是在涉及并发、内存管理和编译器优化的场景下。通过深入分析对象生命周期管理和线程局部存储的使用，我们不仅找到了解决方案，也加深了对分布式系统底层机制的理解。对于类似系统的开发和维护，这种对底层细节的关注至关重要。