Beego框架中基于Redis有序集合实现实时排行榜-Golang-PHP中文网

zadd优于set因排行榜需「按分数排序+实时更新」，set无内置排序，查topn需全量内存排序，数据过万即卡；而zset底层用跳表+哈希表，zadd插入/更新为o(log n)，zrange取前n名为o(log n + m)，可扛每秒千级写入。

beego框架中基于redis有序集合实现实时排行榜

为什么用 `ZADD` 而不是 `SET` 存排行榜数据

因为排行榜核心是「按分数排序 + 实时更新」，SET 没有内置排序能力，每次查 TopN 都得全量拉取再内存排序，数据一过万就卡。而 Redis 有序集合（Sorted Set）底层用跳表 + 哈希表实现，ZADD 插入/更新时间复杂度是 O(log N)，ZRANGE 取前 100 名是 O(log N + M)，M 是返回数量——这才是能扛住每秒上千次写入的方案。

Beego 中直接调用 redis.Client 即可操作，别自己封装一层“排行榜服务”再加抽象，反而容易把 ZADD 的 XX（仅更新存在 key）、NX（仅新增）等关键参数漏掉。

ZADD rank:score 85.5 "user_123"：分数是 float，用户 ID 是 string，注意别把分数拼成字符串传进去
如果业务要求“同分时按更新时间升序”，得把时间戳作为次要排序因子，比如 score = base_score * 1e6 + timestamp
Beego 启动时务必检查 redis.DialTimeout 和 redis.ReadTimeout，否则高并发下连接卡住，ZADD 看似成功实则超时丢弃

如何用 `ZRANK` 和 `ZSCORE` 查单个用户排名和得分

用户进个人页想看“当前排第几”，不能用 ZRANGE 全扫再遍历——O(N) 太伤。正确姿势是：ZRANK rank:score "user_123" 返回索引（从 0 开始），加 1 就是名次；ZSCORE rank:score "user_123" 拿实时分数。这两个命令都是 O(log N)，稳。

但 Beego 控制器里容易踩坑：没判空。如果用户从来没上榜，ZRANK 返回 nil，Go 里直接转 int 会 panic；ZSCORE 返回 nil 时也别硬解析成 float64。

用 redis.Int64(reply, err) 之前先 if reply == nil，返回 0 或 -1 表示未上榜
分数字段建议统一用 float64 存，避免整型溢出（比如积分达千万级后 int32 溢出）
别在 HTTP handler 里反复 Do("ZRANK", ...)，提前用 pipeline 打包查排名+分数+总人数（ZCARD），减少 RTT

定时清理过期用户用 `ZREMRANGEBYSCORE` 还是 `ZREMRANGEBYRANK`

要看清理逻辑。如果规则是“分数低于 10 分的踢出”，用 ZREMRANGEBYSCORE rank:score -inf 10；如果是“只保留前 10000 名”，就得用 ZREMRANGEBYRANK rank:score 10000 -1（注意 rank 从 0 开始，10000 表示第 10001 名往后全删）。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

Beego 里通常起一个 cron job，但别直接在 main() 里用 time.Ticker，容易跟热重载冲突。推荐用 beego.BeeApp.AddFunc 注册定时任务，并设好 maxprocs 防止并发清理时 Redis 连接打满。

ZREMRANGEBYSCORE 对 score 有精度要求：Redis 内部存的是 double，但 Go 写入时如果用 fmt.Sprintf("%.1f", score) 再传给 ZADD，读出来可能因浮点误差对不上
清理前先 ZCARD，如果总数不到阈值，跳过后续操作，省资源
线上千万别用 ZREM 逐个删——10 万个用户要发 10 万条命令，网络开销压垮 Redis

Beego 中怎么安全复用 Redis 连接池避免 `connection refused`

错误现象：压测时大量报 read tcp 127.0.0.1:6379: connection refused，不是 Redis 挂了，而是 Beego 默认的 redis.Pool 配置太保守：MaxIdle=3、MaxActive=5，并发一高连接全占满，新请求排队超时后直接失败。

解决方案是在 app.conf 里显式配置，并在 models/init.go 初始化时传给 redis.NewPool：

redis.maxidle = 30
redis.maxactive = 100
redis.idletimeout = 240

然后代码里用 pool.Get() 拿连接，defer conn.Close() 归还——注意不是 defer pool.Close()，后者会关整个池。

别在 controller 里 new 一堆 redis.Pool，每个 pool 都会建独立连接，很快耗尽文件描述符
如果用了 Redis Cluster，Beego 自带的 redis client 不支持，必须换 github.com/go-redis/redis/v8，且初始化方式完全不同
上线前用 redis-cli --latency 测本机到 Redis 的延迟，超过 2ms 就得查网络或 Redis 是否启用了持久化阻塞

Beego 里排行榜看似只是几个 Redis 命令，但 ZADD 的参数策略、连接池大小、浮点精度处理、清理边界条件——这些地方不细抠，流量一上来要么排名错乱，要么接口大面积超时。