17370845950

直接用数据库自增字段实现点赞计数虽强一致但高并发下性能差；UPDATE likes=likes+1存在丢失更新、行锁争用、无法去重三大问题；推荐Redis缓存+MySQL落库+用户去重的三层方案。

直接用数据库自增字段实现点赞计数，是最简单且能保证强一致性的方案；但高并发下容易成为性能瓶颈，需配合缓存与异步落库来平衡准确性和响应速度。

为什么不能只靠 UPDATE ... SET likes = likes + 1

这条 SQL 看似简洁，但在真实场景中会暴露三个关键问题：

• 并发写入时可能丢失更新（两个请求同时读到 likes=100，各自加 1 后都写回 101）
• 频繁更新单行记录会导致 InnoDB 行锁争用，QPS 上千后明显变慢
• 无法区分“同一用户重复点击”，即缺少去重逻辑

推荐的三层结构：Redis 缓存 + MySQL 落库 + 用户维度去重

核心思路是：先用 Redis 记录用户对视频的点赞状态和临时计数，再异步批量同步到 MySQL。这样既防刷、又抗压。

关键实现点：

• 用 SETNX 或 Redis::set($key, $value, ['nx', 'ex' => 3600]) 标记用户是否已点过赞（video:like:uid:123:vid:456）
• 点赞成功后，向有序集合 video:likes:456 插入用户 ID（score 可设为时间戳），用于后续查谁点了赞
• 使用 INCR 增加计数器 video:likes:count:456，这是前端展示用的实时值
• 每 5 分钟用脚本扫描 Redis 中的计数器，用 GET 读取并执行 UPDATE video SET likes = likes + ? WHERE id = ? 批量落库

MySQL 表结构必须支持幂等更新和唯一约束

如果跳过 Redis 直接操作数据库，至少要满足两点：防止重复计数、避免锁表。示例如下：

CREATE TABLE video_likes (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  video_id INT NOT NU
LL,
  user_id INT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY uk_video_user (video_id, user_id)
);
-- 原子性插入，失败则说明已点过
INSERT INTO video_likes (video_id, user_id) VALUES (456, 123)
ON DUPLICATE KEY UPDATE id = id;
-- 再单独更新计数（注意：这里不是 SELECT + UPDATE）
UPDATE video SET likes = likes + 1 WHERE id = 456 AND NOT EXISTS (
SELECT 1 FROM video_likes WHERE video_id = 456 AND user_id = 123
);

这个写法依赖 UNIQUE KEY 和 NOT EXISTS 子查询，能规避大部分并发冲突，但仍有小概率因执行顺序导致计数偏差——所以生产环境仍建议走 Redis+异步。

前端展示时别直接读 Redis 计数器

video:likes:count:456 是高频变更数据，但 Redis 没有事务，万一异步脚本崩溃，它可能比 MySQL 多出几百个赞。稳妥做法是：

• 日常展示优先读 Redis（快）
• 用户进入详情页时，额外发一次 SELECT likes FROM video WHERE id = 456（准）
• 若两者差值超过阈值（比如 > 50），就用 DB 值覆盖 Redis 并触发补偿任务

这个细节很多人忽略，结果上线后发现“点赞数一会儿多一会儿少”，其实是缓存和 DB 不一致没兜住。