其实就是个秒拍系统

秒拍系统的核心理念就是

能不动数据库就不动数据库

那么如何在不动数据库的情况下，解决用户高并发的问题呢？ 高并发下，要守住两个底线：

• 库存不能为负
• 下单成功，且付款成功的，一定要购买成功

将秒拍抢购进行进一步的分析：

1. 用户首先获得购买资格（库存足够 + 用户下单）
2. 用户付款，安排发货

其实并发压力就在 1 上，2 无所谓，毕竟付款成功后回调大多数系统都有 retry 机制，问题不大。 至于解决并发压力最好的方式就是让这些变成串行通过，

最简单方式自然是 利用 redis 的原子性来进行操作

方案 1：硬来

redis 记录库存数量，待秒杀开始时，进来的请求进行下单操作，DECR 后的读书如果>=0，则建立订单，注意，这里一定要利用 decr 的原子性，在此判断之前，不要有任何数据库操作，否则数据库会爆

if redis.decr(’SKU_STOCK_GATE‘) >= 0 # 在此之前不要有数据库读写操作
  create_order(current_user, sku) #这里最好是个异步， 否则也可能造成数据库抖动
end

这种最基础的方式有一个麻烦之处，如果有一个买家想一次购买 N 个商品，就比较头疼了，因为我们很可能遇到这样的情况，库存只有 1, 但是此时用户要买 2 个或者更多

如果需求是：如果是多个购买，则允许最小购买数，那就无所谓，系统可以将其转化为单位为 1 的订单，但是大部分是：如果数量不够，就建立订单失败。

因为包含了多个购买，所以就不能用 decr 而是要用 decrby 2 了 此时 SKU_STOCK_GATE 为 1，redis 操作完毕后，GATE 值为 -1 不满足 GATE 条件，不能购买了。 库存不变

但是此时就有个麻烦的地方：
STOCK_GATE 已经小于 0 了，但是真实的库存是 1

此时，如果再有人购买一个库存，也会提示失败了

也就是说，这种方案的弊病就是：

有可能出现 库存还有，但是无法进行购买了

其实我们可以发现，大于 1 的购买，STOCK_GATE 有几种可能

1. 在 STOCK_GATE 操作之前，STOCK_GATE 就已经为负数。这种分俩情况，第一种情况是，前置操作是 单一购买，以及前置操作是大于 1 的购买，用递归的思想，后者一定开始于前置是单一购买或 0 购买，而没人买的话，不存在库存不足的问题，所以 这种问题简化成：前置是单一购买，且操作前 STOCK_GATE 已经为负，这种情况很好理解，就是没库存了，购买失败

2. STOCK_GATE 在操作前后，都为正，所以没啥说的，正常购买

3. STOCK_GATE 在操作钱为 正，操作后为负，这种是库存不够，购买失败，理应回退库存

但是这里就有个问题，因为要拿到 decr 之前的数据，所以要先 get 一下数据，超过 1 次操作 redis 的话， 整个操作就不保证原子性了，当并发高的时候，就会出大问题，例如：

账户 A 和账户 B 请求同时 一起进来

有可能出现这样的情况，假设 key 的值是 0，当 k <0 的时候，跳出判断，否则执行减 1， A 和 B 一起发生 GET 请求，A 先返回 GET 请求，ruby 执行下一句 让 redis 执行 decr - 1，但是正当 ruby 要通知 redis，但 redis 还没执行的时候 B 的 ruby 的 GET 命令先到达了 redis , 此时 redis 也返回 0 于是根据 ruby 的逻辑，B 也会执行 -1

解决这类问题，自然是锁

改进后的方案 2：lock

使锁来保证判断的时候只有单线程，不会出现数据脏读

begin
  block_result = lock_manager.lock!("SKU_LOCK_KEY", 2000) do
    pre_gate_value = redis.get('SKU_STOCK_GATE')
    return false if pre_gate_value <= 0  # 库存没有了

    after_gate_value = redis.decrby(SKU_STOCK_GATE, num
    if after_gate_value >=0 
      return true  #可以购买
    else
      redis.incrby(SKU_STOCK_GATE, num) # 将扣除的加回来
      return false  #
    end  
  end
rescue Redlock::LockError
  # 锁超时， 理论上来说这里只有redis 和最简单的判断操作， 很难超时， 最好接入人工检查
end

通过锁可以解决问题

但是这种方案有没有啥其他的问题呢？

比较麻烦，自己维护锁，万一锁超时，检查起来也很烦躁

于是到了我觉得最简单的方案 3，排队。

方案 3：排队

即当发生抢购的时候，利用 redis，在一定时间内，给每个参加购买的人一个号码即可，之后入队。

因为 push 本身靠的是 redis 来保持原子性，所以无所谓。

之后拿一个进程单独处理这个队列，不符合的就直接 next，因为是独立处理，所以压根不存在并发问题，也就没有锁的概念。

但是这种的缺点也很明显，即订单生成时间与用户无关，只与 进程处理时间有关，但是其实这个时候秒杀用户基本也都在线，就算建立的订单最后他没支付，重新将库存加上即可。