valkey连接池需按qps预估并设maxidle=maxactive×0.8，idletimeout=240s；热点保护须用lua脚本原子实现限流，降级开关应独立于valkey存于配置中心，并暴露分原因监控指标。
Valkey连接池配置必须匹配服务并发模型
Go服务里用Valkey做热点保护，连接池配小了会卡住请求，配大了又浪费资源。关键不是最大连接数，而是MaxIdle和MaxActive的比值——通常设为MaxIdle = MaxActive * 0.8，避免空闲连接过多被Valkey主动断开（默认timeout 300），也防止突发时频繁建连。
常见错误是直接套用Redis文档里的默认值（比如MaxActive=10），结果高并发下大量goroutine阻塞在Get上。实际应按服务QPS预估：若峰值QPS 500，单请求平均Valkey耗时 2ms，则理论最小连接数 ≈ 500 × 0.002 = 1；但必须留余量，建议起步设MaxActive=32，上线后看valkey-cli info clients里的connected_clients和client_longest_output_list是否持续升高。
-
IdleTimeout设为240 * time.Second，略小于Valkey的timeout，避免连接被服务端静默断开后客户端仍尝试复用 - 禁用
TestOnBorrow——Valkey响应快，每次取连接都PING反而拖慢吞吐 - 用
redis.DialReadTimeout(500 * time.Millisecond)而非默认0，防网络抖动导致goroutine永久挂起
用Valkey Lua脚本原子判断+计数防穿透
单纯用INCR + EXPIRE两步走，在并发下会漏判：两个请求同时读到0，都去执行INCR，结果计数变成2但只该放行1个。必须用Lua脚本保证原子性，且脚本里要区分“首次触发”和“后续续命”。
典型场景：某商品详情页缓存失效，瞬间1000个请求打到后端。用以下脚本控制每秒最多放行50个：
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current = redis.call("INCR", key)
if current == 1 then
redis.call("EXPIRE", key, window)
end
return current <p>Go里调用：<code>client.Eval(ctx, script, []string{hotKey}, limit, window).Bool()</code>。注意<code>window</code>不能设太短（如1s），否则窗口切换时会出现计数归零后的瞬时洪峰；也不宜过长（如60s），否则热点消退后保护还残留。</p>
- 脚本返回
true表示放行，false表示拒绝，业务层据此返回503 Service Unavailable - key建议带业务前缀+参数哈希，例如
"hot:product:" .. md5(id)，避免不同商品共用一个计数器 - 不要在脚本里做
GETSET之类操作——Valkey集群模式下Lua脚本要求所有key落在同一slot，GETSET可能跨slot失败
降级开关必须独立于Valkey可用性
Valkey挂了，保护器本身不能跟着失效——否则雪崩直接发生。所以“是否启用热点保护”这个开关不能存在Valkey里，而要放在本地内存或配置中心。
推荐做法：启动时从配置中心拉取hot_protect_enabled布尔值，存入sync.Map，每5分钟轮询刷新；同时监听Valkey连接状态，一旦连续3次PING超时，自动将本地开关置为false并打告警日志，而不是抛错中断流程。
- Valkey不可用时，直接返回
true（放行），宁可短暂过载，也不能因保护器故障引发级联失败 - 配置中心要用强一致存储（如etcd），避免多实例开关不同步
- 开关变更需记录
log.Printf("hot protect switch changed to %v by %s", newVal, source)，方便事后追溯
监控指标必须暴露具体拦截原因
只看“总拦截数”没用。得拆开：是限流触发？还是Valkey超时降级？或是配置开关关闭？否则半夜告警来了只能盲猜。
用prometheus暴露三个指标：
-
valkey_hot_protect_blocked_total{reason="rate_limit"}—— Lua脚本返回false次数 -
valkey_hot_protect_blocked_total{reason="valkey_unavailable"}—— Valkey不可用时的被动放行计数（反向指标） -
valkey_hot_protect_enabled{state="true"}—— 开关当前状态（gauge类型）
特别注意：reason="valkey_unavailable"这个指标值上升，说明Valkey真的出问题了，而不是保护逻辑误杀——这是唯一能区分“保护生效”和“保护失灵”的依据。
Valkey本身也要开latency-monitor-threshold 10，配合redis-cli --latency -h x.x.x.x查毛刺点。很多“雪崩”其实源于Valkey慢查询阻塞了整个事件循环，不是Go代码的问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
