关于订单库存扣减的最佳实践

一： 背景

在电商的业务场景中每个商品都是有库存的，而且可能存在很多限售的运营策略。我们团队面临社区电商的业务场景更为复杂。不仅仅是库存限售，存在区域，门店，用户，运营分组，物流等的限售策略。如何面对日单量千万级别（未来更多），和多个维度的限售策略而不超卖，少卖是一个必须解决的问题。

​ 下面就是库存扣减的流程图。冲图种我们可以看出，要保证整个扣减库存不出问题，限购查询和库存的扣减必须是原子性的而且要单线程执行。

​

​ 现在处理这种场景存在多种方案。但是要保证高性能和高可用，大部分方案并不满足。

二：探索

1. 历史数据库的事务特性和唯一主键的实现原子操作和单线程操作

​ 基于数据库的事务，扣减库存的操作方法同一个事务中进行库存扣减，事务中任何操作失败，执行回滚操作。从而保证原子性。单纯靠数据库的事务，只能在单体的项目中。如何要分布式的项目中，就无法保证单线程操作了。

​ 那如何在多进程中实现单线程扣减库存呢？我们可以利用数据库的唯一索引。具体操作步骤：

  • 新建立一张表：t_lock_tbl，同时将商品ID作为唯一索引。
  • 进行扣减库存之前在表中插入商品ID，然后进行数据库更新。
  • 更新结束后上次刚才插入数据库中的记录，释放锁。

A线程进程扣减库存时候，插入了该商品的id，当B线程扣减该商品的库存的时候，同样也会在数据库中插入该商品ID，A线程没有执行完B线程插入同一个商品ID就会报主键重复的错误，这样就扣减库存失败。

这种方案，功能上是可以实现，但是过分依赖数据库，无法满足性能要求，而且存在很多获取锁失败的情况，用户体验差。

2. 利用分布式锁

​ Redis 或者 ZooKeeper 来实现一个分布式锁，以商品维度来加锁，在获取到锁的线程中，按顺序去执行商品库存的查询和扣减，这样就同时实现了顺序性和原子性。

​ 其实这个思路是可以的，只是不管通过哪种方式实现的分布式锁，都是有弊端的。以 Redis 的实现来说，仅仅在设置锁的有效期问题上，就让人头大。如果时间太短，那么业务程序还没有执行完，锁就自动释放了，这就失去了锁的作用；而如果时间偏长，一旦在释放锁的过程中出现异常，没能及时地释放，那么所有的业务线程都得阻塞等待直到锁自动失效，这样可能导致CPU飙升，系统吞吐量下降。这与我们要实现高性能的系统是相悖的。所以通过分布式锁的方式可以实现，但不建议使用。

3. Redis + lua 脚本

​ reids，单线程支持顺序操作，而且性能优异，但是不支持事务回滚。但是通过redis+lua脚本可以实现redis操作的原子性。这种方案同时满足顺序性和原子性的要求了。

这里能帮我们实现 Redis 执行 Lua 脚本的命令有两个，一个是 EVAL，另一个是 EVALSHA。

原生 EVAL 方法的使用语法如下：

EVAL script numkeys key [key ...] arg [arg ...]

​ 其中 EVAL 是命令，script 是我们 Lua 脚本的字符串形式，numkeys 是我们要传入的参数数量，key 是我们的入参，可以传入多个，arg 是额外的入参。但这种方式需要每次都传入 Lua 脚本字符串，不仅浪费网络开销，同时 Redis 需要每次重新编译 Lua 脚本，对于我们追求性能极限的系统来说，不是很完美。所以这里就要说到另一个命令 EVALSHA 了，原生语法如下：

EVALSHA sha1 numkeys key [key ...] arg [arg ...]

​ 可以看到其语法与 EVAL 类似，不同的是这里传入的不是脚本字符串，而是一个加密串 sha1。这个 sha1 是从哪来的呢？它是通过另一个命令 SCRIPT LOAD 返回的，该命令是预加载脚本用的，语法为：

SCRIPT LOAD script

​ 这样的话，我们通过预加载命令，将 Lua 脚本先存储在 Redis 中，并返回一个 sha1，下次要执行对应脚本时，只需要传入 sha1 即可执行对应的脚本。这完美地解决了 EVAL 命令存在的弊端，所以我们这里也是基于 EVALSHA 方式来实现的。既然有了思路，也有了方案，那我们开始用代码实现它吧。首先我们根据以上介绍的库存扣减核心操作，完成核心 Lua 脚本的编写。其主要实现的功能就是查询库存并判断库存是否充足，如果充足，则做相应的扣减操作，脚本内容如下：

-- 调用Redis的get指令，查询活动库存，其中KEYS[1]为传入的参数1，即库存key
local c_s = redis.call('get', KEYS[1])
-- 判断活动库存是否充足，其中KEYS[2]为传入的参数2，即当前抢购数量
if not c_s or tonumber(c_s) < tonumber(KEYS[2]) then
   return 0
end
-- 如果活动库存充足，则进行扣减操作。其中KEYS[2]为传入的参数2，即当前抢购数量
redis.call('decrby',KEYS[1], KEYS[2])

然后我们将 Lua 脚本转成字符串，并添加脚本预加载机制。

​ 预加载可以有多种实现方式，一个是外部预加载好，生成了 sha1 然后配置到配置中心，这样 Java 代码从配置中心拉取最新 sha1 即可。另一种方式是在服务启动时，来完成脚本的预加载，并生成单机全局变量 sha1。我们这里先采取第二种方式，代码结构如下图所示：

以上是将 Lua 脚本转成字符串形式，并通过 @PostConstruct 完成脚本的预加载。然后新增 EVALSHA 方法，如下图所示：

方法入参为活动商品库存 key 以及单次抢购数量，并在内部调用 Lua 脚本执行库存扣减操作。看起来是不是很简单？在写完底层核心方法之后，我们只需要在下单之前，调用该方法即可，具体如下图所示：

三：总结

​ 技术的角度分析了库存超卖发生的两个原因。一个是库存扣减涉及到的两个核心操作，查询和扣减不是原子操作；另一个是高并发引起的请求无序。所以我们的应对方案是利用 Redis 的单线程原理，以及提供的原生 EVALSHA 和 SCRIPT LOAD 命令来实现库存扣减的原子性和顺序性，并且经过实测也确实能达到我们的预期，且性能良好，从而有效地解决了秒杀系统所面临的库存超卖挑战。以后再遇到类似的问题，你也可以用同样的解决思路来应对。

原文 
http://www.cnblogs.com/simple-flw/p/15501704.html