【干货】常见库存设计方案-各种方案对比总有一个适合你

一：背景

        某个票务系统比如12306占座，演出等， 流量最高的业务场景是在查询座位图和锁座环节，新的票务系统在优化后用了新的扣位占座系统，同时锁座扣位环节用新库存服务支撑，锁座&下单环节分别做预占、扣减库存操作，查询座位图由静态座位图加上实时座位图，静态座位图来自基础数据，实时座位图（预占+已占）来自新库存服务，票务库存与电商库存的区别在于电商库存只要控制加减避免超卖，而票务库存需要精确到座位，关注座位不重卖和少卖。

二：功能

• 查询库存：座位图查询库存
• 预占库存：锁座时预占库存
• 扣减库存：出票时扣减库存
• 释放库存：超时未支付释放&退款时释放库存
• 预留库存：保留座位，预留，或者后边再卖

三：业务流程

• 预占库存时机

       常规电商都是在下单环节预占库存，支付成功后扣减库存，但票务在线选座有个前置环节是选座，所以预占库存可以前置到选座，而不是在下单环节，在支付成功后进行扣减库存操作。

• 恶意预占库存        如果有用户在开始恶意预占大量库存但不下单，导致票导致后续有大量票没有卖出？预占并不是实际扣减，后台系统会自动释放预占超过15分钟的库存，重新放出来售卖，这种在现有电商系统已经很常见了，但用户还是可以重新恶意预占，这种只能通过风控和反作弊行为来限制，具体方式有很多，用户限制，ip限制，手机PIN限制等。

• 预占失败导致查询库存量变大

       在热门场次会出现用户抢座，而抢座失败的用户会高频刷新座位图信息重新选座，导致查询库存的请求量瞬时增加3-5倍。

四： 那么最终系统设计要遵循什么原则？？？

• 容忍动态座位图短暂不一致，接受最终一致性，必须保障高可用；

五 ：具体设计

• 请求量最大的是查询库存，避免查库操作；
• 预占库存需要考虑多并发场景，防止重卖，可以用数据库唯一索引防止重卖。
• 定时释放超时的预占库存，防止少卖；

5.1 方案一

本方案完全基于同步操作

5.1.1 预占库存

• 预占库存不能完全靠mysql索引来防止重卖，需要用redis先做一层防重，这样可以最大保证数据库的请求量等于实际座位数；
• 在redis出问题时导致流量全部击穿到mysql，此时需要在mysql操作上加入流控熔断，宁可部分预占失败，也要保障服务可用；
• 先插入mysql后写入redis，防止写redis成功但插入mysql失败导致少