高并发,业务量大的业务场景下,数据库减库存的解决方案

SpringBoot实战:高并发场景下的高校食堂点餐系统设计与实现 在软件开发领域,高并发与数据一致性是构建稳定系统的核心挑战。其原理在于通过合理的技术架构,应对瞬时大量请求,确保业务逻辑的正确执行。对于电商、社交、在线服务等应用场景,这直接关系到用户体验和系统可用性。SpringBoot作为主流的Java开发框架,以其快速构建和简化配置的优势,常被用于实现此类系统。结合Redis实现缓存与分布式锁,以及利用消息队列进行系统解耦,是应对高并发、保证最终一致性的关键技术实践。本文以高校食堂点餐这一典型高并发业务为背景,深入探讨如何运用SpringBoot整合MySQL、Red 阅读详情

一,用户下单购买商品的情况下,如果有多个人同时下单,减除库存的情况下,如果遇到了减去库存的并发问题,这个时候应该怎么处理呢?

传统的业务流程场景下,处理流程是这样的:
1,库存查询,通过dao查询商品库存,返回库存数量
select stock from goods where gid=#{gid}
2,逻辑判断库存是否充足,充足进行库存减扣
update stock set stock=stock-#{count} where gid=#{gid}


但是在减去库存的时候往往会出现一些意想不到的错误,出错后程序设计可能会有“重试”机制,但是在重试时,可能会得到错误的数据,导致重复减扣或者库存为负数。

重试导致错误的根本原因,是因为“扣减”操作是一个非幂等的操作,不能够重复执行,改成设置操作则不会有这个问题,如下:假如用户购买三件商品,通过数据库查询,返回商品余量为5,然后通过逻辑计算减去三件商品余2,然后在设置数量2到数据库持久化
1,库存查询,通过dao查询商品库存,假如返回库存数量为5
select stock from goods where gid=#{gid}
2,判断库存是否充足,充足进行逻辑库存减扣,设置数据库(逻辑计算5-3=2,new_stock=2)
update goods set stock=#{new_stock} where gid=#{gid}

这样虽然避免了程序出错,“重试”机制的减扣没有导致数据出现错误,但是如果用户发生了并发的购买动作(秒杀类业务特别容易出现),流程如下:
用户A和用户B并发购买商品,此时同时查询数据库库存数量为5
用户A购买了3个库存,于是库存要设置为2
用户B购买了2个库存,于是库存要设置为3

此时场景,应该是五个商品刚好售卖完,储存应该为0,但是这两个设置库存的接口并发执行,库存会先变成2,再变成3,导致数据不一致(实际卖出了5件商品,但库存只扣减了2,最后一次设置库存会覆盖和掩盖前一次并发操作)
其根本原因是,设置操作发生的时候,没有检查实际库存与查询出来的库存有没有变化,理论上:

库存为5时,用户A的库存设置才能成功
库存为5时,用户B的库存设置才能成功

实际执行的时候:
库存为5,用户A的set stock=2确实应该成功
库存变为2了,用户B的set stock=3应该失败掉

所以,在数据量较大的情况下,减库存应该是以下这种方案:
update goods set stock=#{new_stock} where gid=#{gid}
修改为:
update goods set stock=#{new_stock} where gid=#{gid} and stock=#{old_stock}
这样修改后,用户A设置库存为2了,用户B再去设置库存,通过条件stock=#{old_stock}判断条件已经不满足了更新失败,从而保证了数据的一致性。

总结:
在业务复杂,数据量大,并发量大的情况下,库存扣减容易引发数据的不一致,常见的优化方案有两个:

  • 调用“设置库存”接口,能够保证数据的幂等性
  • 在实现“设置库存”接口时,需要加上原有库存的比较,才允许设置成功,能解决高并发下库存扣减的一致性问题
民航订票系统设计实战:从Spring Boot架构到高并发库存扣减方案 在构建企业级业务系统时,数据库设计与高并发处理是两大核心挑战。关系型数据库通过ACID特性保障了数据一致性,而面对高并发场景,乐观锁、悲观锁等并发控制机制成为关键技术。这些技术对于确保库存扣减、订单创建等核心业务的正确性至关重要,广泛应用于电商、票务等交易系统。本文以民航订票系统为具体案例,深入剖析了如何运用Spring Boot框架与MySQL数据库,结合乐观锁方案解决库存超售问题,并详细解读了航班查询、订单事务管理等关键业务逻辑的实现与优化策略。 阅读详情

相关推荐

VS Code + EIDE + Clangd 构建 Keil/MDK 嵌入式开发新范式

