点赞功能看似简单，却是互联网最典型的高并发、读多写少、瞬时流量爆炸场景。 很多新手、甚至初级工程师写的点赞系统，并发量上来后会出现大量致命问题：
- 用户快速连击导致重复点赞、点赞数翻倍
- 高并发下 MySQL 行锁竞争严重，接口超时、服务雪崩
- 前端 UI 抖动、状态错乱、页面渲染塌陷
- Redis 与 MySQL 数据不一致，出现少赞、多赞、脏数据
- 接口缺少幂等设计，请求重试引发数据异常
本文从头到尾完整拆解企业生产级「高并发点赞系统」落地方案：前端防重防抖 + 乐观 UI 更新 + 后端 Redis 抗峰值 + MQ 异步消峰 + 定时校正保证数据一致性，同时附上 Codex 专属提示词，一键生成整套可上线工程代码。
一、点赞业务核心痛点（为什么不能直连 MySQL）
1.1 业务特征
- 超高瞬时并发：短视频、活动页面容易出现万级 QPS 涌入
- 读多写少：查询点赞状态频次极高，更新操作相对较少
- 用户高频重复点击，无效请求占比很高
- 业务允许最终一致性，不需要强实时一致性
1.2 原生直写 MySQL 方案致命缺陷
不少初学者直接使用 SQL：update article set like_count = like_count + 1 where id = ? 并发场景下缺陷非常明显： 大量并发请求触发行锁竞争，数据库 CPU 持续打满，请求堆积、接口超时、数据库连接池耗尽，完全无法承载公网流量。
结论：高并发点赞场景，绝对不能直接操作数据库。
二、前端完整解决方案（拦截 80% 无效流量）
高并发优化第一原则：能在前端拦截的请求，绝不传递到后端。 前端主要解决三大问题：重复点击、UI 卡顿抖动、请求失败状态错乱。
2.1 按钮防抖 + 请求锁（拦截高频连击）
核心逻辑：同一时间段只允许发起一次点赞请求，屏蔽用户疯狂连续点击。
bash
// uni-app / Web通用代码
let isLoading = false
async function handleLike(targetId) {
if (isLoading) return
isLoading = true
// 备份原始状态，用于接口失败回滚
const oldLikeStatus = isLike
const oldCount = likeCount
// 乐观UI更新（优先渲染界面，提升用户体验）
isLike = !isLike
likeCount += isLike ? 1 : -1
try {
await request.post("/api/like", { targetId })
} catch (err) {
// 请求异常，强制回滚UI状态，杜绝界面错乱、塌陷
isLike = oldLikeStatus
likeCount = oldCount
} finally {
isLoading = false
}
}2.2 乐观更新 + 失败回滚
普通写法：等待后端返回结果再更新页面，网络波动时体验卡顿。 企业级标准写法：前端先行渲染 UI，一旦请求失败立刻恢复原始状态，兼顾流畅度与数据准确性。
2.3 前端幂等防重
每次点赞请求携带唯一requestId，后端根据 id 识别重复请求，避免网络重试造成多次点赞。
bash
import { uuid } from '@/utils'
async function handleLike(targetId) {
const reqId = uuid()
await request.post("/api/like", { targetId, reqId })
}前端策略总结
- 防抖锁：拦截短时间连续点击
- 幂等 ID：规避网络重试产生重复请求
- 乐观 UI：优化交互，消除等待卡顿
- 失败回滚：防止点赞状态错乱、页面塌陷
三、后端四层架构方案（从入门到生产级高并发）
3.1 初级方案：MySQL 联合唯一索引（仅适合内部系统）
设计点赞记录表，user_id + target_id建立联合唯一索引，依靠索引约束防止重复点赞。 缺点：并发量上涨后行锁冲突严重，极易出现接口超时，面向公网业务禁止使用。
3.2 中级方案：Redis 缓存点赞（中小流量标准方案）
核心思路：Redis 承接热点并发，MySQL 作为数据保底。 采用两类 Redis 数据结构：
- Set 集合：
like:set:{targetId}，存储已点赞用户 ID，天然实现去重 - String 计数器：
like:count:{targetId}，维护点赞总数
执行逻辑：
- 判断用户是否存在 Set 集合内
- 未点赞：
sadd添加用户 +incr计数器自增 - 已点赞：
srem移除用户 +decr计数器递减
优势：毫秒级响应，轻松支撑十万级并发，不存在行锁竞争。
3.3 高级生产方案：Redis + MQ 异步消峰（短视频、社区主流架构）
超高流量场景首选架构：
- 用户点赞请求优先操作 Redis，快速响应前端
- 将点赞行为投递消息队列
- 消费者批量异步写入 MySQL
- 定时任务定期校正 Redis 与数据库数据差值
这套架构解决热点流量冲击数据库、长期运行数据不一致、请求尖峰问题。
3.4 超大规模分布式方案：分布式锁 + 数据分片 + 全局幂等
大厂海量流量落地架构：
- 点赞数据按照 targetId 分片存储，规避热点 key 问题
- Redisson 分布式锁处理极端并发竞争场景
- 全局幂等表过滤重复请求
- 定时校对任务长期兜底，修复数据漂移
四、高并发点赞核心避坑（90% 工程师容易踩雷）
❌ 禁止高并发场景直接执行 update 更新 count 字段
❌ 业务逻辑不能依赖前端状态判断，后端必须独立校验
❌ 不做幂等控制，网络重试一定会产生脏数据
❌ 只使用缓存，缺少定时校对，长期运行数据必然不一致
✅ 设计原则：用户点赞状态保证强一致，点赞计数允许最终一致
五、AI 赋能开发：Codex 专属精准提示词（直接生成上线工程）
很多人使用 AI 开发业务代码效果差，根源是提示词约束不足，AI 只能生成 Demo 代码。 下面提供适配 Codex 搭载最新 GPT 模型的生产级提示词，直接复制即可生成完整可部署代码。
5.1 完整版｜Codex 生成整套前后端高并发点赞系统
bash
你是资深架构师，基于高并发短视频点赞场景，开发一套可直接上线的生产级代码。
技术栈：前端uni-app，后端SpringBoot + Redis + MQ + MySQL。
需求约束：
1. 前端实现：按钮防抖、连击拦截、幂等请求ID、乐观UI更新、请求失败状态回滚，彻底解决点赞抖动塌陷。
2. 后端采用 Redis 抗高并发，Set结构存储点赞用户去重，String做计数器。
3. 所有点赞操作先走Redis，异步MQ批量落地MySQL，提升吞吐、削峰填谷。
4. 接口全局幂等，过滤重复请求，防止重试脏数据。
5. 编写定时校正任务，修复Redis与MySQL数据不一致问题。
6. 处理Redis缓存击穿、失效、宕机兜底场景。
7. 输出完整：前端页面、组件、请求封装、后端Controller、Service、Redis工具类、MQ消费者、SQL表结构。
8. 代码工程化、带详细注释、可直接部署。5.2 后端精简版｜纯 Java 高并发核心架构
bash
使用 SpringBoot + Redis + Redisson 实现生产级高并发点赞功能。
1. 使用 Set 实现用户唯一点赞去重
2. incr/decr 实现高性能计数
3. 接口幂等设计
4. 定时任务校对数据一致性
5. 处理并发临界问题、缓存失效问题
输出可直接运行的完整业务代码。5.3 前端专项｜Codex 生成 UniApp 通用点赞组件
bash
基于uni-app 开发通用高并发点赞组件，适配微信小程序。
实现：防抖防连击、幂等请求、乐观UI更新、失败自动回滚、无塌陷无抖动。
代码解耦、可全局复用、带完整注释。六、深度思考：到底是模型强，还是 Agent 框架强？
结合高并发点赞这个复杂业务场景，理清一个关键问题： 复杂工程业务开发，单纯基础大模型能力存在上限，Codex 的 Agent 框架才是提升生产力的核心。 原因：
- 普通对话模式下大模型大多只能写出基础 CRUD，缺少并发、幂等、削峰、数据兜底等工程思维；
- Codex Agent 具备上下文感知、项目工程理解能力，可以自动补充异常处理、边界条件、容错机制；
- 同样一套大模型底座，普通对话只能产出 Demo，依托 Agent 框架能够生成满足线上标准的业务代码。
结论：高端业务开发，Agent 框架决定开发上限，大模型只是底层基础底座。
七、全文总结（面试 + 实战双丰收）
- 点赞属于典型高并发读多写少场景，禁止直接写入 MySQL；
- 前端依靠防抖、幂等、乐观 UI 拦截大部分无效流量；
- 后端标准架构：Redis 承载流量峰值 + MQ 异步落库 + 定时任务数据校正；
- 高并发系统通用思路：请求拦截、流量削峰、接口幂等、最终一致性兜底；
- AI 高效开发方式：精准架构约束提示词 + Codex Agent 工程能力，直接落地生产级代码。