乐观锁解决并发下单问题和事务隔离级别的修改

最新推荐文章于 2025-04-18 10:00:00 发布
最新推荐文章于 2025-04-18 10:00:00 发布
阅读量371 收藏
点赞数
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/zw496862766/article/details/104138836
本文探讨了使用乐观锁解决电商场景下并发下单的问题，详细解释了如何通过循环尝试更新库存来确保交易的一致性，同时介绍了如何修改MySQL的事务隔离级别以实现更高效的并发控制。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

一.乐观锁结果并发下单问题

1.查询商品
查询原有库存
查询原有销量
2.以商品和原有库存作为条件,用result接收结果,result=0,表示被修改,下单失败,若不等于零表示原始库存中途未被修改,则更新库存和销量
3.如果遇到网络信号不好,那么用户只买一个但是库存100时也会下单失败
购买成功包括两点:
库存大于购买商品数
库存没有被他人修改
4.所以使用无线循环,如果库存被改动,循环下单,直到库存不足,跳出循环
5.事务隔离级别决定了是否能查到已被修改后的库存数据
所以修改事务隔离级别为Read committed读取已提交

#循环下单直到库存不足
  while True:
  	#查询商品
  	sku=SKU.object.get(id=sku_id)
  	#查询商品原始库存
  	origin_stock=sku.stock
  	origin_sales=sku.sales
  	.....其他操作
	#乐观锁更新数据库销量
	new_stock=origin_stock - sku_count
	new_sales=origin_sales + sku_count	
	result=SKU.objects.fllter(id=sku_id,sku.stock=origin_stock)
		.update(stock=new_stock,sales=new_sales)
	#如果下单失败但是库存足够,继续下单,直到下单成功
	if result==0:
		continue
	#下单成功跳出循环
	break

二.修改事务隔离级别

MySQL事务隔离级别修改
隔离级别指,在处理同一个数据的多个事务中,一个事务修改数据后,其他事务能否看到修改后结果
默认使用可重复读（ Repeatable read）。
修改:

cd /etc/mysql/mysql.conf.d/
ls
sudo vim mysql.cnf
105 transaction-isolation=Read committed

Read committed:读取已提交,其他事务提交了对数据的修改后,本事务就能读取到修改后的数据值

