轮询负载均衡的核心逻辑是按顺序循环分配请求，仅维护“下一个该选谁”的索引，不考虑节点负载或响应时间；实现关键在于索引的状态保存与线程安全，多线程下必须用原子操作（如AtomicInteger或std::atomic_size_t）避免竞态，否则会导致重复选取或跳过节点。
轮询负载均衡的核心逻辑是什么
轮询（Round Robin）的本质是按顺序把请求分发给后端节点，每次选一个，循环往复。它不关心节点当前负载或响应时间，只维护一个“下一个该用谁”的索引。实现的关键不是复杂计算，而是状态的正确保存和线程安全——尤其在多线程环境下，next_index 变量必须避免竞态。
单线程下怎么写最简轮询
用一个整型变量记录当前索引，每次取模后递增即可。注意边界：空列表要提前检查，否则 % 0 会崩溃；索引更新必须在取值之后，否则第一次就跳过了首节点。
class RoundRobinBalancer {
std::vector<std::string> servers_;
size_t next_index_ = 0;
public:
explicit RoundRobinBalancer(const std::vector<std::string>& servers)
: servers_(servers) {}
std::string next() {
if (servers_.empty()) return "";
auto server = servers_[next_index_];
next_index_ = (next_index_ + 1) % servers_.size();
return server;
}
};
-
servers_不能在运行中动态变更，否则next_index_可能越界 - 如果后端列表变化频繁，建议改用原子操作或加锁，而不是依赖“不变”假设
- 返回
""是临时兜底，生产环境应抛异常或返回std::optional<std::string>
多线程下为什么直接++会出错
多个线程同时执行 next_index_ = (next_index_ + 1) % servers_.size() 时，读-改-写三步非原子，可能丢失一次递增。现象是：两个请求拿到同一个 server，而另一个 server 被跳过。这不是概率问题，是必然发生的竞态。
- 用
std::atomic_size_t next_index_替代普通size_t - 改用
next_index_.fetch_add(1, std::memory_order_relaxed) % servers_.size() - 不要用
++next_index_，它等价于非原子的读写，无法保证线程安全 - 如果服务器列表可能动态增删，还需对
servers_加读写锁，否则fetch_add后取模时servers_.size()已变
实际部署时容易被忽略的细节
轮询看着简单，但线上出问题往往不在算法本身，而在配套机制缺失。
立即学习“C++免费学习笔记（深入）”；
- 没有健康检查：挂掉的 server 还在轮询队列里，请求持续超时 → 需配合定时探测+移除逻辑
- 没有权重支持：所有节点一律平等，但真实机器配置不同 → 若需加权轮询，不能只改索引，得预生成带重复的 server 列表或改用累积权重法
- 实例重启后
next_index_归零：导致流量瞬间打到第一个节点 → 可持久化索引，或用一致性哈希类方案替代 - gRPC 或 HTTP/2 多路复用下，单连接内多个请求共享同一个 backend，轮询粒度需对齐连接生命周期，而非单个请求
