直接用数据库自增字段实现点赞计数虽强一致但高并发下性能差；UPDATE likes=likes+1存在丢失更新、行锁争用、无法去重三大问题；推荐Redis缓存+MySQL落库+用户去重的三层方案。
直接用数据库自增字段实现点赞计数，是最简单且能保证强一致性的方案；但高并发下容易成为性能瓶颈，需配合缓存与异步落库来平衡准确性和响应速度。
为什么不能只靠 UPDATE ... SET likes = likes + 1
这条 SQL 看似简洁，但在真实场景中会暴露三个关键问题：
- 并发写入时可能丢失更新（两个请求同时读到
likes=100，各自加 1 后都写回101） - 频繁更新单行记录会导致 InnoDB 行锁争用，QPS 上千后明显变慢
- 无法区分“同一用户重复点击”，即缺少去重逻辑
推荐的三层结构：Redis 缓存 + MySQL 落库 + 用户维度去重
核心思路是：先用 Redis 记录用户对视频的点赞状态和临时计数，再异步批量同步到 MySQL。这样既防刷、又抗压。
关键实现点：
立即学习“PHP免费学习笔记（深入）”；
- 用
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 NULL, 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 不一致没兜住。
