金融平台高并发场景下的抢购解决方案

抢购——常见于电商网站的商品限量低价销售，限时秒杀等，特点是商品数量有限制，价低于往日正常售价，顾客在抢到库存中的商品后会暂时占有这笔库存，支付完成后库存中才会减1，如果在规定时间内（例如15分钟）没有完成支付，会将库存放回可售库存。

抢购模块因瞬时访问量会比平时高十几倍甚至几十倍，不能让抢购模块的大并发量影响到其他模块，造成整体系统响应缓慢甚至整个系统的崩溃都有可能，所以将抢购模块单独拆分成一个抢购系统已经是必然。

开发之初我们总结了抢购系统所需要解决的几个问题
1.库存的高实时性和一致性，不可超卖或者未卖完即提示已售完
2.大并发下须保证系统在可承受范围内，做好限流措施
3.整体异步化，与订单系统，资产系统的交互中通过中间表、缓存、队列实现数据的异步，减缓对其他系统造成高并发冲击。

流程图：

图片.png

任何系统都有压力临界点，为防止系统崩溃，让系统保持在可接受的压力环境下，我们对抢购系统采取了限流措施 , 通过Guava RateLimiter实现平滑限流
限流伪代码：

//每秒发放10个令牌
final RateLimiter limiter = RateLimiter create(10.0);
ThreadPoolExecutor excutor = new ThreadPoolExecutor(availableProcessors, availableProcessors * 5, 60L,
            TimeUnit.MILLISECONDS, workQueue, new NamedThreadFactory("wallet", false));
void submitOrder(List tasks) {
    for (Runnable task : tasks) {
        limiter.acquire();
        excutor.execute(task);
    }
}

理财产品的抢购与电商类商品库存大致概念一样，在整体的库存控制中（产品额度），产品额度分为总额度（total），冻结额度（freeze），已售额度（sold），整个抢购流程中必然是 total >= freeze + sold的情况，如何有效的控制住高并发下的额度不超卖，额度更新的原子性也是系统关键点之一。实际系统中的可售额度为 total - freeze - sold，具体请看下文。

控制额度单从数据库层面是控制不了，高并发情况下数据库压力增大并且按乐观锁控制额度不能有效的控制住额度，目前我们使用redis 存hash结构来操作额度的增加和扣减。整体流程如下：

情况1. 冻结额度增加
从用户下单时做冻结额度的增加，当发现冻结额度 + 已售额度 > 总额度，返回订单创建失败。

RedisCallback<Object> createCallback = connection -> {
                        connection.multi();
                        connection.hIncrBy((productIdKey,soldKey,0);
                        //增加冻结额度
                        connection.hIncrBy(productIdKey,freezeKey,orderAmount);
                        return connection.exec();
                    };
                    List<Object> list = (List)redisService.excute(createCallback);
                    if (ListUtil.isHave(list)){
                        long soldAmount = (long)list.get(0);
                        long withHoldAmount = (long)list.get(1);
                        if (withHoldAmount+soldAmount > sellAmount){
                            logger.error("额度控制 创建订单 冻结金额+售卖金额大于总发售金额 withHoldAmount={},sellAmount={},productId={}",withHoldAmount,sellAmount,productId);
                            RedisCallback<Object> createFailureCallback = connection -> connection.hIncrBy(productIdKey,(freezeKey,-orderAmount);
                            //额度不足回滚数据。
                            redisService.excute(createFailureCallback);
                            //发布事件，将额度同步到数据库
                            eventBus.postEvent(new SyncAmountDataEvent(productId));
                            throw new ServiceException("额度不足");
                        }
                    }

情况2. 冻结额度释放
定时任务定时跑批查询订单不是已支付且支付开始时间超过最近15分钟的会调用关闭订单方法，关闭订单方法将订单状态修改为已失效，并将redis中的冻结额度-orderAmount释放出可用额度。
connection.hIncrBy(productIdKey,freezeKey,-orderAmount);
情况3. 已售额度增加并释放冻结额度
与情况2一样，在订单支付完成后我们需要将sold + orderAmount ，freeze - orderAmount。

  connection.multi();
       connection.hIncrBy(productIdKey,sold,orderAmount);
       connection.hIncrBy(productIdKey,freezeKey,-orderAmount);
  return connection.exec();

在redis 额度更新的同时会启动异步线程更新mysql的额度表数据。
以上三种情况可让额度在订单的各个状态流转时得到有效的控制。

在高并发情况下，如果将抢购系统的大量请求与其他核心系统同步处理显然是不明智的，将抢购系统单独抽离的一大原因就是为了减缓大请求量对整个系统的冲击，这种情况下我们考虑出了使用临时表记录订单数据，订单创建，更新等都会先将订单信息刷到redis用户订单缓存，保证用户能第一时间看到自己的已抢成功的订单，随后发送mq同步到订单系统中，订单系统在数据落地成功后会再次将库里数据和redis做一次同步。订单缓冲表比较简单，可以只存一个订单json串来实现。

至此抢购系统的大概流程讲解完毕，其中还有一些细节问题需要去处理，比如redis高并发下性能问题，多次交互会浪费网络资源，可以考虑将额度控制的内容改为redis + lua的方式更为高效，同时考虑redis在挂掉时的系统如何运转等情况。