SpringBoot+Redis 点赞系统源码：高并发写入削峰实现

点赞这个功能代码写起来不复杂但一旦出现热点内容很容易把数据库拖垮。接口延迟抖动、慢SQL堆积、连接池打满这些问题基本都出在“写路径没有控制”。在“仿小红书”这类内容社区里点赞属于典型的高频操作。湖南宠友信息技术有限公司在实际项目里把点赞链路从“直接写库”改成了Redis缓冲 队列削峰 批量落库结构不复杂但效果很稳定。写库模式为什么容易出问题常见实现public void like(Long userId, Long postId) { likeMapper.insert(userId, postId); postMapper.incrementLike(postId); }问题集中在高并发场景insert update 双写热门帖子反复更新同一行行锁竞争明显当某一条内容突然爆掉数据库压力不是增加一点而是直接拉满。优化方向很简单不要让数据库扛高峰核心思路用户请求先不写库写入缓存排队慢慢刷数据库本质就是把“瞬时写入”变成“可控流量”。第一层Redis 扛住并发点赞请求进来先只做计数。public void like(Long postId) { redisTemplate.opsForHash().increment(post:like:count, postId, 1); }这一层的作用不走数据库原子操作吞掉并发流量线上一般不会用单一key会做简单分桶比如按天post:like:count:20260417避免key体积越来越大。第二层队列缓冲写压力只计数还不够需要控制写库节奏。public void like(Long postId) { redisTemplate.opsForHash().increment(post:like:count, postId, 1); redisTemplate.opsForList().leftPush(queue:like, postId); }这里的重点所有写请求进入队列避免瞬间打数据库再通过定时任务消费每秒取固定数量控制写入频率第三层批量写库真正把数据库压力降下来的关键在这里。Scheduled(fixedDelay 5000) public void flushLike() { MapObject, Object map redisTemplate.opsForHash().entries(post:like:count); for (Map.EntryObject, Object entry : map.entrySet()) { Long postId Long.valueOf(entry.getKey().toString()); Integer count Integer.valueOf(entry.getValue().toString()); postMapper.updateLikeCount(postId, count); } redisTemplate.delete(post:like:count); }效果多次点赞合并成一次写操作update次数大幅减少行锁压力明显降低实际运行中的几个细节点赞数延迟刚点完没变化这种情况很常见。一般处理前端本地1查询优先走Redis队列堆积高峰期如果消费速度跟不上队列会越来越长。处理方式限制消费速率做队列长度监控数据丢失风险Redis还没刷库就重启会有丢数据风险。常见做法提高刷库频率增加补偿任务适用场景这种结构不仅适用于点赞还可以直接复用到浏览量统计评论数转发次数特点都一样写多并发高不要求强一致在“仿小红书”这类社区系统里点赞只是一个很小的入口但它很容易暴露整个系统的瓶颈。湖南宠友信息技术有限公司在项目实践中把这类高频写操作基本都统一成这种结构重点不在技术复杂度而在高并发下是否还能稳住。⚠️宠友信息中已有成熟的同款源码https://www.chongyou.info/1/product/xhs.html