不能直接用std::condition_variable做跨节点同步，因其仅支持进程内共享内存同步，无法感知网络且notify_all对远程节点无效；真实场景需序列化+网络传输+远程唤醒。
大规模分布式系统里，节点同步不是靠“等一等”或“轮询一下”就能解决的。C++ 实现时，必须把网络延迟、分区容忍、状态不一致这三类现实问题直接编译进逻辑——否则上线后遇到脑裂或时钟漂移，std::condition_variable 等不到信号，std::mutex 锁不住跨节点状态。
为什么不能直接用 std::condition_variable 做跨节点同步
std::condition_variable 是进程内同步原语，依赖共享内存和原子指令，完全不感知网络。它内部的等待队列只在本进程线程间生效，调用 notify_all() 对其他机器上的线程毫无作用。
- 常见错误现象：本地测试一切正常，一上集群就出现“任务卡住”“节点状态长期不更新”，其实是误把条件变量当 RPC 通知用了
- 真实场景中，节点 A 修改了本地状态并想通知节点 B，必须走序列化 + 网络发送 + 远程反序列化 + 本地唤醒这一整套流程
- 性能影响：如果硬要在每个远程事件后触发本地
cv.notify_one()，会掩盖真正的瓶颈——网络往返（RTT）和序列化开销远大于条件变量本身
用 Raft + gRPC-C++ 实现带日志复制的节点同步
Raft 是目前 C++ 分布式系统中最易落地的一致性协议，gRPC-C++ 提供了强类型的 RPC 框架，二者组合能覆盖多数节点同步需求。
- 关键点：Raft 的
AppendEntries请求本质就是一种“同步指令”，它携带任期号、日志索引、前一条日志哈希，接收方校验通过后才提交日志并 apply 到状态机 - 不要自己手写心跳包：gRPC 的
KeepAlive配置（如GRPC_ARG_KEEPALIVE_TIME_MS）比轮询ping更可靠，且能自动触发连接重建 - 注意日志压缩：大规模系统运行数天后，
logs容易撑爆内存，必须配合快照（snapshot）机制，而gRPC-C++的 streaming RPC 天然适合传输大块快照数据
本地状态机如何响应远程同步事件
远程日志提交成功后，状态机要立即反映到本地业务逻辑，但不能阻塞网络线程。典型做法是把 apply 动作投递到工作线程池，再由线程池触发条件变量或原子标志位。
- 容易踩的坑：在
Apply()回调里直接调用cv.notify_all()—— 如果网络线程和业务线程共用一个std::mutex，可能引发优先级反转或锁竞争 - 推荐结构：
std::atomic<bool> ready_flag{false}</bool>用于轻量通知；重逻辑（如更新哈希表、刷新缓存）交由独立线程处理 - 参数差异：
std::atomic_thread_fence(std::memory_order_release)必须出现在 flag 设置前，否则其他线程可能读到 stale 值——这是 CPU 缓存一致性问题，不是代码逻辑问题
租约机制防止假同步
节点间时钟不同步是常态。单纯依赖“收到日志就认为已同步”会导致脏读。Raft 的 leader 租约（lease）+ 客户端租约（client lease）双层机制才是工业级解法。
- leader 租约：leader 在任期内持续向 followers 发送带时间戳的心跳，followers 只接受该租约期内的日志，超时即拒绝——这需要
std::chrono::steady_clock，不能用system_clock - 客户端租约：每个写请求返回时附带租约过期时间（如 10s），客户端在此期间可跳过 read-after-write 的二次确认，但必须检查租约是否 still valid
- 性能影响：租约机制带来少量时间判断开销，但避免了大量 read quorum 和 linearizable read 的网络交互，整体吞吐反而更高
真正难的不是实现 Raft 或封装 gRPC，而是理解“同步”在分布式语境下早已不是“所有节点值一样”，而是“所有节点对某个操作的执行顺序达成共识”。这个共识一旦被打破，std::mutex 和 std::atomic 都救不了——它们只管得了本机，管不了网络另一头那个正在重启的节点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
