令牌桶限流不能仅靠单机 std::chrono + std::mutex 实现全局限流，因为多进程、多线程或分布式部署下各实例令牌状态无法同步，导致同一用户/接口请求被重复放行；生产环境必须依赖 Redis 等共享存储实现原子性限流，辅以本地缓存和异步调用避免阻塞。
令牌桶限流为什么不能只靠单机 std::chrono + std::mutex
在 HTTP 网关（比如基于 libevent、nghttp2 或自研 C++ 服务）中做全局限流，单机内存计数器（如用 std::unordered_map<:string tokenbucket></:string>）只能管住本进程请求。一旦网关是多进程（fork）、多线程（std::thread）或部署了多个实例，令牌桶状态就不同步——同一用户/接口的请求可能被重复放行，限流形同虚设。
真正能落地的方案必须引入外部共享状态。常见选择有：
-
Redis：用INCR/EXPIRE模拟桶，或用 Lua 脚本原子执行“取令牌+更新时间戳” -
etcd或Consul：适合强一致性场景，但写入延迟高，不适合每请求都查 - 本地缓存 + 分布式协调（如
Redis + 本地滑动窗口预校验）：折中方案，降低 Redis 压力
纯 C++ 不依赖外部服务的“全局”限流，实际只能叫“本机全局”，适用于单实例网关且 QPS 不超 10k 的轻量场景。生产环境请默认走 Redis。
用 Redis 实现线程安全的令牌桶 Lua 脚本怎么写
关键不是 C++ 代码多漂亮，而是 Lua 脚本能否在 Redis 中原子完成：检查剩余令牌、计算是否应补充、扣减并返回结果。下面这个脚本被广泛验证过：
立即学习“C++免费学习笔记（深入）”；
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2]) -- tokens per second
local now = tonumber(ARGV[3])
<p>local bucket = redis.call("HMGET", key, "tokens", "updated_at")
local tokens = tonumber(bucket[1]) or capacity
local updated_at = tonumber(bucket[2]) or now</p><p>local delta = math.min(capacity, tokens + (now - updated_at) * rate)
local allowed = delta >= 1
local new_tokens = allowed and delta - 1 or delta
local new_updated_at = allowed and now or updated_at</p><p>redis.call("HMSET", key, "tokens", new_tokens, "updated_at", new_updated_at)
redis.call("EXPIRE", key, 60) -- auto cleanup
return allowed and 1 or 0调用时传入：KEYS[1] 是桶唯一键（如 "rate:api:/user/profile:uid_123"），ARGV[1] 是容量，ARGV[2] 是速率，ARGV[3] 是当前秒级时间戳（由 C++ 侧生成并传入，避免 Redis 时间不准）。
注意：不要用 TIME 命令获取 Redis 时间，它不保证与客户端时钟一致；也不要省略 EXPIRE，否则键会永久残留。
C++ 客户端调用 Redis 限流时如何避免阻塞和超时雪崩
网关对延迟极度敏感，直接用同步 Redis 客户端（如 hiredis 的 redisCommand）会导致线程卡死。必须满足三个条件：
- 使用异步客户端（如
redis-plus-plus的async_redis，或封装libuv+hiredis的 event loop） - 设置硬性超时（建议 ≤ 5ms），超时即拒绝，不重试 —— 熔断本身就是降级手段
- 把限流结果缓存到本地 LRU（如
boost::container::flat_map），TTL 设为 100ms，避免高频重复打 Redis
示例伪代码逻辑：
bool allow = false;
if (local_cache_.get(key, &allow)) {
return allow;
}
auto future = redis_client->eval(script_, {key}, {capacity_, rate_, std::time(nullptr)});
if (future.wait_for(5ms) == std::future_status::ready) {
allow = (future.get() == 1);
} else {
allow = false; // 超时，熔断
}
local_cache_.put(key, allow, 100ms);这里 local_cache_ 不需要强一致性，它只是减少 Redis 压力的“善意猜测”。哪怕缓存击穿，最坏也只是多放行几条请求，不会导致系统崩溃。
熔断降级怎么和限流联动而不是各自为政
限流管“进”，熔断管“出”。两者必须共享失败信号：当后端服务（如用户中心）连续返回 5xx 或超时超过阈值，应主动关闭对应接口的令牌桶入口，而不是等限流器自己耗尽令牌。
推荐做法是用一个轻量状态机，例如：
- 状态为
HALF_OPEN/OPEN/CLOSED - 后端错误率 ≥ 50% 持续 30 秒 → 切到
OPEN，所有请求立即返回503 Service Unavailable -
OPEN状态持续 60 秒后自动切到HALF_OPEN，放行 5% 请求试探 - 试探请求成功率达 90% → 回到
CLOSED；否则重置计时器
关键点：熔断状态变更要广播（如通过 Redis Pub/Sub 或内存映射文件），否则多进程网关各管各的，降级失效。C++ 里别手写状态机，用 boost::statechart 或简单 std::atomic<int></int> + CAS 就够用。
令牌桶和熔断器的组合策略，最容易被忽略的是“恢复节奏”——熔断关闭后，令牌桶不应立刻满额，而应从低水位缓慢充盈，否则瞬间洪峰会冲垮刚恢复的后端服务。
