点赞功能看似简单却是互联网最典型的高并发、读多写少、瞬时流量爆炸场景。 很多新手、甚至初级工程师写的点赞系统并发量上来后会出现大量致命问题用户快速连击导致重复点赞、点赞数翻倍高并发下 MySQL 行锁竞争严重接口超时、服务雪崩前端 UI 抖动、状态错乱、页面渲染塌陷Redis 与 MySQL 数据不一致出现少赞、多赞、脏数据接口缺少幂等设计请求重试引发数据异常本文从头到尾完整拆解企业生产级「高并发点赞系统」落地方案前端防重防抖 乐观 UI 更新 后端 Redis 抗峰值 MQ 异步消峰 定时校正保证数据一致性同时附上 Codex 专属提示词一键生成整套可上线工程代码。一、点赞业务核心痛点为什么不能直连 MySQL1.1 业务特征超高瞬时并发短视频、活动页面容易出现万级 QPS 涌入读多写少查询点赞状态频次极高更新操作相对较少用户高频重复点击无效请求占比很高业务允许最终一致性不需要强实时一致性1.2 原生直写 MySQL 方案致命缺陷不少初学者直接使用 SQLupdate article set like_count like_count 1 where id ?并发场景下缺陷非常明显 大量并发请求触发行锁竞争数据库 CPU 持续打满请求堆积、接口超时、数据库连接池耗尽完全无法承载公网流量。结论高并发点赞场景绝对不能直接操作数据库。二、前端完整解决方案拦截 80% 无效流量高并发优化第一原则能在前端拦截的请求绝不传递到后端。 前端主要解决三大问题重复点击、UI 卡顿抖动、请求失败状态错乱。2.1 按钮防抖 请求锁拦截高频连击核心逻辑同一时间段只允许发起一次点赞请求屏蔽用户疯狂连续点击。// 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 识别重复请求避免网络重试造成多次点赞。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 生成整套前后端高并发点赞系统你是资深架构师基于高并发短视频点赞场景开发一套可直接上线的生产级代码。 技术栈前端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 高并发核心架构使用 SpringBoot Redis Redisson 实现生产级高并发点赞功能。 1. 使用 Set 实现用户唯一点赞去重 2. incr/decr 实现高性能计数 3. 接口幂等设计 4. 定时任务校对数据一致性 5. 处理并发临界问题、缓存失效问题 输出可直接运行的完整业务代码。5.3 前端专项Codex 生成 UniApp 通用点赞组件基于uni-app 开发通用高并发点赞组件适配微信小程序。 实现防抖防连击、幂等请求、乐观UI更新、失败自动回滚、无塌陷无抖动。 代码解耦、可全局复用、带完整注释。六、深度思考到底是模型强还是 Agent 框架强结合高并发点赞这个复杂业务场景理清一个关键问题 复杂工程业务开发单纯基础大模型能力存在上限Codex 的 Agent 框架才是提升生产力的核心。 原因普通对话模式下大模型大多只能写出基础 CRUD缺少并发、幂等、削峰、数据兜底等工程思维Codex Agent 具备上下文感知、项目工程理解能力可以自动补充异常处理、边界条件、容错机制同样一套大模型底座普通对话只能产出 Demo依托 Agent 框架能够生成满足线上标准的业务代码。结论高端业务开发Agent 框架决定开发上限大模型只是底层基础底座。七、全文总结面试 实战双丰收点赞属于典型高并发读多写少场景禁止直接写入 MySQL前端依靠防抖、幂等、乐观 UI 拦截大部分无效流量后端标准架构Redis 承载流量峰值 MQ 异步落库 定时任务数据校正高并发系统通用思路请求拦截、流量削峰、接口幂等、最终一致性兜底AI 高效开发方式精准架构约束提示词 Codex Agent 工程能力直接落地生产级代码。
点赞功能看似简单却是互联网最典型的高并发、读多写少、瞬时流量爆炸场景。 很多新手、甚至初级工程师写的点赞系统并发量上来后会出现大量致命问题用户快速连击导致重复点赞、点赞数翻倍高并发下 MySQL 行锁竞争严重接口超时、服务雪崩前端 UI 抖动、状态错乱、页面渲染塌陷Redis 与 MySQL 数据不一致出现少赞、多赞、脏数据接口缺少幂等设计请求重试引发数据异常本文从头到尾完整拆解企业生产级「高并发点赞系统」落地方案前端防重防抖 乐观 UI 更新 后端 Redis 抗峰值 MQ 异步消峰 定时校正保证数据一致性同时附上 Codex 专属提示词一键生成整套可上线工程代码。一、点赞业务核心痛点为什么不能直连 MySQL1.1 业务特征超高瞬时并发短视频、活动页面容易出现万级 QPS 涌入读多写少查询点赞状态频次极高更新操作相对较少用户高频重复点击无效请求占比很高业务允许最终一致性不需要强实时一致性1.2 原生直写 MySQL 方案致命缺陷不少初学者直接使用 SQLupdate article set like_count like_count 1 where id ?并发场景下缺陷非常明显 大量并发请求触发行锁竞争数据库 CPU 持续打满请求堆积、接口超时、数据库连接池耗尽完全无法承载公网流量。结论高并发点赞场景绝对不能直接操作数据库。二、前端完整解决方案拦截 80% 无效流量高并发优化第一原则能在前端拦截的请求绝不传递到后端。 前端主要解决三大问题重复点击、UI 卡顿抖动、请求失败状态错乱。2.1 按钮防抖 请求锁拦截高频连击核心逻辑同一时间段只允许发起一次点赞请求屏蔽用户疯狂连续点击。// 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 识别重复请求避免网络重试造成多次点赞。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 生成整套前后端高并发点赞系统你是资深架构师基于高并发短视频点赞场景开发一套可直接上线的生产级代码。 技术栈前端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 高并发核心架构使用 SpringBoot Redis Redisson 实现生产级高并发点赞功能。 1. 使用 Set 实现用户唯一点赞去重 2. incr/decr 实现高性能计数 3. 接口幂等设计 4. 定时任务校对数据一致性 5. 处理并发临界问题、缓存失效问题 输出可直接运行的完整业务代码。5.3 前端专项Codex 生成 UniApp 通用点赞组件基于uni-app 开发通用高并发点赞组件适配微信小程序。 实现防抖防连击、幂等请求、乐观UI更新、失败自动回滚、无塌陷无抖动。 代码解耦、可全局复用、带完整注释。六、深度思考到底是模型强还是 Agent 框架强结合高并发点赞这个复杂业务场景理清一个关键问题 复杂工程业务开发单纯基础大模型能力存在上限Codex 的 Agent 框架才是提升生产力的核心。 原因普通对话模式下大模型大多只能写出基础 CRUD缺少并发、幂等、削峰、数据兜底等工程思维Codex Agent 具备上下文感知、项目工程理解能力可以自动补充异常处理、边界条件、容错机制同样一套大模型底座普通对话只能产出 Demo依托 Agent 框架能够生成满足线上标准的业务代码。结论高端业务开发Agent 框架决定开发上限大模型只是底层基础底座。七、全文总结面试 实战双丰收点赞属于典型高并发读多写少场景禁止直接写入 MySQL前端依靠防抖、幂等、乐观 UI 拦截大部分无效流量后端标准架构Redis 承载流量峰值 MQ 异步落库 定时任务数据校正高并发系统通用思路请求拦截、流量削峰、接口幂等、最终一致性兜底AI 高效开发方式精准架构约束提示词 Codex Agent 工程能力直接落地生产级代码。
