海口h5建站,如何免费创建网站,嘉定集团网站建设,吉安网站建设吉安电商系统中秒杀是一种常见的业务场景需求#xff0c;其中核心设计之一就是如何扣减库存。本篇主要分享一些常见库存扣减技术方案#xff0c;库存扣减设计选择并非一味追求性能更佳#xff0c;更多的应该考虑根据实际情况来进行架构取舍。在商品购买的过程中#xff0c;库存…电商系统中秒杀是一种常见的业务场景需求其中核心设计之一就是如何扣减库存。本篇主要分享一些常见库存扣减技术方案库存扣减设计选择并非一味追求性能更佳更多的应该考虑根据实际情况来进行架构取舍。在商品购买的过程中库存的抵扣过程通常包括以下步骤
开启事务在开始进行库存抵扣操作前开启一个事务。查询库存根据商品ID使用SELECT语句从库存表中查询该商品的当前库存数量。检查库存是否足够将查询到的库存数量与用户购买数量进行比较。如果库存数量大于或等于用户购买数量则库存足够可以继续下单。如果库存不足需要采取相应的处理措施例如提示用户库存不足或进行库存预订等。扣减库存如果库存足够根据用户购买数量使用UPDATE语句将库存表中对应商品的库存数量减去购买数量得到最新的库存剩余值。记录交易明细在购买过程中通常需要记录交易明细例如生成订单记录或交易日志以便后续查询和跟踪。提交事务以上操作通常会在一个事务中进行确保操作的原子性。如果所有步骤都成功执行则提交事务库存扣减过程完成。如果在任何步骤中出现错误或异常事务会回滚恢复到操作前的状态确保数据的完整性和一致性。
由于涉及到 SELECT后进行UPDATE以上步骤中存在多事务并发时写覆盖的问题。
悲观锁更新库存
在数据库并发控制中防止写覆盖是一个重要的问题特别是在多个会话事务同时尝试修改同一行数据时。如果不进行适当的并发控制可能会导致数据的不一致性和丢失更新。
为了解决这个问题可以使用 SELECT FOR UPDATE语句。在使用SELECT FOR UPDATE时数据库会将目标行的数据加上写锁阻止其他事务在当前事务完成之前修改被锁定的数据。这样其他会话无法同时修改同一行数据从而避免了并发写入冲突。
需要注意的是使用SELECT FOR UPDATE可能会引起一些并发性能问题因为其他会话需要等待锁释放才能继续执行。因此在设计并发控制策略时需要综合考虑并发性能和数据一致性之间的平衡。
在上述流程中步骤3 改为
3. 查询库存并锁定使用SELECT ... FOR UPDATE语句查询指定商品的库存并将其锁定。这将确保其他并发事务在当前事务提交或回滚之前无法修改该商品的库存。 # 开始事务connection.begin()# 加锁FOR UPDATE并读取当前库存记录cursor.execute(SELECT quantity FROM inventory WHERE id ? FOR UPDATE, item_id)current_quantity cursor.fetchone()[quantity]# 检查库存是否足够if current_quantity requested_quantity:# 计算更新后的库存数量new_quantity current_quantity - requested_quantity# 更新库存cursor.execute(UPDATE inventory SET quantity ? WHERE id ?, (new_quantity, item_id))#{... 记录明细等操作}# 提交事务connection.commit()return Trueelse:# 库存不足回滚事务connection.rollback()return False 乐观锁更新库存
除开悲观锁自然也可以想到使用乐观锁的方式来进行更新最常见的设计就是CAS 版本号的更新来实现库存更新在库存表中新加一个 version的字段。
# 开始事务
connection.begin()# 读取当前库存记录和版本号
cursor.execute(SELECT quantity, version FROM inventory WHERE id ?, item_id)
result cursor.fetchone()
current_quantity result[quantity]
current_version result[version]# 检查版本号是否匹配
if current_quantity requested_quantity:# 计算更新后的库存数量和版本号new_quantity current_quantity - requested_quantitynew_version current_version 1# 更新库存和版本号cursor.execute(UPDATE inventory SET quantity%s,version%s WHERE id%s AND version%s,(new_quantity, new_version, item_id, current_version))#{... 记录明细等操作}# 检查是否有更新行数if cursor.rowcount 1:# 提交事务connection.commit()return Trueelse:# 更新失败可能是由于版本号不匹配导致的并发操作问题connection.rollback()return False
else:# 库存不足回滚事务connection.rollback()return False可以进一步思考是否需要版本的概念扣减库存流程中如果将 SELECT 查询 作为库存超卖前置检查的保障扣减成功率减少不必要的写操作是视角看待其实需要保障的是扣减后的库存是否大于等于零。 如何理解前置检查视角? 用个卖西瓜的例子来说明假如你今天微信问到楼下水果店老板有特价5毛一斤西瓜还有10个这时你立刻下楼去购买。那么可能两种结果结果一 你买到了特价西瓜结果二 买的人太多你到店的时候已经卖光了。从结果看微信询问的消息只是决定你下不下楼购买而并非决定真正买到不影响库存这种询问作用在于减少直接下楼购买花费体力。 # 读取当前库存记录cursor.execute(SELECT quantity FROM inventory WHERE id ? , item_id)current_quantity cursor.fetchone()[quantity]# 检查库存是否足够if current_quantity requested_quantity:# 开始事务connection.begin()# 更新库存cursor.execute(UPDATE inventory SET quantity quantity-? WHERE id ? and quantity - ? 0, (requested_quantity, item_id,requested_quantity))#{... 记录明细等操作}# 检查是否有更新行数if cursor.rowcount 1:# 提交事务connection.commit()return Trueelse:# 更新失败connection.rollback()return Falseelse:return False 库存读写分离
再考虑一个极端的例子假设有一个最新款的 iPhone 秒杀活动库存只有 100 件活动期间预估峰值每秒查询请求量QPS为 10 万次。在活动结束后流水表最终只会插入 100 条记录但是查询的 QPS 却接近 10 万次导致读取的压力非常大。
在这种情况下查询压力主要是由于活动期间大量的用户查询商品的秒杀状态和库存数量所导致的。虽然流水表最终只插入了 100 条记录但是查询请求却非常频繁可能会导致数据库性能问题。
优化首先可以想到是采用读写分离架构通过新增一套从库来实现。借助MySQL自带的数据同步能力可以将主库的数据同步到从库从而在读取库存时可以直接查询从数据库。这样可以将读取请求分散到从库减轻主库的查询压力。 虽然读写分离可以提高查询性能但需要注意从库的数据同步可能会有一定的时间延迟导致从库的数据新鲜度实时性有一定的滞后性。前置检查视角在进行库存校验时从库的数据并不一定完全准确但可以拦截大部分无效流量起到了一定的作用。
最终的购买决策仍然由主库的UPATE SQL语句来控制以确保最终扣减的准确性。虽然从库的数据可能有一定的滞后但并不会影响最终扣减的结果因为购买操作仍然在主库上执行确保了数据的一致性和准确性。
优点1. 借助数据库的 ACID 特性确保事务的原子性、一致性、隔离性和持久性避免了超卖和少买等业务问题。 2. 实现简单适用于项目工期紧张或开发资源有限的情况。
不足 如果参与秒杀的 SKU库存量单位非常多最终的写操作都是基于库存主库可能会导致主库的性能压力较大。
这里 牺牲数据实时性新鲜度 来提升性能 是一种典型的 技术架构选型的 取舍方向。
库存分库分表
为了解决上述存在的容量和性能上限问题库存分库分表会是一种优化选择。 将库存扣减表和扣减明细表根据商品ID进行水平拆分将不同商品的记录存储在不同的分片中。这样可以将高并发的请求路由到不同的数据库实例上分摊数据库负载。 在水平拆分的基础上进一步考虑将不同商品的记录分布在不同的数据库实例中每个实例称为一个库。对于每个库可以再将表进行分表将不同商品的记录分开存储。例如可以按照商品ID的哈希值进行分表或者按照一定的范围将商品ID进行分段确保每个表的数据量均衡。
在实际应用中系统需要根据商品ID来决定将请求路由到哪个数据库实例上。可以使用一致性哈希算法、分段路由规则等方式来实现请求的正确路由。这样可以确保同一商品的库存扣减和明细记录在同一个数据库实例上进行保证事务的原子性和数据的一致性。 总体来说通过水平拆分和分库分表的设计可以有效地提高系统的吞吐量和性能并减轻单一实例的容量限制。但是在实际应用中需要仔细考虑数据库的选择、数据路由策略、数据一致性等问题以确保系统的可用性和性能。同时还需要合理评估业务需求和数据增长趋势以选择合适的分片和数据库配置避免出现过度分片或数据倾斜等问题。
缓存扣减库存
读写分离、分库分表确实能分摊主库很大一部分压力但是如果面对是 单品万级QPS 的秒杀流量MySQL 的千级 TPS 同样也支撑不了需要进一步升级性能。
(读 改为 Redis)此时引入缓存中间件将 MySQL 的数据定时同步到缓存中可能存在延迟库存显示不准确。库存超卖前置检查从 Redis 中查询剩余的库存数据写入操作在数据库校验不准也不会超卖。 由于缓存基于内存操作性能比数据库高出几个数量级单台 Redis 实例可以达到 10W QPS 的读性能。 读/写库存都为 Redis对于扣减库存的操作如果直接执行多个 Redis 命令无法保证原子性。为了确保原子性可以采用 Lua 脚本的形式将多个 Redis 命令打包到一个脚本中作为一个命令发送给 Redis 执行从而保证了操作的原子性。
具体步骤如下
使用 Lua 脚本将扣减库存的多个 Redis 命令封装在一个 Lua 脚本中。这样可以确保这些命令在 Redis 中以原子方式执行避免并发问题。执行 Lua 脚本将封装了扣减库存逻辑的 Lua 脚本作为一个整体命令发送给 Redis 执行。这样在 Redis 中执行脚本时将按照脚本中的逻辑一次性执行多个命令。异步保存到数据库Redis 扣减库存成功后将此次扣减操作异步化保存到数据库中进行持久化存储。 单品分桶扣减
在更大规模,针对单一商品的超高并发扣减的库存集群中可能基于数据库内核的改造优化还无法满足业务需求。单一商品的超高并发扣减可能会影响到同一数据库实例上的其他商品扣减同一个数据库实例上也可能存在多个热点商品造成互相影响这时就考虑引入基于缓存的分桶扣减方案。
将商品ID按照一定的规则分成多个桶Bucket每个桶对应一个缓存项。例如可以根据商品ID的哈希值或者取模运算的结果来分桶。分桶的目的是将不同商品的库存信息均匀地存储在不同的缓存项中避免单个缓存项过大导致性能问题。
在进行库存扣减时首先根据商品ID找到对应的缓存项。然后在缓存中读取当前库存数量并进行判断是否足够进行扣减操作。如果足够更新缓存中的库存数量并将扣减后的值存回缓存。如果不足直接返回扣减失败。
其他解决方案 针对单品较多场景也可以考虑批量扣减库存批量处理库存的更新操作这样可以大量的减少数据库事务。 基于消息的库存下单完成后发生订单相关消息库存通过消息消费的方式进行更新优势在于库存的更新速率可控。 令牌库存可控的时间内进行秒杀库存提升用户秒杀感知。
以上综述
可以看到库存扣减方案场景多样更多的 应该根据业务要求 以及 具体的流量进行选择仅追求性能非好的选择性能高的同时 往往意味 着其他方面的取舍比如代码复杂性、库存精准性、部署复杂性等等。
