新闻详情

新闻详情

首页 / 资讯中心 / 详情

Redis 实现播放量原子计数 + 定时任务同步 MySQL

发布时间:2026/11/12 15:44:22来源:尧图网络
Redis 实现播放量原子计数 + 定时任务同步 MySQL
一、业务场景做音乐网站项目每一次用户点击歌曲播放就需要该歌曲播放数加一。 假设并发量上来如果每一次播放请求直接 update 修改 MySQL。大量访问会频繁触发数据库写操作数据库压力会很高。于是想到使用 Redis 做中间缓存。播放先写到 Redis隔一段时间批量同步回 MySQL减少直接操作数据库的次数。二、实现思路1.用户点击播放后端接收请求2. 使用 Redis INCR原子命令对对应歌曲 id 的播放计数自增 1INCR 是原子操作不用担心并发冲突3. 开启 SpringBoot 定时任务每隔一段时间读取 Redis 里面所有歌曲播放增量4. 将增量批量更新 MySQL同步完成之后清空 Redis 里面已经落库的增量数据。注意隐患如果服务器突然宕机。Redis 还没来得及同步的数据会有丢失风险。 解决思路可以开启 Redis 持久化 RDB/AOF 降低丢数概率或者缩短定时任务间隔时间。三、核心关键代码片段1.播放量自增接口使用 RedisTemplate//歌曲id播放一次计数1 // redisKey格式play:count:{songId} String key play:count: songId; redisTemplate.opsForValue().increment(key);2.定时任务Scheduled每 10 分钟执行一次同步逻辑Component EnableScheduling public class PlayCountSyncTask { Resource private RedisTemplateString,Object redisTemplate; Resource private SongMapper songMapper; Scheduled(fixedDelay 10 * 60 * 1000) public void syncPlayCountToMysql(){ //1.查询redis中所有play:count开头的key //2.循环取出歌曲id和增量 //3.批量update mysql播放数量 //4.同步成功删除redis里面这一批key } }定时任务不要写太短间隔频繁同步就失去 Redis 缓冲意义太长宕机丢数风险变大。四、Redis‑MySQL 缓存不一致问题我们这套方案Redis 暂存增量定时任务批量同步。这是异步更新天然就容易出现缓存和数据库不一致。4.1当前项目会出现不一致的两种场景1.还没到定时同步时间MySQL 直接修改歌曲播放量后台手动改数据库数值。Redis 里面还保留旧增量同步之后就会叠加造成播放数量出错。2.定时任务执行一半程序宕机定时任务遍历一批 key一部分同步成功入库还没来得及删除 Redis 里对应的 key服务宕机。服务重启后定时任务再次执行会把这部分增量再次同步一遍造成播放量重复累加数据变多。注意普通用户点击播放只会往 Redis 做 increment不会直接写 MySQL。普通播放不会产生不一致人为修改 MySQL 才是不一致主要来源。4.2几种解决思路方案 1业务约束业务上约定所有播放量修改只能走 Redis。后台不允许直接手动修改 MySQL 播放量字段。优点实现零代码改动。适合课程演示。缺点现实生产环境很难强制所有人不碰数据库。方案 2更新 MySQL 同时主动清理对应 Redis Key如果后台需要修改歌曲播放量管理员编辑修改 MySQL 播放数字立刻删除该歌曲对应的play:count:{songId}这个 Redis key。Redis 这条增量作废。下一次定时任务不会再把旧增量刷进去。优点简单好实现。缺点如果删除 Redis 网络超时失败不一致仍然会发生。方案 3记录增量日志不要直接用 Redis 存最终增量数字。Redis 只记录变更。或者数据库新建一张增量日志表。每次播放除了 Redis 自增插入一条增量日志。定时任务读取日志表同步同步完标记已处理。就算 Redis 宕机数据库日志还留存记录不会丢数据。优点解决宕机丢数减少不一致风险。缺点每一次播放都插入数据库又增加数据库 IO违背最开始减轻数据库压力初衷。五、强一致 vs 最终一致如果业务强行要求强一致性该怎么办本项目 Redis 暂存增量定时同步只能保障最终一致性。若业务场景余额等要求强一致优先方案放弃 Redis 做计数缓冲读写直接访问 MySQL。牺牲一部分吞吐量换取数据准确。分布式事务 Seata 理论可实现事务回滚但是 Redis 不支持 XA 协议工程落地麻烦很少用于解决 Redis‑MySQL 一致性。六、思考总结“不存在优雅、高性能的方案让 Redis 与 MySQL 保证强一致性。工业上的思路是业务选型规避这个难题。如果要求强一致就不要把写逻辑交给 Redis如果想用 Redis 扛住高并发写压力就要接受最终一致性。”如果非要强一致又想要高性能可以换专门组件例如 Redis 本身的 Redisson 的 RLock 只是锁锁只能减少并发冲突锁解决不了网络故障导致双写不一致。锁≠强一致。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

