你所不知道的库存超限做法

在互联网企业中，限购的做法，多种多样，有的别出心裁，有的因循守旧，但是种种做法皆想达到的目的，无外乎几种，商品卖的完，系统抗的住，库存不超限。虽然短短数语，却有着说不完，道不尽，轻者如释重负，重者涕泪横流的架构体验。 但是，在实际开发过程中，库存超限，作为其中最核心的一员，到底该怎么做，如何做才会是最合适的呢？

今天这篇文章，我将会展示给大家库存限购的五种常见的做法，并对其利弊一一探讨，由于这五种做法，有的在设计之初当做提案被否定掉的，有的在线上跑着，但是在没有任何单元测试和压测情况下，这几种超限控制的做法也许是不符合你的业务的，所以不建议直接用于生产环境。我这里权当是做抛砖引玉，期待大家更好的做法。

工欲善其事必先利其器，在这里，我们将利用一台测试环境的redis服务器当做库存超限控制的主战场，先设置库存量为10进去，然后根据此库存量，一一展开，设置库存代码如下：

   1:  def set_storage():
   2:      conn = redis_conn()
   3:      key = "storage_seckill"
   4:      current_storage = conn.get(key)
   5:      if current_storage == None:
   6:          conn.set(key, 10)

为了方便性，我这里使用了python语言来书写逻辑，但是今天我们只是讲解思想，语言这类的，大家可以自己尝试转一下。

上面就是我们的设置库存到redis中的做法，很简单，就是在redis中设置一个storage_seckill的库存key，然后里面放上库存量10.

 

超限限制做法一：先获取当前库存值进行比对，然后进行扣减操作

   1:  def storage_scenario_one():
   2:      conn = redis_conn()
   3:      key = "storage_seckill"
   4:      current_storage = conn.get(key)
   5:      current_storage_int = int(current_storage)
   6:      if current_storage_int<=0 :
   7:          return 0
   8:      result = conn.decr(key)
   9:      return result

首先，我们拿到当前的库存值，然后看看是否已经扣减到了零，如果扣减到了零，则不继续扣减，直接返回；如果库存还有，则利用decr原子操作进行扣减，同时返回扣减后的库存值。

此种做法在小并发量下访问，问题不大；在对库存量控制不严格的业务中，问题也不大。但是如果并发量比较大一些，同时业务要求严格控制库存，那么此种做法是非常不合适的，原因在于，在高并发情况下，get命令，decr命令，都是分开发给redis的，这样会导致比对的时候，很容易出现限制不住的情况，也就是会造成第六行的比对失效。

设想如下一个场景，AB两个请求进来，A获取的库存值为1，B获取的库存值为1，然后两个请求都被发到redis中进行扣减操作，然后这种场景下，A最后得到的库存值为0；但是B最后得到的库存值为-1，超限。

所以此种场景，由于在高并发下，get和decr操作不是一组原子性操作，会引发超限问题，被直接pass。

 

超限限制做法二：先扣减库存，然后比对，最后根据情况回滚

   1:  def storage_scenario_two():
   2:      conn = redis_conn()
   3: