ZSET适合存点赞数因其天然支持按分数排序和范围查询，而INCR+HASH方案无法高效获取热度榜单；ZSET的member应为动态ID，score为点赞数，用无条件ZADD覆盖更新，HASH存储用户点赞状态以节省内存。
为什么用 ZSET 存点赞数而不是 INCR + HASH 单独计数
直接对每个动态用 INCR 记点赞总数，再用 HASH 存用户是否点过，看似简单，但无法高效回答“当前热度前10的动态是哪些”。ZSET 天然支持按分数（如点赞数）排序和范围查询，ZREVRANGE post:zset 0 9 WITHSCORES 一行就拿到实时榜单。而纯计数方案得先查所有动态ID、再逐个 HGET 点赞数、最后在应用层排序——数据量一上去就卡住。
实操建议：
-
ZSET的member用动态唯一 ID（如"post:123"），score设为当前点赞数，每次点赞/取消点赞都用ZADD覆盖更新 - 不要把用户ID塞进
ZSET成员里——那会混淆“被点赞对象”和“点赞人”，查排行榜时无法区分主体 - 如果点赞数可能为小数（比如加权热度），
ZSET支持浮点score，整数反而要转成float避免精度丢失
怎么防止同一用户重复点赞——HASH 存用户动作比 SET 更省空间
判断用户 A 是否已点过动态 B，最直觉是建一个 SET：如 liked:post:123，SISMEMBER 查，SADD 加。但用户量大时，每个动态一个 SET 会产生海量小 key，Redis 内存碎片和元数据开销明显上升。
改用 HASH：以动态 ID 为 key，用户 ID 为 field，固定值（如 "1"）为 value。例如：HSET liked:post:123 uid:456 "1"。好处是：
立即学习“Python免费学习笔记（深入）”；
- 所有用户对同一动态的点赞记录收敛到一个 key，节省 key 数量级
-
HGET比SISMEMBER少一次哈希寻址（HASH内部是字典，field直接定位） - 后续若要统计“某用户点过哪些动态”，可另建
SET或ZSET（如liked:uid:456），不与主逻辑耦合
ZADD 更新分数时，必须用 XX 或 NX 吗？实际应无条件覆盖
常见误区：以为点赞数增加要先 ZSCORE 查旧值，再 ZADD XX 更新。这引入竞态——两个请求并发时，可能都读到旧值，导致只加了1次而非2次。
正确做法是让业务层算出**目标分数**，然后无条件 ZADD：
# 用户A点赞 → 当前总点赞数 = 原值 + 1
redis.zadd("post:zset", { "post:123": current_score + 1 })
<h1>用户B取消点赞 → 当前总点赞数 = 原值 - 1</h1><p>redis.zadd("post:zset", { "post:123": current_score - 1 })
关键点：
-
ZADD对已有 member 是原子覆盖，不存在中间态；只要业务层能保证“加1/减1”的计算逻辑一致，就无需锁 - 别用
XX（仅更新存在 member）或NX（仅新增），否则首次点赞可能失败——因为ZSET里还没这个 member - 如果需要严格精确（比如防刷），应在应用层做限流或校验，而不是依赖
ZADD选项
排行榜分页卡顿？ZREVRANGEBYSCORE 比 ZREVRANGE 更危险
用 ZREVRANGE post:zset 0 9 拿前10名很稳；但有人想“查点赞数在100~500之间的动态”，改用 ZREVRANGEBYSCORE post:zset 500 100。问题来了：如果大量动态分数相同（比如都为0），Redis 会遍历所有 score=0 的 member 直到凑够 limit，O(N) 时间复杂度，延迟飙升。
规避方式：
- 避免用
ZREVRANGEBYSCORE做非精确分页，尤其分数分布密集时 - 真要按分数区间查，给
member拼接时间戳后缀（如"post:123:1712345678"），让相同分数的 member 也天然有序，再配合WITHSCORES+ 应用层过滤 - 更稳妥的是：排行榜只走
ZREVRANGE+ 游标（cursor），前端传上次返回的最小 score 和对应 member，后端用ZREVRANGEBYSCORE ... LIMIT 10精确续查
复合操作本身不难，难的是各数据结构边界清晰——ZSET 只管排序依据，HASH 只管用户动作事实，别让一个结构承担两种语义。稍一混淆，扩容或排查时就会发现某个 key 内存暴涨却不知源头。
