不能直接用 redis set 做点赞计数，因其无原子计数能力、高并发下 scard 成性能瓶颈、难以处理重复/取消点赞逻辑、内存占用高、全量落盘阻塞主线程；应改用 sorted set + 时间戳实现去重与计数分离。
为什么不能直接用 Redis Set 做点赞计数
因为 SET 本身不带原子计数能力，SADD 返回值只能告诉你“这个 ID 是不是新加入的”，没法直接知道当前总点赞数。如果靠 SCARD 实时查，高并发下会成为瓶颈——每次点赞都要查一次全量集合大小，QPS 上去后 Redis CPU 直接拉满。
更麻烦的是：用户重复点赞、取消点赞这些状态切换，仅靠 SET 很难干净表达。比如用户点两次赞，第二次 SADD 返回 0，但你得额外判断这是“重复操作”还是“已存在”，逻辑容易错漏。
- 真实场景要区分「是否已点」+「当前总数量」两个维度，单靠
SET强行揉在一起，后续扩展（比如显示“你的好友也点了”）会非常吃力 -
SET存的是字符串 ID，如果业务里用户 ID 是int64，转成字符串再存，内存占用比HyperLogLog或Bitmap高出 3–5 倍 - 异步落盘时若只 dump
SET全量，数据量大了会阻塞主线程，Redis 的BGSAVE或BGREWRITEAOF都可能被拖慢
用 Sorted Set + 时间戳做轻量级去重计数
把点赞行为建模成「用户对某视频的一次时间戳标记」，用 ZSET 最合适：member 是 user_id，score 是毫秒级时间戳，天然支持去重（同一 user_id 多次 ZADD 只保留最新 score），还能用 ZCARD 拿总数，ZSCORE 查单个用户是否点过。
关键点在于：写入用 ZADD video:123:likes NX（NX 保证只加一次），查总数用 ZCARD video:123:likes，不碰全量数据遍历。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
NX参数必须加，否则重复点击会覆盖时间戳，导致无法感知“最新互动时间” - score 用毫秒时间戳（不是秒），避免同秒内多次操作冲突；但别用
redis.time()，客户端生成更可控 - 如果需要快速反查“某用户点过哪些视频”，得另建
user:456:liked的SET，不能指望靠ZSET双向索引
异步落盘不是 dump 全量 Set，而是增量发消息
别在点赞接口里调 SMEMBERS 然后塞进 MQ——那是自找死路。正确做法是：每次 ZADD 成功后，立刻往消息队列发一条轻量事件，比如 {"video_id":123,"user_id":456,"action":"like"}，由消费者批量写 DB。
这样 Redis 不承担落盘压力，MQ 也能削峰。哪怕消费者挂了，消息还在队列里，不会丢数据。
- 事件体里不要带时间戳字段，消费者收到时自己打时间戳，避免客户端时钟不准导致排序错乱
- DB 写入用
INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或UPSERT（PostgreSQL），避免双写冲突 - Redis 里可以定期用
ZREMRANGEBYSCORE清理过期点赞（比如只保留最近 30 天），但得避开高峰时段执行
抗住 10w+ QPS 的实际卡点在哪
真正压垮系统的往往不是 Redis 命令本身，而是客户端连接池和序列化开销。比如用 Jedis 默认配置，连接池最大只有 8，瞬间打满就全阻塞；或者用 Jackson 序列化整个对象再发 MQ，CPU 花在 JSON 上比花在业务逻辑上还多。
- Java 客户端务必调大
maxTotal（建议 ≥200），并开启testOnBorrow=false，否则每次取连接都 ping 一次，延迟翻倍 - MQ 消息体必须用二进制协议（如 Protobuf），别用 JSON；字段能用
int32就别用string - Redis 部署要分片，按
video_id % 16分到不同实例，别让所有热点视频挤在一个节点上
最常被忽略的是 DB 落盘的唯一索引设计：(video_id, user_id) 必须建联合唯一索引，否则并发写入时主键冲突会触发重试，把 MQ 积压雪球越滚越大。