嵌入式C/C++开发长期受限于传统IDE的语法理解弱、导航卡顿、跨工程复用难等问题。Clangd作为基于AST的现代语言服务器,结合EIDE对Keil uVision和ARM MDK工程文件(.uvprojx)的深度解析能力,可将编译配置、芯片型号、内存模型、扩展关键字等语义精准翻译为标准compile_commands.json,从而实现智能跳转、宏展开识别、结构体实时展开等高阶编辑体验。该方案不替换Keil/MDK编译与烧录流程,仅升级代码理解层,天然兼容STC8051、STM32 Cortex-M、G

weixin_34321753的博客 352

高并发场景的库存扣减方案

支持高并发场景高效库存扣减方案

qq_17509371的博客 2311

在abaqus中利用point-based 来快捷定义螺栓连接

abaqus中可以通过point-based方式定义连接点的位置,并对连接方式进行定义,可以进行螺栓连接的模拟。 可以通过逐点输入坐标或导入外部的坐标位置 也可以通过阵列的方式定义点 定义完点后就利用create fasteners,选择point-based,选取刚才创建好的点阵列,然后定义连接的属性,如下图 定义connector section时,类型选择translator,相当于只有1方向可以动,定义弹性模量以及破坏准则。 案例操作 假如有两个板,通过...

fiber_tape的博客 7337

高并发库存扣减超卖问题解决,多种sql适合场景分析

方案一: id是主键索引的前提下,如果每次只是减少1个库存,则可以采用上面的方式,只做数据安全校验,可以有效减库存,性能更高,避免大量无用sql,只要有库存就也可以操作成功. 场景:高并发场景下的取号器,优惠券发放扣减库存等 update product set stock=stock-1 where id = 1 and stock>0 方案二: 使用业务自身的条件做为乐观锁,但是存在ABA问题,对比方案三的好处是不用增加version版本字段。如果只是扣减库存且不在意ABA问题时,则可以采用上面

不爱吃鱼的猫丶的博客 1862

【STM32Cube HAL】输入捕获(六)——脉宽测量

1

HAHAHA 4907

基于AXI PCIE IP的FPGA PCIE卡示意图

如果在上图中的AXI互联IP上再连接一个带AXI Slave接口的BRAM控制器,这个BRAM控制器连接一个BRAM,Host PC在系统主存中分配了一些不连续的内存,Host PC可以将这些内存段的起始地址(当然要先转为PCIE总线地址)写到AXI总线上的BRAM中,这样AXI CDMA读取BRAM,将读取到的PCIE总线基地址写到AXIPCIE寄存器块中的AXIBAR2PCIEBAR_n寄存器中,这样就实现了SG DMA。通过动态改变AXIBAR2PCIEBAR_n寄存器的值,可以实现多通道DMA。

csdn_gddf102384398的博客 1623

高并发下的库存扣减技术

在明星直播、大促、秒杀等高并发场景下,数据库的性能会变得非常差。

开源项目 rich-agent、biga作者。 1806

评价模型——层次分析法(AHP)与熵权法(EWM)

层次分析法是定性与定量结合的多准则决策、评价方法。将决策的有关元素分解成目标层、准则层和方案层,并通过人们的判断对决策方案的优劣进行排序,在此基础上进行定性和定量分析。它把人的思维过程层次化、数量化,并用数学为分析、决策、评价、预报和控制提供定量的依据。

好好学习 天天向上 2万+

同一热卖商品的高并发写难题 - Lua脚本扣减库存方案

org.springframework.data.redis.core.script.DefaultRedisScript#getSha1获取Lua脚本的校验码,是对Lua脚本的预加载,首次执行生成SHA的校验码,第二次执行无需生成校验码。通常来说,秒杀场景的爆款商品库存数量相对较少,当发生库存扣减操作时,实际上落到数据库中的写流量很小,只要系统上游能够配合交易系统做好限流保护,数据库基本上不会有太大的负载压力,但大库存的限时抢购场景就恰恰相反了。若采用分布式锁,该方案太重,并发量上不去。

爱我所爱0505 1739

万字长文,小白新手怎么开始做YOLO实验,从零开始教!整体思路在这里,科研指南针!

万字长文,小白新手怎么开始做YOLO实验,从零开始教!整体思路在这里,科研指南针!

Coding... 1万+

【nnUNetv2进阶】三、nnUNetv2 自定义网络-发paper必会

对于很多朋友来说,找到nnunet的网络结构位置的代码可能比较困难,因为nnunet的网络结构从else:代码中没有网络结构的类名,那么使用的网络是哪个呢?打开预处理后的数据集中的nnUNetPlans.json文件,如下图,configurations里面有2d、3d_fullres等,这些表示nnunet的模型,下面的network_class_name指的就是训练使用的模型结构,一般都是PlainConvUNet。

AI爱好者的博客,分享计算机领域相关知识 8755

