日活3kw的实际库存业务场景中的超卖到底怎么解决的

这个问题其实可以说是日活随便一百度几乎可以出来全是解决方案，其实超卖问题在实际业务场景中是实的超底解十分复杂的。没有什么绝对的际库景中决解决方案。都是存业因人而异的。

"超卖"是日活指商品售出数量超过实际库存量的情况。通常在处理商品库存扣减时，实的超底解我们会先检查库存是际库景中决否充足，如果足够则进行扣减，存业否则直接返回下单失败。日活

然而，实的超底解在高并发环境下，际库景中决可能出现以下情形：

在高并发情况下，存业当两个并发线程同时查询库存时，日活假设数据库中库存仅剩1个，实的超底解两个线程都获得了1的际库景中决库存量。在经过库存校验后，它们分别开始执行库存扣减操作，最终导致库存变成负数。

这种情况是b2b信息网高并发环境下典型的超卖问题。

超卖问题的根源在于并发操作，因此解决超卖问题实质上就是解决并发问题。在上述情况中，关键在于确保库存扣减过程的原子性和有序性。

原子性指的是库存查询、库存判断和库存扣减这一系列操作作为一个不可分割的整体，不会被中断，也不会被其他线程同时执行。这确保了操作的完整性和一致性。有序性则要求多个并发操作按照一定的顺序执行，避免出现竞争条件，从而保证数据的准确性和正确性。

通过确保库存扣减操作的原子性和有序性，可以有效解决高并发环境下的超卖问题，保障系统的稳定性和可靠性。

一、实现方案：数据库

从三个角度考虑实现：

数据库层面的悲观锁数据库层面的乐观锁依赖数据库执行引擎的服务器托管顺序执行机制

以上三个角度简单来说：在处理库存扣减时，常见的方法是通过数据库操作实现。确保操作的原子性和有序性通常可以通过加锁实现，无论是悲观锁还是乐观锁都可以达到这个目的。

1.悲观锁的实现方式 复制-- 开始事务 BEGIN; -- 查询商品信息并加锁 SELECT quantity FROM items WHERE id = 1 FOR UPDATE; -- 修改商品数量为2 UPDATE items SET quantity = 2 WHERE id = 1; -- 提交事务 COMMIT;1.2.3.4.5.6.7.8.9.10.11.

注意：

在前述讨论中，我们提到了使用SELECT...FOR UPDATE会对数据进行锁定，但需要注意锁的级别。在 MySQL InnoDB 中，默认使用行级锁。行级锁是基于索引的，如果一条 SQL 语句没有使用索引，那么不会使用行级锁，而会使用表级锁将整个表锁定。因此，这一点需要引起注意。

然而，使用悲观锁可能会导致请求阻塞和排队，在高并发情况下可能对数据库造成负担。乐观锁则通过版本号等方式控制顺序执行，但在高并发环境下可能会出现大量失败操作，不适合高并发场景，因为在更新过程中也需要加行级锁，可能会导致阻塞。亿华云计算

2.乐观锁的实现方式

在MySQL中，乐观锁主要通过CAS（Compare and Swap）机制来实现，通常通过版本号来实现。CAS是一种乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能成功更新变量的值，而其他线程会失败。失败的线程不会被挂起，而是会被告知在这次竞争中失败，并可以再次尝试。

举例来说，对于之前提到的库存扣减问题，通过乐观锁可以实现以下操作：

复制//查询出商品信息，quantity = 3 select quantity from items where id=1 //根据商品信息生成订单 //修改商品quantity为2 update items set quantity=2 where id=1 and quantity = 3;1.2.3.4.5.6.

尽管如此，即使不使用锁也是可行的。可以依赖数据库执行引擎的顺序执行机制，只需确保库存不会变为负数。这种情况下，可以通过巧妙设计的SQL语句来实现操作的原子性和有序性。

3.数据库执行引擎的实现方式

举例来说，假设有一张名为"inventory"的表，其中包含"product_id"和"stock"字段，可以通过以下SQL语句来实现库存扣减：

复制UPDATE inventory SET stock = stock - 1 WHERE product_id = your_product_id AND stock > 0;1.2.3.

这样的SQL语句能够确保在库存大于0的情况下进行扣减，避免库存变为负数。通过这种方式，可以在不加锁的情况下有效地管理库存扣减操作。

有人可能会觉得数据库执行引擎的实现方式挺好的。然而，这种解决方案并不理想。实际上，这种方式与乐观锁方案的缺点相同，都完全依赖于数据库。在高并发情况下，多个线程同时更新库存时可能会导致阻塞。这不仅会导致操作速度变慢，还可能给数据库带来压力。

通常情况下，MySQL的热点行更新最多也只能承受200-300个并发更新。如果需要更高的并发处理能力，一种方法是提升硬件水平，另一种方法是进行一些技术改造，比如采用inventory hint的方式。

