std::atomic仅保证单机缓存一致性，无法跨节点同步，故不适用于分布式令牌桶；需用redis的incrby+expire等支持cas与ttl的方案实现全局限流。
为什么 std::atomic 不能直接用于跨节点令牌桶同步
分布式场景下，单机用 std::atomic_int 做本地桶计数没问题，但一上集群就失效——原子操作只保证本机缓存一致性，不触达其他服务实例。常见错误是把本地限流逻辑原封不动搬到微服务里，结果压测时发现 QPS 超阈值、熔断失效，日志里全是 rate limit exceeded 但各实例统计自说自话。
- 真正需要的是「全局单调递增 + 低延迟读写」的共享状态，
std::atomic不提供跨进程/跨网络语义 - Redis 的
INCRBY+EXPIRE组合是更现实的选择，它天然支持 CAS 语义和 TTL 自动清理 - 若强行用 Raft 或 etcd 做协调，会引入 50ms+ P99 延迟，对毫秒级接口不友好；优先选 Redis Cluster 或 Codis 这类已验证的分片方案
如何用 redis-plus-plus 实现带滑动窗口的令牌预取
纯靠每次请求都 INCRBY 会压垮 Redis，尤其在突发流量下。正确做法是在客户端做一层轻量预取：按周期从 Redis 批量拿一批令牌到本地内存，再用 std::atomic_int 消费，降低网络往返次数。
- 预取窗口设为 100ms，每批取
burst_size / 10个令牌（例如 1000 QPS 配 100 burst，则每批取 10 个） - 用
redisClient.evalsha执行 Lua 脚本，保证INCRBY和EXPIRE原子执行，避免过期 key 被重复初始化 - 注意 Lua 脚本中不能用
redis.call("TIME")，应传入客户端时间戳参数，否则 Redis 集群时钟不同步会导致 TTL 错乱
-- 示例 Lua 脚本（传入 key, delta, ttl_ms）
local current = redis.call("INCRBY", KEYS[1], ARGV[1])
if tonumber(current) == tonumber(ARGV[1]) then
redis.call("PEXPIRE", KEYS[1], ARGV[2])
end
return current
std::chrono::steady_clock 在重置桶时为何比 system_clock 更可靠
限流器常需按固定周期重置桶（比如每秒清零），若用 std::chrono::system_clock，遇到 NTP 校时跳变或手动调时间，可能触发多次重置或完全跳过，导致限流失效或误拦截。
-
steady_clock是单调递增的，不受系统时间调整影响，适合做周期判断 - 典型用法：记录上一次重置的
steady_clock::time_point，每次请求前检查是否超过1s，而不是依赖「当前秒数是否变化」 - 不要用
time(nullptr)或gettimeofday()做重置依据，它们都属于 wall-clock 类型，生产环境出过问题
为什么 Redis key 设计必须包含 service_name + endpoint + client_ip
只用 rate:login 这种粗粒度 key，会导致全局限流变成“一人被封，全员陪绑”。真实微服务里，不同服务、不同接口、甚至不同来源 IP 的流量特征差异极大，key 必须带上下文维度。
立即学习“C++免费学习笔记（深入）”；
- 推荐格式：
rate:{service}:{endpoint}:{client_hash}，其中client_hash是 IP 哈希后取模（如std::hash<:string>{}("10.1.2.3") % 100</:string>），避免 key 过多打散 Redis - 别把 user_id 直接塞进 key——OAuth 透传链路长，且存在脱敏合规风险；IP 哈希已足够区分流量源
- 如果用 Redis Cluster，确保 hash tag
{...}包裹的部分能路由到同一 slot，否则MGET批量查询会失败
最易被忽略的是 key 生命周期管理：没配 EXPIRE 的桶 key 会永久残留，几周后 Redis 内存暴涨。务必在首次写入时用 PEXPIRE 设定略大于窗口的 TTL（比如 1.1 秒），并接受少量过期 key 存在——比内存泄漏好处理得多。