事务隔离级别——READ-UNCOMMITTED（读未提交）
Zzze0101的博客
06-08 5746
首先，我们先设置MySQL事务隔离级别为Read uncommitted 在my.ini配置文件最后加上如下配置 #可选参数有：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. [mysqld] transaction-isolation = READ-UNCOMMITTED 重启MySQL服务 1、脏读 提...
PostgreSQL 中如何处理数据的并发读写和事务隔离级别选择？
技术笔记
07-16 1215
读已提交是大多数数据库系统的默认隔离级别，在这个级别下，一个事务只能读取到已经提交的数据，避免了脏读的问题，但仍然可能会出现不可重复读和幻读的问题。读已提交的隔离级别就好比一个人在一个有门但没有锁的房间里工作，只有当其他人完成工作并离开房间后，他才能进入房间，这样可以避免看到别人未完成的工作，但他可能会在不同的时间看到房间里的不同情况。可重复读是比读已提交更高的隔离级别，在这个级别下，一个事务在执行过程中，多次读取同一数据的结果是一致的，避免了不可重复读的问题，但仍然可能会出现幻读的问题。
Django 中订单并发处理
qyf__123的博客
11-28 1679
并发处理 在多个用户同时发起对同一个商品的下单请求时，先查询商品库存，再修改商品库存，会出现资源竞争问题，导致库存的最终结果出现异常。 解决办法： 悲观锁 当查询某条记录时，即让数据库为该记录加锁，锁住记录后别人无法操作，使用类似如下语法 select stock from tb_sku where id=1 for update; SKU.objects.select_for_update...
事务隔离级别与乐观锁、悲观锁
cpf2016的专栏
02-15 1291
1.引入      在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这样会产生冲突，就会造成并发性问题。      冲突类型：      （1）脏读                指一个事务A正在访问数据，并且对数据进行了修改，但是这种修改还没有提交到数据库，这时另一个事务B也访问这个数据，而A事务产生了异常，发生了回滚，但是B事务使用的还是A修改后的数据，这个就是脏读
RocketMQ高并发项目——下订单与库存的乐观锁机制、分库分表介绍
哈喽羊
05-09 1434
关于乐观锁的概念介绍摘自https://www.cnblogs.com/sheseido/p/5038562.html，特此声明！ 一.下订单与库存的乐观锁机制 乐观锁，大多是基于数据版本 Version 记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取...
事务的隔离级别以及乐观锁，悲观锁
zhouren1314的专栏
02-27 1329
事务的隔离级别： 先说说 （通俗说）  1. 脏读：是一个事务读取了  其他事务没有提交的数据。 2.不可重复度：就是第一次读和第二次读，两次读到的 数据不一致，原因是：在此期间有其他的事务修改了数据。 3.幻读：就是第一次读和第二次读，两次读到的 数据不一致， 原因是：在此期间有事务插入了新的数据(区别于不可重复读：不可重复读是  对于修改操作而言，幻读对插入造作而言) 事务的隔离级
【数据库并发控制机制】：锁与事务隔离级别实战解析
本文深入探讨了数据库并发控制的相关技术，从锁机制的理论基础到实际应用，再到事务隔离级别的详细解析，系统性地介绍了并发控制的高级策略以及案例分析与调试技巧。文章首先对锁机制进行了深度解析，包括锁的分类、...
【并发控制机制】：隔离级别和锁策略的深度剖析
通过对比不同事务隔离级别和锁机制，本文揭示了并发操作中可能出现的问题，如脏读、不可重复读、幻读以及死锁，并提供了相应的解决方案和权衡策略。本文还探讨了并发控制在高并发数据库系统和分布式系统中的实际应用...
【Java进阶必备】深入理解事务原理(二) - 隔离级别与传播机制详解
最新发布
Pte_moon的博客
04-18 1099
🔥 本文是Java事务系列的第二篇，深入讲解事务的隔离级别和传播机制。通过本文，你将彻底理解事务并发问题的本质，以及如何正确使用事务传播行为。
PostgreSQL并发控制机制：理解锁与事务隔离级别的权威指南
![PostgreSQL并发控制机制：理解锁与事务隔离级别的权威指南](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/... # 摘要 本文深入探讨了PostgreSQL数据库的...
事务隔离级别+悲观乐观锁
fupenghao的博客
02-07 432
事务1、事务的概念： 事务是用来维护数据库完整性的，能够保证一系列的mysql操作要么全部执行，要么全部不执行 一个mysql语句就是一个事务 事务指的是一个操作序列，这个操作序列的多个操作要么全部执行，要么全部不执行，是不可分割的单位，是数据库环境中逻辑工作单位 2、事务的特征： 原子性：对数据的修改要么全部执行成功，要么全部失败（实现事务的原子性，基于redo/undo机制） 一致性：事务执行的结果从一个一致性状态，到达另一个一致性状态（前后状态要一直） 隔离性：事务的执行相互独立，不受影响 永久性：
事务隔离级别&悲观乐观锁
Bob欧巴のblog
07-26 530
本文是对https://github.com/ScrappyZhang/python_web_Crawler_DA_ML_DL/blob/master/web%E5%85%A8%E6%A0%88%E5%BC%80%E5%8F%91/Django%E7%94%B5%E5%95%86%E7%BD%91%E7%AB%99%E5%BC%80%E5%8F%91%E5...
Mysql中的读锁，写锁，乐观锁及事务隔离级别和并发问题
weixin_30319153的博客
07-04 206
mysql读锁，写锁，乐观锁 读锁，也叫共享锁（shared lock） SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 写锁，也叫排他锁（exclusive lock） SELECT * FROM table_name WHERE ... FOR UPDATE 乐观锁，是一种逻辑锁，通过数据的版本号（ves...
事务并发(乐观锁)
Yuncoco的博客
06-23 1983
一、 事务4个特性ACID 原子性(Atomic)，事务必须是原子工作单元； 一致性(Consistent)，事务在完成时，必须使所有的数据都保持一致状态。 隔离性(Insulation)，由事务并发所作的修改必须与任何其它并发事务所作的修改隔离。 持久性(Duration)，事务完成之后，它对于系统的影响是永久性的。 二、事务并发 通常为了获得更好的运行性能，各种数据库都允许多个事务同时运...
Hibernate事务与并发问题处理（乐观锁与悲观锁）
alva88888888的博客
01-27 374
目录 一、数据库事务的定义 二、数据库事务并发可能带来的问题 三、数据库事务隔离级别 四、使用Hibernate设置数据库隔离级别 五、使用悲观锁解决事务并发问题 六、使用乐观锁解决事务并发问题 Hibernate事务与并发问题处理（乐观锁与悲观锁） 一、数据库事务的定义 　　数据库事务(Database Transaction) ，是指作为单个逻辑工作单元...
乐观锁的使用场景以及失效问题
qq_39220971的博客
04-24 3416
乐观锁是什么 以及乐观锁如何使用 使用场景是什么
悲观锁和乐观锁
jiangwei_80的博客
04-04 222
一、概念 悲观锁顾名思义：数据被外界修改总是保持悲观的态度，事物每次去操作数据的时候，都假设有其他事物要修改访问的数据，所以在访问数据之前，都要加上锁，因此数据在操作过程中，数据是被锁定的。进一步解释：总是假设在最坏的情况下，每次去拿数据的时候都认为会被别人修改，所以在拿数据的时候，对数据加锁，别人拿数据的时候就会阻塞，直到它获取该数据的锁，传统的关系型数据库都使用到这种锁，例如：行锁，表锁，读...
乐观锁原理应用
weixin_48493949的博客
09-23 306
乐观锁主要解决的问题 乐观锁主要解决了 丢失更新的问题 丢失更新 多个人同时修改同一条记录，最后提交的会把之前提交的数据覆盖 解决方案 1.悲观锁：串行，同时只能一个人操作 2.乐观锁： 乐观锁实现方式： 取出记录时，获取当前version 更新时，带上这个version 执行更新时， set version = newVersion where version = oldVersion 如果version不对，就更新失败 MybatisPlus乐观锁的具体实现 1.表中添加字段，作为乐观锁的版本号 给
Mysql之事务隔离级别与锁机制
2302_77659577的博客
07-17 400
隔离级别决定了事务之间的隔离程度，不同隔离级别对应不同的并发控制方式，可以根据业务需求选择合适的隔离级别。锁机制则是实现隔离级别的具体手段，悲观锁适用于并发写较多的场景，而乐观锁适用于并发写较少的场景。在实际应用中，需要根据业务场景和性能需求选择合适的隔离级别和锁机制，以保证数据的一致性和并发性。
用户高峰期下单时，数据库频繁执行订单插入和库存更新操作，导致事务锁竞争激烈。 MySQL默认隔离级别为可重复读（Repeatable Read），频繁锁表引发性能瓶颈。怎么解决这个问题
02-26
<think>好的，我现在需要解决用户提出的数据库在高并发下单时出现的锁竞争和性能瓶颈问题。用户提到MySQL默认使用可重复读隔离级别，导致频繁锁表，性能下降。我需要先理解问题背后的原因，然后思考可能的解决方案。 首先，回顾一下MySQL的可重复读隔离级别。在这个级别下，使用Next-Key Lock来防止幻读，这会导致在范围查询时锁定更多的记录，可能增加锁竞争。特别是在库存更新这样的高频操作中，如果多个事务同时尝试更新同一行（比如库存数量），可能会产生大量的行锁甚至表锁，导致阻塞。 接下来，用户的问题场景是高并发下的订单插入和库存更新。这两个操作通常在一个事务中执行，先插入订单，然后更新库存。如果事务设计不当，或者锁的粒度太大，就会导致锁竞争激烈，事务等待时间变长，进而影响性能。 可能的解决方案需要从多个方面考虑： 1. **优化事务范围**：缩短事务的执行时间，减少锁的持有时间。比如，将不必要的操作移到事务外，或者将事务拆分为更小的单元。 2. **调整隔离级别**：可重复读可能不是最适合高并发的场景，考虑使用读已提交（Read Committed）隔离级别，减少锁的范围，但需要评估是否接受幻读的风险。 3. **库存更新优化**：库存扣减是高频操作，可以考虑使用乐观锁或CAS（Compare and Set）操作，避免使用行锁。比如在更新库存时，检查当前库存是否足够，并通过版本号或时间戳来防止并发覆盖。 4. **分库分表**：如果数据量巨大，可以考虑水平分片，将库存表分散到不同的数据库实例或表中，减少单点的锁竞争。 5. **使用队列缓冲**：将下单请求先放入消息队列，异步处理订单插入和库存更新，削峰填谷，减轻数据库压力。 6. **应用层缓存**：使用Redis等缓存中间件预扣库存，减少直接访问数据库的次数。但需要注意缓存和数据库的一致性。 7. **索引优化**：确保库存更新的操作能够高效使用索引，减少锁的扫描范围。 8. **批量处理**：将多个库存更新合并为批量操作，减少事务次数。 需要具体分析每个方案的适用性。比如，调整隔离级别可能是一个快速有效的方法，但需要确保应用逻辑能处理可能出现的幻读。乐观锁适用于冲突较少的情况，高并发下可能产生大量重试，需要结合重试机制。而队列缓冲虽然能缓解压力，但增加了系统复杂性，可能影响用户体验（异步处理可能导致延迟）。 此外，还需要考虑数据库的配置参数，如innodb_lock_wait_timeout，是否合理。监控数据库的锁状态，查看是否有死锁或长时间等待的锁，通过慢查询日志分析是否有需要优化的SQL语句。 可能还需要引入读写分离，将读操作和写操作分离到不同的数据库实例，但写操作仍然集中在主库，库存更新属于写操作，所以这可能帮助有限。 总结下来，需要从事务设计、锁机制、架构优化等多个层面综合采取措施。可能需要逐步实施，先优化事务和锁竞争，再考虑架构调整。</think>针对高并发下单场景下的数据库锁竞争问题，可以通过以下多维度方案进行优化，结合具体场景选择组合策略： --- ### **一、事务与锁优化** 1. **缩小事务范围** - 将非核心操作移出事务（如日志记录、通知发送） - 示例代码改造： ```sql START TRANSACTION; /* 只保留必要操作 */ INSERT INTO orders ...; -- 订单创建 UPDATE inventory SET stock=stock-1 WHERE product_id=123 AND stock>0; -- 库存扣减 COMMIT; ``` 2. **调整隔离级别为READ COMMITTED** ```sql SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED; ``` - 减少Next-Key Lock使用 - 需评估幻读风险（可通过唯一索引或业务逻辑规避） 3. **使用SELECT ... FOR UPDATE SKIP LOCKED**（MySQL 8.0+） ```sql START TRANSACTION; SELECT * FROM inventory WHERE product_id=123 AND stock>0 FOR UPDATE SKIP LOCKED LIMIT 1; UPDATE inventory SET stock=stock-1 WHERE product_id=123; COMMIT; ``` - 跳过被锁定的记录，避免线程阻塞 --- ### **二、库存扣减优化** 1. **CAS乐观锁** ```sql UPDATE inventory SET stock = stock - 1, version = version + 1 WHERE product_id=123 AND stock > 0 AND version = #{current_version} ``` - 通过版本号避免覆盖更新 - 需配合应用层重试机制 2. **批量分段锁** ```sql -- 将库存拆分为多个slot（如10个） UPDATE inventory_slot SET stock = stock - 1 WHERE slot_id = #{hash(user_id)%10} AND stock > 0 ``` - 通过slot_id分散锁竞争 3. **Redis预扣库存** ```python # 伪代码示例 if redis.call('DECR', 'product:123:stock') >= 0: # 创建订单并异步更新数据库 send_to_queue(order_info) return success else: redis.call('INCR', 'product:123:stock') # 回滚 return out_of_stock ``` - 先扣减Redis库存再异步持久化 - 需处理Redis与MySQL数据一致性 --- ### **三、架构优化** 1. **分库分表策略** ```sql -- 按product_id分片（示例分16片） CREATE TABLE inventory_0000 ... -- 分片表0 CREATE TABLE inventory_0001 ... -- 分片表1 ... CREATE TABLE inventory_000F ... -- 分片表15 ``` - 通过sharding_key分散写压力 2. **读写分离架构** ``` [应用层] ├── 写请求 → 主库 └── 读请求 → 从库 ``` - 需配合中间件（如MyCat、ShardingSphere） 3. **异步队列削峰** ``` 用户请求 → 消息队列（Kafka/RabbitMQ） → 消费者批量处理 ``` - 示例吞吐对比： ``` 直接写DB：约2000 TPS 队列缓冲：可达到5000+ TPS ``` --- ### **四、数据库参数调优** ```ini # my.cnf配置 [mysqld] innodb_buffer_pool_size = 80%物理内存 # 缓存优化 innodb_flush_log_at_trx_commit = 2 # 适当降低持久化要求 innodb_autoinc_lock_mode = 2 # 提升自增列并发 innodb_thread_concurrency = 0 # 自动调整并发线程数 ``` --- ### **五、监控与应急方案** 1. **锁监控** ```sql SHOW ENGINE INNODB STATUS; -- 查看锁信息 SELECT * FROM information_schema.INNODB_TRX; -- 当前事务 ``` 2. **熔断降级** - 当库存低于阈值时返回「库存紧张」提示 - 动态限流（令牌桶/漏桶算法） 3. **热点数据特殊处理** ```sql -- 对秒杀商品使用内存表 CREATE TABLE flash_sale_inventory ( product_id INT PRIMARY KEY, stock MEDIUMINT UNSIGNED ) ENGINE=MEMORY; ``` --- ### **方案对比表** | 方案 | 优点 | 缺点 | 适用场景 | |--------------------|-------------------------|-------------------------|---------------------| | CAS乐观锁 | 无锁竞争 | 高并发时重试率高 | 冲突较少的长尾商品 | | 分库分表 | 线性扩展能力 | 架构复杂度高 | 千万级SKU的大型电商 | | Redis预扣库存 | 吞吐量极高 | 数据一致性维护复杂 | 秒杀场景 | | 异步队列 | 平滑流量峰值 | 增加延迟 | 允许最终一致性的业务 | 建议采用组合方案：**Redis预扣库存 + 异步队列 + 分库分表**，配合数据库参数优化，可实现百万级TPS的订单处理能力。具体实施时需根据业务特点进行压测验证。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值