ZINCRBY是排行榜更新的唯一合理选择，因其原子性完成“读当前分+加增量+写回”，避免并发覆盖；ZREVRANGE降序拉榜需带WITHSCORES；WebSocket推送须按需定向且解耦业务。
直接用 ZINCRBY 更新分数 + ZREVRANGE 拉取榜单 + WebSocket 主动推送，就能撑住万级并发的实时排行榜。别碰全量重算、别在 HTTP 轮询里硬扛。
为什么 ZSet 的 ZINCRBY 是排行榜更新的唯一合理选择
排行榜不是静态快照，是持续变化的动态集合。用户打赏、下单、发帖都会触发分数变更——如果每次更新都先 ZSCORE 再 ZADD，就引入了竞态和额外 RTT；而 ZINCRBY 是原子操作，一次网络往返完成“读+改+写”，且天然支持增量更新（比如礼物榜加 50 分，不是设成 50 分）。
- 不支持负分？
ZINCRBY rank_key -10 "user1"合法，直接扣分 - 分数为 0 时首次插入？
ZINCRBY会自动初始化，无需预判 - 并发写冲突？Redis 单线程保证原子性，不用加分布式锁
- 误用
ZADD替代？会导致覆盖原分，而非累加，这是线上最常见翻车点
WebSocket 连接管理必须解耦业务逻辑
排行榜推送不是“有更新就群发所有客户端”，而是按需定向：只推给订阅了该榜单的用户，或只推给当前在线且在 TOP 100 内的用户。否则一个热门榜单更新，会引发连接雪崩。
- 别把用户 ID 和 WebSocket
session存在内存 Map 里——进程重启就丢，水平扩展失效 - 必须用 Redis Hash 或 String 记录
user_id → gateway_node:port映射，配合 Pub/Sub 路由消息 - 客户端要带榜单类型参数建立连接，例如
wss://api.example.com/rank?rankType=daily_income，服务端据此做频道订阅 - 心跳检测不能只靠
ping/pong，得结合 Redis 的EXPIRE设置连接有效期，防假死连接堆积
ZREVRANGE + WITHSCORES 拉榜单时的三个硬限制
前端请求“查 TOP 50”，后端不能无脑执行 ZREVRANGE rank_key 0 49 WITHSCORES 就完事。真实场景下，这个命令会因数据规模、网络、序列化方式产生隐性瓶颈。
- 别返回原始
member字符串（如"u_12345"），必须提前用 Hash 补全用户昵称、头像等字段，避免前端再发 N 次查询 - 限制最大拉取长度，比如
ZREVRANGE rank_key 0 999是危险操作，ZSet 超过 10 万成员时延迟明显上升，应强制count ≤ 200 - 用户查自己排名要用
ZREVRANK，不是遍历结果找位置——O(log N) vs O(N)，10 万数据下差 100 倍耗时
真正难的不是单点技术，而是当 ZSet 里有 80 万用户、每秒 3000 次 ZINCRBY、同时 12 万 WebSocket 连接在线时，如何让 PUB/SUB 消息不堆积、让网关节点不成为单点瓶颈、让每个用户看到的“实时”时间窗口保持一致——这些不会报错，但会让排行榜看起来“卡两秒又跳一下”。
