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

背景

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

问题复现

解决方案:

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

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

相关推荐
Qinana39 分钟前
第一次用向量数据库!手搓《天龙八部》RAG助手,让AI真正“懂”你
前端·数据库·后端
DolphinDB17 小时前
集成 Prometheus 与 DolphinDB 规则引擎,构建敏捷监控解决方案
数据库
IvorySQL18 小时前
PostgreSQL 技术日报 (3月10日)|IIoT 性能瓶颈与内核优化新讨论
数据库·postgresql·开源
DBA小马哥21 小时前
时序数据库是什么?能源行业国产化替换的入门必看
数据库·时序数据库
爱可生开源社区1 天前
某马来西亚游戏公司如何从 SQL Server 迁移至 OceanBase?
数据库
小瓦码J码1 天前
PostgreSQL表名超长踩坑记
数据库·postgresql
yhyyht1 天前
InfluxDB入门记录(三)flux-dsl
数据库·后端
IvorySQL2 天前
PostgreSQL 技术日报 (3月9日)|EXPLAIN ANALYZE 计时优化与复制语法讨论
数据库·postgresql·开源
stark张宇2 天前
MySQL 核心内幕:从索引原理、字段选型到日志机制与外键约束,一篇打通数据库任督二脉
数据库·mysql·架构
倔强的石头_2 天前
融合数据库架构实践:关系型、JSON与全文检索的“一库多能”深度解析
数据库