深入分析 braft 中 arm64 架构下日志复制异常问题

问题背景

在分布式一致性协议实现库 braft 中，用户报告了一个在 arm64 架构下出现的日志复制异常问题。具体表现为：在由3个节点组成的复制组中，运行一段时间(1-2天)后，其中一个follower节点的日志索引(index)会落后于leader节点，并且不再更新。

问题现象分析

通过深入调查，我们发现以下关键现象：

1. 当问题发生时，leader节点只会向出现问题的follower发送心跳包(heartbeat)，而不再发送包含日志内容的AppendEntries RPC请求。

2. 日志分析显示，leader节点上的两个日志复制组件在发送完日志后调用log_manager->wait等待新日志时出现了异常行为：

   • 一个日志复制组件的回调没有被调用
   • 另一个日志复制组件的回调被调用了两次 这种异常导致后续不再发送AppendEntries请求。

3. 进一步分析发现，在log_manager的_wait_map flatmap中，wake_up_waiter函数获取到的两个wait meta指针是相同的，这表明存在对象管理问题。

根本原因

经过深入分析，我们定位到问题的根本原因在于butil::get_object的实现机制：

1. butil::get_object使用了thread_local变量来管理对象池

2. 如果在两次butil::get_object/return_object调用之间发生了bthread切换(例如调用了bthread_start_urgent)，就会导致对象管理混乱

3. 具体来说，当log_manager调用wake_up_waiter时，由于bthread切换导致获取到的wait meta对象指针异常，进而影响了日志复制的正常流程

解决方案

针对这个问题，我们找到了两种解决方案：

1. 编译器选项调整：通过添加特定的编译参数可以解决此问题：

   -fno-gcse 
   -fno-cse-follow-jumps 
   -fno-move-loop-invariants
   

   这些选项可以防止编译器进行某些可能影响线程安全性的优化。

2. 升级编译器版本：使用更高版本的编译器(如GCC 7.3以上)也可以避免这个问题，因为新版编译器对这类情况的处理更加完善。

技术启示

这个问题给我们带来了一些重要的技术启示：

1. 线程局部存储(TLS)与协程的交互：在使用协程(bthread)的环境中，需要特别注意thread_local变量的使用，因为协程可能在同一个系统线程中切换，导致TLS状态混乱。

2. 编译器优化的副作用：某些编译器优化可能会在多线程/协程环境中引入难以察觉的问题，特别是在低级别内存操作方面。

3. 架构差异的影响：这个问题在arm64架构下出现，提醒我们在跨平台开发时需要特别注意不同架构下的行为差异。

总结

braft作为分布式一致性协议的高性能实现，其正确性和稳定性至关重要。这次发现的arm64架构下日志复制异常问题，展示了在底层对象管理和协程调度交互中可能存在的陷阱。通过深入分析问题原因并找到解决方案，不仅修复了特定场景下的bug，也为类似系统的开发提供了宝贵的经验教训。