扣减库存(高并发更新数据库都可使用)

通过以上处理,基本可以保证下单扣减库存的准确性,但是对于“秒杀”,依然存在风险,例如两个用户同时抢购,都拿到了库存数量为10的商品,其中一个用户购买了5件商品,随后更新库存数量为5件;因为,“扣减”操作不是幂等的,如果接口设计的不够完美,没有考虑幂等性,那么在由于网络原因或者其他原因造成重试之后,会出现重复“扣减”,导致“超卖”,甚至库存为负数的情况。如果只是简单的一个扣减库存的操作,可以先将库存数量直接放到缓存中,然后利用分布式缓存,例如大名鼎鼎的Redis,去应对这种高并发情况下的系统挑战。

weixin_51977686的博客 981

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

2023春招面试专题:高并发解决方案

高并发意味着大流量,需要运用技术手段抵抗流量的冲击,这些手段好比操作流量,能让流量更平稳地被系统所处理,带给用户更好的体验。 我们常见的高并发场景有:淘宝的双11、春运时的抢票、微博大V的热点新闻等。除了这些典型事情,每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等,都可以归为高并发。

BS009的博客 396

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

老版QQ原生表情gif动态

这是老版的QQ表情,不过全是动态的的,Windows照片查看器是不会动的,可以右击用浏览器打开查看,再说一遍是老版的,只是分享给宁愿用老版也要动态的人。

高并发下单库存扣减异常?飞算 JavaAI 自动化生成分布式事务解决方案

而传统依靠数据库锁机制保障数据一致性的方法,在高并发下会严重阻塞请求,延长响应时间,降低用户体验,即便企业通过增加硬件资源、优化代码等手段缓解,也难以根治这些库存扣减异常难题,严重影响企业系统稳定性、用户体验,甚至带来经济损失与声誉危机。通过飞算 JavaAI 的深度应用,企业不仅解决了分布式事务的技术难题,更构建起智能化的事务治理体系。这种 AI 驱动的开发模式,使开发效率提升 3 倍以上,系统可靠性达到 90%,为电商业务的高速发展提供了坚实的技术底座。三、AI 驱动的分布式事务实施路径。

CalEx_Tech的博客 625

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

业务量增长10倍、100倍时系统该如何设计?

围绕支撑高并发的业务场景怎么设计系统才合理? 面对超高的并发,首先硬件层面机器要能扛得住,其次架构设计做好微服务的拆分,代码层面各种缓存、削峰、解耦等等问题要处理好,数据库层面做好读写分离、分库分表,稳定性方面要保证有监控,熔断限流降级该有的必须要有,发生问题能及时发现处理。这样从整个系统设计方面就会有一个初步的概念。 微服务架构演化 在互联网早期的时候,单体架构就足以支撑起日常的业务需求,大家的所有业务服务都在一个项目里,部署在一台物理机器上。所有的业务包括你的交易系统、会员信息、库存、商品等等都夹杂在一

ZERO 2140

Redis+Lua脚本实现高并发库存扣减,秒杀系统防超卖实战解析

在高并发场景下,库存扣减的正确性直接关系到业务成败,超卖问题成为电商秒杀系统的核心挑战。原子性操作是解决并发竞态的关键,而Redis单线程模型配合Lua脚本,能够将“判断库存+扣减库存”合并为不可分割的整体,天然规避了分布式锁的复杂性。该方案不仅性能优越,还能灵活扩展限购、批量扣减等复杂业务逻辑,是构建高吞吐、强一致库存服务的理想选择。从技术原理到工程落地,剖析如何借助Redis+Lua实现原子性扣减,结合Spring Boot完整代码与压测验证,为秒杀、抢购等典型场景提供了一套简单可靠的解决方案,帮助开发

weixin_33997389的博客 302

小卖家ERP选型指南:从业务流程梳理到库存高并发避坑

进销存与ERP系统的本质,是将企业线下业务流程数字化、标准化,其核心价值在于通过系统化的订单、库存与财务协同,提升管理效率并支撑规模扩张。在电商多平台运营与直播秒杀等场景下,库存数据的高并发一致性成为关键技术挑战,系统需要具备实时扣减与防超卖能力,同时权限审计与多仓支持也是团队协作与未来扩展的基础。从通用进销存到垂直电商ERP,不同阶段与业务模式的小卖家,应基于自身流程痛点与峰值压力进行匹配选型。本文从订单库存、财务对账、流程适配、部署方式等维度,系统梳理小卖家选择与实施ERP的完整路径,并结合库存高并发、

weixin_33827590的博客 170

在线票务系统高并发设计与实现:从数据库到Redis的库存防超卖实战