说到这里，数据库层面的超卖的解决实现方案也就聊的差不多了。

二、实现方式：Redis

我们可以利用Redis的单线程执行特性，结合Lua脚本执行过程中的原子性保障，实现库存扣减操作。通过在Redis中使用如下Lua脚本：

复制local key = KEYS[1] -- 商品的键名 -- 获取商品当前的库存量 local remaining_stock = tonumber(redis.call("GET", key)) local quantity_to_reduce = tonumber(ARGV[1]) -- 扣减的数量 -- 如果库存足够，则减少库存并返回新的库存量 if remaining_stock >= quantity_to_reduce then redis.call("DECRBY", key, quantity_to_reduce) return "Stock reduced successfully" else return "Insufficient stock" end1.2.3.4.5.6.7.8.9.10.11.12.13.

通过先从Redis中获取当前剩余库存，然后进行足够性检查并执行扣减操作，可以有效避免并发问题。由于Lua脚本在执行过程中不会被中断，且Redis是单线程执行的，因此在脚本中进行这些操作可以确保原子性和有序性。这种方法结合了Redis的高性能和分布式缓存特性，使得使用Lua脚本扣减库存非常高效。

三、我们实际项目中如何处理超卖的

在实际应用中，通常会结合使用数据库和Redis两种方案来实现库存扣减操作。一种常见的做法是首先利用Redis进行扣减操作以应对高并发流量，然后将扣减结果同步到数据库中，实现扣减并进行持久化存储，以防止Redis宕机导致数据丢失。

具体流程如下：

首先在Redis中进行库存扣减操作，然后发送一个消息到消息队列（MQ）。消费者接收到消息后，执行数据库中的真正库存扣减以及其他业务逻辑操作。

Redis扣减操作示例代码：

可以使用上述提到的Lua脚本方式，或者采用如下Redisson方式

复制import org.redisson.Redisson; import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.redisson.config.Config; public class InventoryConsumer { public static void main(String[] args) { Config config = new Config(); config.useSingleServer().setAddress("redis://localhost:6379"); RedissonClient redisson = Redisson.create(config); RLock lock = redisson.getLock("inventory_lock"); try { lock.lock(); // 执行库存扣减及其他业务逻辑操作 // 例如：更新数据库中的库存信息 // 注意：在锁内执行扣减操作 } finally { lock.unlock(); redisson.shutdown(); } } }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.

消费者示例代码：

复制public class InventoryConsumer { public static void main(String[] args) { Jedis jedis = new Jedis("localhost", 6379); Connection conn = null; try { conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/database", "user", "password"); jedis.subscribe(new JedisPubSub() { @Override public void onMessage(String channel, String message) { // 在收到消息时执行数据库操作，进行库存扣减及其他业务逻辑 try { Statement stmt = conn.createStatement(); stmt.executeUpdate("UPDATE inventory SET stock = stock - 1 WHERE product_id = 123"); conn.commit(); } catch (SQLException e) { e.printStackTrace(); } } }, "inventory_update"); } catch (Exception e) { e.printStackTrace(); } finally { if (conn != null) { try { conn.close(); } catch (SQLException e) { e.printStackTrace(); } } jedis.close(); } } }1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.

通过结合使用Redis和数据库，可以充分发挥它们各自的优势，实现高效的库存管理并确保数据的一致性和持久性。

这种方法确实有助于确保Redis中的数据与数据库中的数据最终保持一致，同时也有助于避免超卖的情况发生。然而，存在一个潜在问题，即可能导致少卖的情况发生。

四、少卖的解决方案

在上述流程中，如果第一步成功执行，导致Redis中的库存成功扣减，但随后的第二步消息未能成功发送，或者在后续消费过程中消息丢失或失败，就可能出现Redis中库存减少而数据库库存未减少的情况，从而导致实际业务操作未能发生。这种情况会导致Redis中出现多扣的情况，进而引发少卖的问题。

为了解决这类问题，需要引入一种对账机制，实施准实时核对，及时发现并处理这类情况。如果发现存在较大的少卖问题，需要将这些库存重新添加回去。

在许多成熟的电商公司中，无论之前的方案多么完善，这种对账系统都是不可或缺的。及时进行核对，发现超卖、少卖等问题至关重要。

一个简单的示例是，在消费者处理消息时，记录每次库存变化的日志，包括扣减和增加操作，然后定期对比Redis中的库存和数据库中的库存，检查是否存在不一致的情况。如果发现多扣或少卖的情况，可以根据日志记录进行修正。

这种对账机制可以帮助保证系统的数据一致性，并及时发现并纠正潜在的问题，确保业务操作的准确性和稳定性。

综上所述可得没有完美的解决方案，引入新的中间件总会面临的的问题。这就需要根据实际业务进行权衡了。

本文地址：http://www.bzve.cn/html/398a2599576.html