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