【外设】之大彩串口显示屏 2026/11/11 13:52:51

【外设】之大彩串口显示屏

大彩串口屏初步使用 1 .官网下载 STM32 屏幕 GUI 设计资料 http://www.gz-dc.com/category/typeid/4112 找到 STM32 Keil 工程,移植相关代码因项目而异进行移植,由于项目简单,本人只对用到的指令接口进行修改。 比如:注意事项&…

阅读更多 →
无法下载Windows系统iso文件 2026/11/10 19:42:40

无法下载Windows系统iso文件

当我遇到这个问题的时候,我打开了一个网站: 登录 然后我打算下载的时候: 突然那个官方的连接就可以下载了:

阅读更多 →
【清华代码熊】DeepSeek V4.1 Flash 后训练详解 2026/11/12 9:50:02

【清华代码熊】DeepSeek V4.1 Flash 后训练详解

📌 上期解析了 DeepSeek V4.1 Flash 模型架构改进,本期解析 DeepSeek V4.1 Flash 预训练/后训练技术: 🌟 预训练:45T 文本 多模态混合语料、直接训练 sparse attention(取消 DeepSeek V4 的 dense 冷启动&…

阅读更多 →
Shuffle-R1: Efficient RL framework for Multimodal Large Language Models via Data-centric Dynamic ... 2026/11/12 9:25:38

Shuffle-R1: Efficient RL framework for Multimodal Large Language Models via Data-centric Dynamic ...

文章主要内容和创新点 主要内容 本文聚焦于多模态大语言模型(MLLM)强化学习(RL)训练中的效率问题,提出了一个名为Shuffle-R1的框架。研究发现,当前RL训练存在两个关键缺陷: 优势值坍缩(Advantage Collapsing):批次中大多数优势值集中在零附近,导致有效梯度信号被淹…

阅读更多 →
PRvL: Quantifying the Capabilities and Risks of Large Language Models for PII Redaction 2026/11/11 15:37:39

PRvL: Quantifying the Capabilities and Risks of Large Language Models for PII Redaction

一、文章主要内容总结 本文聚焦于利用大型语言模型(LLMs)实现个人身份信息(PII)脱敏的研究,旨在解决传统脱敏方法(如基于规则的系统、领域特定命名实体识别(NER)模型)泛化能力差、跨格式/跨语境适应性弱的问题。 研究通过全面评估多种LLM架构(包括密集型LLM(D-LLM…

阅读更多 →
LLaVA-RE: Binary Image-Text Relevancy Evaluation with Multimodal Large Language Model 2026/11/10 17:14:10

LLaVA-RE: Binary Image-Text Relevancy Evaluation with Multimodal Large Language Model

文章主要内容和创新点 主要内容 本文聚焦于二进制图像-文本相关性评估任务(判断图像与文本“相关”或“不相关”),针对该任务中文本格式多样、相关性定义随场景变化等挑战,提出了基于多模态大语言模型(MLLM)的解决方案LLaVA-RE。 模型设计:LLaVA-RE基于LLaVA 1.5架构,…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