消息队列+更新DB极易引发的DB并发修改bug

背景

我们在生产系统中和其他系统进行交互时一般都会通过消息队列来解耦生产者和消费者,然后通过每个使用方消费消息队列的消息的方式来完成消息的消费,并且一般来说我们消费消息后极有可能会操作DB,不过这种方式如果处理不够仔细,很容易发生DB并发更新导致的数据覆盖

问题复现

解决方案:

1.对于DB的同一条记录的操作需要有先后顺序,这就要求对于同一个mid的消息消费要串行,而不能并行,所以这就要求生产者发送消息到消息队列时需要按照mid进行partition分区,这样同一个mid只会在一个分区中,而kafka的消息消费是分区有序的,这个问题就可以解决掉了

2.对于DB的并发更新使用加乐观锁(版本号)或者悲观锁的方式来达到串行更新DB记录的效果

相关推荐
扑克中的黑桃A27 分钟前
金仓多模数据库平替MongoDB的电子证照国产化实践——从2TB数据迁移到1600+并发支撑
数据库
计算机毕业设计小帅32 分钟前
【2026计算机毕业设计】基于Django的社区婴幼儿预防接种系统
数据库·django·课程设计
友友马1 小时前
『 数据库 』MySQL复习 - 内置函数详解
数据库·mysql
互联网中的一颗神经元2 小时前
小白python入门 - 6. Python 分支结构——逻辑决策的核心机制
开发语言·数据库·python
数据库知识分享者小北2 小时前
AI Agent的未来之争:任务规划,该由人主导还是AI自主?——阿里云RDS AI助手的最佳实践
数据库·阿里云·数据库rds
凸头2 小时前
MySQL 的四种 Binlog 日志处理工具:Canal、Maxwell、Databus和 阿里云 DTS
数据库·mysql·阿里云
码界奇点3 小时前
MongoDB 排序操作详解sort方法使用指南
数据库·mongodb·性能优化
武子康3 小时前
Java-155 MongoDB Spring Boot 连接实战 | Template vs Repository(含索引与常见坑)
java·数据库·spring boot·后端·mongodb·系统架构·nosql
武子康3 小时前
Java-157 MongoDB 存储引擎 WiredTiger vs InMemory:何时用、怎么配、如何验证 mongod.conf
java·数据库·sql·mongodb·性能优化·系统架构·nosql