必须用ZINCRBY而非ZADD实现分数累加，ZREVRANGE须带WITHSCORES并限制count，EXPIRE需按周期分key对齐生命周期。
Valkey（原Redis）在Golang服务中做热点排行榜缓存，核心不是“能不能用”，而是“怎么避免ZSET命令误用导致排名错乱、延迟飙升或内存暴涨”。直接上生产前必须确认三点：ZINCRBY 的原子性是否被业务逻辑绕过、ZREVRANGE 是否带 WITHSCORES 且限制了 count、EXPIRE 是否和排行榜生命周期对齐。
为什么不用 ZADD 而必须用 ZINCRBY 更新分数
热点榜单分数通常是“实时累加”（比如每秒点击+1），不是覆盖写入。ZADD 在 score 已存在时默认不更新，除非显式加 XX 或 CH 参数——但 XX 会跳过不存在的成员，CH 又无法区分“首次添加”和“重复累加”。ZINCRBY 天然满足“有则增、无则建”，且全程原子。
- 错误写法：
ZADD hot_rank 100 user:123→ 第二次调用不会更新分数 - 正确写法：
ZINCRBY hot_rank 1 user:123→ 每次都累加 1 - 注意：
ZINCRBY的increment必须是字符串数字，传"1.5"会报(error) ERR value is not a valid float
如何防止 ZREVRANGE 拉取全量数据拖垮Valkey
排行榜前端只展示前 100 名，但没加 count 参数的 ZREVRANGE hot_rank 0 -1 会遍历整个有序集合——当成员数达百万级时，单次命令耗时可能超 500ms，且阻塞其他请求。
- 必须指定范围：
ZREVRANGE hot_rank 0 99 WITHSCORES（取 Top100 + 分数） - 如果需要分页，用
ZREVRANGE hot_rank 100 199 WITHSCORES，但注意：Valkey 的分页不支持游标，大数据量下建议用ZRANGEBYSCORE配合分数区间做“分数分片” -
WITHSCORES不可省略——否则 Golangredis.ZRangeWithScores返回的[]redis.Z中Score字段为 0
Golang 客户端连接池与超时配置的关键陷阱
Valkey 连接池配置不当会导致“看似连得上，实则慢查询积压”。官方 github.com/redis/go-redis/v9 默认 MaxIdleConns=2，在高并发榜单更新场景下，连接争抢严重，ZINCRBY 延迟毛刺明显。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 调大连接池：
MaxIdleConns: 20、MaxActiveConns: 50（根据 QPS 估算，一般 1000 QPS 至少配 20） - 必须设
ReadTimeout和WriteTimeout（建议 100ms），否则网络抖动时 goroutine 卡死 - 禁用
MinIdleConns（默认 0）——Valkey 是内存数据库，空闲连接不占资源，没必要保活 - 别漏掉
ConnMaxLifetime（建议 30m），避免 NAT 超时断连后复用失效连接
排行榜自动过期与冷热分离的实际做法
纯靠 EXPIRE hot_rank 3600 有问题：过期是被动清理，内存不会立刻释放；且“小时榜”“日榜”“周榜”混在一个 key 里，更新逻辑耦合，一不小心就清错。
- 按周期分 key：
hot_rank:hourly、hot_rank:daily，各自设置不同 TTL - 用
EXPIREAT替代EXPIRE：计算绝对时间戳（如time.Now().Add(24*time.Hour).Unix()），避免因 Valkey 时钟漂移导致提前过期 - 冷数据迁移：每天零点用
ZREVRANGE hot_rank:daily 0 -1 WITHSCORES扫出 Top1000，写入 PostgreSQL 归档表，再ZREMRANGEBYRANK hot_rank:daily 0 999清理
真正麻烦的不是命令怎么写，而是“谁来触发过期”“分数精度要不要截断”“Top100 里并列分数怎么稳定排序”——这些细节没对齐，缓存层反而会成为故障放大器。
