ZINCRBY 是更新 Redis 有序集合排行榜分数的唯一合理方式，它原子性处理成员存在与否，避免并发覆盖；需传 double 类型增量，慎用小数以防浮点误差；取 Top N 应用 ZREVRANGE 而非 ZREVRANGEBYSCORE。
Redis ZSet 的 ZINCRBY 是更新排行榜分数的唯一合理方式
直接用 ZINCRBY，别写先查再 ZADD 或 ZREM + ZADD。ZSet 本身不支持“原子性地加一个不存在的成员”，但 ZINCRBY 天然处理：成员不存在就从 0 开始加，存在就累加——这正是热门榜“点击+1”“播放+1”的核心语义。
常见错误是用 ZSCORE 查分、Java 里算完再 ZADD，结果并发时覆盖彼此；或者误以为 ZADD 第二个参数能传表达式（比如 ZADD hot:rank 1+1 "item1"），实际会报错 ERR value is not a valid float。
-
ZINCRBY hot:rank 1 "article:123"—— 安全、原子、一行搞定 - 分数类型必须是 double，别传字符串如
"1"（虽然 Redis 会强转，但易混淆） - Java 客户端（如 Lettuce / Jedis）调用时，确保传入的是
double类型值，不是int或String
Java 中用 Lettuce 调用 ZINCRBY 的典型写法与线程安全注意点
Lettuce 默认是线程安全的连接池，但别在多个线程里共用同一个 RedisCommands 实例（它是有状态的）。正确姿势是每次从 RedisClient 获取新命令对象，或直接用 StatefulRedisConnection 的 sync() 方法。
示例片段（Spring Boot + Lettuce）：
立即学习“Java免费学习笔记（深入）”；
RedisTemplate<String, String> redisTemplate;
// ...
redisTemplate.opsForZSet().incrementScore("hot:rank", "video:456", 1.0);
这个 incrementScore 底层就是 ZINCRBY，封装干净。但要注意：
- 如果用原生 Lettuce
RedisStringCommands，必须显式调用zIncrBy，参数顺序是key, increment, member - 别把分数写成
1（int），Lettuce 对int和double重载不同，传int可能触发意外的字符串解析逻辑 - 若需批量更新（比如一次刷 10 个视频的热度），用
ZINCRBY单条执行即可，Redis 本身不支持批量ZINCRBY，强行合并反而增加复杂度
排行榜取 Top N 时，ZREVRANGE 和 ZREVRANGEBYSCORE 别混用
热门榜要“按分数降序取前 100”，无条件用 ZREVRANGE hot:rank 0 99 WITHSCORES。它快、语义直白、不用管分数范围。
ZREVRANGEBYSCORE 是为“取分数在 [80, 100] 区间内的所有成员”设计的，用在排行榜场景反而容易出错：
- 初始没人打分时，所有分数是 0，
ZREVRANGEBYSCORE hot:rank 100 0会返回空——因为 100 > 0，而该命令要求第一个 score ≥ 第二个 score - 分数是浮点数，用
ZREVRANGEBYSCORE做范围查询可能因精度丢数据（比如100.0000001被截断） - 想翻页？
ZREVRANGE支持 offset/limit，ZREVRANGEBYSCORE的WITHSCORES+LIMIT组合难调试，且无法跳过重复分数的并列问题
分数设计不当会导致排序失真，整数倍增比小数更稳妥
别用 ZINCRBY hot:rank 0.1 "item" 这类小数增量。浮点误差累积后，ZREVRANGE 返回顺序可能和预期不符（尤其当大量 item 分数接近时）。Redis 内部用 double 存储，但排序依据是实际二进制值，不是十进制显示值。
真实项目中，统一用整数倍增最省心：
- 点击量 → ×1，播放量 → ×10，分享量 → ×50，这样权重分明，又全是整数
- 分数上限不必担心溢出：long 最大值约 9×10¹⁸，就算每秒 1 万次操作，也要运行 3000 年才到
- 如果后期要加衰减（比如按小时衰减），用整数时间戳做 base，再乘以权重，避免小数参与主排序逻辑
真正难处理的不是语法或 API，而是“什么时候该清旧数据”和“怎么让冷门内容偶尔露头”——这两个没标准答案，得看业务是否允许人工干预或引入随机扰动。