在分布式系统设计中,高并发场景下的数据一致性是核心挑战,尤其在电商、票务等涉及库存管理的领域。其基本原理在于通过锁机制、原子操作和事务控制,确保共享资源在并发访问下的正确性。这一技术的核心价值是保障系统在高流量冲击下,既能维持高性能,又能避免超卖、数据错乱等严重业务问题。典型的应用场景包括在线票务预订、电商秒杀等瞬时高并发请求。本文以在线票务预订系统为例,深入探讨如何结合关系型数据库与Redis缓存,设计并实现一套可靠的“查询-锁定-支付”流程,其中重点运用了Redis原子操作进行库存预扣减,并结合数据库事

weixin_34417183的博客 416

面试官:你 Redis怎么样?—— 别光说 Get/Set,这套高并发三板斧拿去!

我们也踩过坑,比如早期有个开发存了个 5MB 的大 List,导致 Redis 偶尔卡顿(阻塞单线程)。后来我上了监控,把这个BigKey拆分了,顺便把连接池参数也优化了一下,解决了性能抖动。

fuladulu的博客 571

⚡️ PowerJob深度解析:Java生态下高并发分布式调度的终极选择

经过深入分析和实战验证,PowerJob作为新一代分布式任务调度框架,在Java生态中展现出了显著的技术优势和商业价值。核心价值总结🚀极致性能:无锁化设计支撑10万+ TPS调度,满足最苛刻的性能要求🛡️可靠保障:完善的故障恢复和数据一致性机制,确保业务连续性📈弹性伸缩:智能应对流量波动,资源利用率最大化🔧运维友好:全面的监控、告警和治理能力,降低运维成本适用场景分析高并发互联网业务,如电商、社交、游戏等大数据处理和分析场景,需要分布式计算能力实时计算和要求低延迟的业务场景。

weixin_42079748的博客 806

Java高并发实战:从架构设计到JVM调优的八种核心解决方案

高并发是衡量系统处理海量请求能力的关键技术挑战,其核心在于通过分层与异步化设计,在保障数据一致性的前提下,最大化资源利用率和系统吞吐量。从技术原理上看,这通常涉及并发编程、缓存机制、消息队列及数据库优化等多个层面的协同。在工程实践中,这些技术为构建高性能、高可用的分布式系统提供了核心价值,广泛应用于电商秒杀、社交热点、金融交易等瞬时流量极高的场景。本文聚焦Java技术栈,系统梳理了包括微服务拆分、多级缓存、JUC工具包、异步编程、MQ解耦削峰、流量管控、数据库优化及JVM调优在内的实战方案,其中对Redis

weixin_31742871的博客 228

如何为不同的业务场景选择最合适的技术方案?例如,什么时候应该用关系型数据库,什么时候用NoSQL?什么时候该引入消息队列?

在技术的世界里,我们从不缺少闪亮的“锤子”——新的数据库、新的框架、新的模式层出-不穷。然而,一个优秀架构师的标志,并非是总能挥舞最新最亮的锤子,而是能精准地判断眼前的到底是不是一颗钉子,并为它选择最称手的那一把。当您下一次面对一个新需求时,不妨先从这几个核心问题开始,您会发现通往正确技术方案的道路,将变得异常清晰。本文将为您揭示这一决策过程背后的思考框架,并以您关心的“数据库选型”和“消息队列引入时机”为例,进行深度剖析。默认情况下,服务间的调用是同步的。技术选型的能力,是衡量架构师价值的核心标尺。

m0_59598970的博客 1011

Redis高可用心路历程以及多种业务场景下的使用模式

本文主要分析了单节点下redis的缺陷以及多场景下的使用方法、针对可能出现的问题进行的了分析,根据业务场景从单节点过渡到主从复制、哨兵集群、分片集群。

小爽帅到拖网速的博客 1030

电商订单系统设计:高并发与分布式事务实战

订单系统作为电商平台的核心模块,承载着交易链路的关键业务逻辑。其本质是通过状态机模型管理订单生命周期,并确保在多系统协作下保持数据一致性。在技术实现上,需要结合分布式事务与高并发设计,如采用本地消息表、Seata等方案解决跨服务数据一致性问题,通过预扣库存、分库分表等策略应对秒杀场景。典型应用包括双11大促的流量洪峰处理,以及跨境电商中的多时区状态同步。本文以某日均50万+订单的跨境平台为例,剖析订单聚合设计、状态机实现等核心技术要点,并给出库存扣减、分库分表等场景的工程实践方案。

weixin_42662293的博客 295
上一篇: Mysql操作binlog时报错mysqlbinlog: unknown variable 'default-character-set=utf8mb4'
下一篇: 常用的数据库表水平拆分方案
hwmhehe
博客等级 码龄13年 86粉丝 106原创
评论 8
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值