用Redis来护航库存管理，解决那些乱七八糟的库存问题

（引用来源：电商库存管理常见痛点与Redis特性结合的分析）

库存问题，说白了就是怕两件事：一是东西卖完了不知道，结果超卖了，客户下了单发不出货，被骂是小事，平台罚款可是真金白银；二是东西明明还有，系统却显示没货了，白白损失订单，尤其是在做活动的时候，比如双十一、618，一秒进来几万人，传统的办法，比如把库存数量存在数据库里，每次卖一个就去数据库里减一，这种方法根本扛不住，数据库读写慢，一下子就被冲垮了，库存数字很容易就错乱了,变成一笔糊涂账。

这时候，Redis就能派上大用场了，你可以把Redis想象成一个放在最前面的、速度超级快的临时小本本，它不像数据库那样要把数据写在硬盘上，所有数据都放在内存里，所以读写的速度极快，每秒处理几十万次请求跟玩似的，用它来管库存，特别是管那个最关键的“可卖库存”数量,再合适不过了。

具体怎么用呢？最核心的一招就是“预扣库存”。（引用来源：Redis在秒杀场景中的典型应用方案）

在活动开始前，我们提前把每种商品的真实库存数量，比如100件，同步到Redis里，用一个简单的键值对存起来，key就是商品ID，value就是库存数量100，当海量用户同时点击“立即购买”时，系统不是直接去碰后面那个又大又慢的数据库,而是先来问Redis。

每一个请求过来，系统都执行一个非常关键的操作：递减，Redis里有一个命令，可以保证在一个瞬间，只有一个请求能成功地把库存数从100减到99，这个操作是原子性的，意思是这个“检查库存是否大于0”和“减1”的动作是打包在一起、不可分割的，绝对不会出现两个人同时看到库存是100，然后都减1，结果变成99这种混乱情况,这就从根儿上杜绝了超卖。

如果递减成功了，说明这个用户抢到了购买资格，这时候，Redis里的可卖库存变成了99，系统就可以给用户生成订单，进入付款流程，这个订单信息可以先异步地、慢慢地存到数据库里,压力就小多了。

如果递减失败了，比如库存已经是0了，Redis会直接返回失败，系统立刻告诉用户“商品已售罄”，用户体验也好,系统也不用再白费力气去处理后续流程了。

你看，这样一来，所有的核心判断都在速度飞快的Redis上完成了，数据库的压力大大减轻，超卖的问题也解决了,这就是用Redis给库存管理上的第一道保险。

但光有这一道保险还不够，因为用户可能会下单但不付款，或者干脆取消了订单，这些被预扣掉的库存不能一直占着茅坑不拉屎，得想办法释放出来，不然就是浪费。（引用来源：基于Redis实现库存预扣与回滚的常见设计）

我们需要一个“回收”机制，通常的做法是给每个预扣的库存设置一个“有效期”，用户下单后15分钟内如果没付款，这个订单就自动关闭，系统要监听这些超时关闭的订单事件，一旦发生，就再向Redis发一个指令，把当时扣掉的那件商品库存加回去，这个“加回去”的操作同样需要是原子性的,确保安全。

还有一种情况是用户主动取消订单，处理方式也是一样的，就是把库存加回Redis，这样，就能最大限度地利用库存,减少有货卖不掉的损失。

除了防止超卖和库存回收，Redis还能帮我们应对另一种尴尬：防止重复下单，有时候网络卡顿，用户可能连续点击了好几下“提交订单”，如果没有防护，可能会生成好几个一模一样的订单，我们可以在用户点击下单时，用Redis记录一个标记，用户A_正在处理商品B的订单”，设置一个很短的过期时间（比如5秒），如果同一个用户对同一商品的第二个请求过来，发现这个标记还存在，就直接拒绝，提示“操作过于频繁，请勿重复提交”,这就避免了库存被同一个用户重复扣减的问题。

Redis也不是万能的，它毕竟是个内存数据库，万一服务器重启，数据可能会丢失（虽然有一些持久化机制，但通常不会为了库存数据配置成最高级别，以免影响速度），它最适合用来管理那个瞬息万变的“可售库存”，而商品的总库存、已经实际卖出去的数量（财务上需要确切的数字），这些最终还是要落地到传统的关系型数据库里，确保数据的安全和持久，Redis和数据库需要配合着用，一个管前台的风风火火，一个管后台的稳稳当当，定期（比如每秒或每分钟）把Redis里的库存变化同步到数据库,保证两边数据大体一致就行了。

用Redis来护航库存管理，就像是给系统请了一个反应神速的前台调度员，它用“原子递减”防超卖，用“过期回滚”防死锁，用“临时标记”防重复，把那些在高并发下最容易出现的“乱七八糟”的库存问题，从源头就梳理得清清楚楚，虽然背后还需要数据库来做最终的数据保障，但有了Redis在前面挡着，库存系统在面对流量高峰时,心里就真的有底了。