短视频点赞场景下，set 更稳妥；bitmap 虽省内存但必须将用户 id 重映射为紧凑逻辑 id，否则因 offset 过大导致内存爆炸，且无法反查用户、不支持原子互斥操作。

直接说结论：短视频场景下，Set 更稳妥，Bitmap 有明显收益但必须严控 offset 范围，否则极易因用户 ID 稀疏或错配导致内存爆炸。

为什么短视频点赞不能无脑用 Bitmap

Bitmap 的 offset 是按用户 ID 当作数组下标用的。如果系统里用户 ID 是自增主键，且从 1 开始、连续、不跳号，那 SETBIT video:123 456789 1 是安全的；但现实中短视频平台的用户 ID 往往是雪花算法生成（如 1298473029485720394），直接当 offset 会导致 Redis 分配数百 MB 甚至 GB 内存——这不是“省空间”，是制造事故。

真实踩坑案例：某平台误将商户 ID（起始值设为 21 亿）作为 offset，单个 SETBIT 就触发 Redis 分配约 250MB 内存，集群迅速 OOM。

• offset 超过 1000 万时，内存占用 ≈ offset / 8 / 1024 / 1024 MB，不是线性增长，是按最大下标向上取整分配整块内存
• 无法用 GETBIT 判断“某个大 ID 是否存在”，只能确认“该偏移位是否为 1”，但中间大量 0 位已占满内存
• 不支持反查：“查出所有给视频 123 点过赞的用户”这种需求，Bitmap 完全做不到

Set 实现点赞/踩的最小可行结构

用两个独立 key 分离点赞和点踩，避免逻辑耦合：

• 点赞集合：like:video:123
• 点踩集合：dislike:video:123

关键操作全部基于原生命令，不依赖业务层判断状态：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 用户点赞：SADD like:video:123 456789（重复执行无副作用）
• 用户点踩：SADD dislike:video:123 456789
• 取消点赞：SREM like:video:123 456789
• 检查是否点赞：SISMEMBER like:video:123 456789 → 返回 1 或 0
• 互斥校验（点赞后不能点踩）需业务层控制，Redis 不自动拦截

总点赞数用 SCARD like:video:123，毫秒级返回；点踩数同理。无需额外计数器，也无需担心并发写覆盖。

Bitmap 可用但必须重映射 offset

真要用 Bitmap 节省内存，唯一安全路径是把原始用户 ID 映射成紧凑、连续、可控的整数 ID（即“逻辑 ID”），再作为 offset：

• 映射方式必须是确定性单向函数，例如 user_id % 10000000 不行（冲突高），推荐用布隆过滤器 + 自增序列或预分配 ID 池
• 映射表本身要持久化（MySQL 或 Redis Hash），且保证原子性：先查映射、再 SETBIT、失败则回滚映射申请
• BITCOUNT video:123 只能统计总点赞数，无法区分“谁点了”，所以必须搭配另一个结构（如 Set 或 Hash）存用户行为快照用于审计或召回
• 上线前必须压测：模拟最高用户 ID 对应的 offset，验证 Redis 内存分配与响应延迟

别忽略的细节：点赞/踩状态同步与一致性

前端双态按钮（赞/踩）切换时，后端不能只依赖 Redis 返回结果做 UI 更新——SISMEMBER 和 SCARD 是两个命令，中间可能有其他用户操作，造成视觉错乱。

更可靠的做法是：一次请求完成状态判定 + 增删动作 + 总数读取，用 Lua 脚本封装：

eval "local liked = redis.call('sismember', KEYS[1], ARGV[1]) local disliked = redis.call('sismember', KEYS[2], ARGV[1]) if liked == 1 then redis.call('srem', KEYS[1], ARGV[1]) elseif disliked == 0 then redis.call('sadd', KEYS[1], ARGV[1]) end return {redis.call('scard', KEYS[1]), redis.call('scard', KEYS[2])}" 2 like:video:123 dislike:video:123 456789

这样点赞/点踩互斥、总数准确、网络往返仅 1 次。而 Bitmap 方案目前没有等效的原子多操作支持，必须靠客户端协调，风险更高。