共计 4973 个字符，预计需要花费 13 分钟才能阅读完成。
如果你要开发一个电商库存零碎，最放心的是什么？闭上眼睛想下，当然是高并发和防超卖了！本文给出一个兼顾思考如何高并发和防超卖数据准确性的计划。读者能够间接借鉴本设计，或在此基础上做出更切合应用场景的设计。
背景
在往年的麻利团队建设中，我通过 Suite 执行器实现了一键自动化单元测试。Juint 除了 Suite 执行器还有哪些执行器呢？由此我的 Runner 探索之旅开始了！上面用电商库存为示例，来阐明如何高并发扣减库存，原理同样实用于其余须要并发写和数据一致性的场景。1.1 库存数量模型示例为了形容不便，上面应用简化的库存数量模型，实在场景中库存数据项会比以下示例多很多，但曾经够阐明原理。如下表，库存数量表 (stockNum) 蕴含商品标识和库存数量两个字段，库存数量代表有多少货能够卖。
传统通过数据库保障不超卖库存治理的传统计划为了保障不超卖，都是应用数据库的事务来保障的：通过 Sql 判断残余的库存数够用，多个并发执行 update 语句只有一个能执行胜利；为了保障扣减不反复，会配合一个防重表来避免反复的提交，做到幂等性，防重示意例（antiRe）设计如下：
比方一个下单过程的扣减过程示例如下：
事务开始
Insert into antiRe(code) value (‘订单号 +Sku’)
Update stockNum set num=num- 下单数量 where skuId= 商品 ID and num- 下单数量 >0
事务完结面临零碎流量越来越大，数据库的性能瓶颈就会裸露进去：就算分库分表也是没用的，促销的时候高并发都是针对大量商品的，最终并发流量会打向多数表，只能去晋升单分片的抗量能力，所以接下来设计一种应用 Redis 缓存做库存扣减的计划。
Redis 缓存做库存扣减的计划
2.1 综合应用数据库和 Redis 满足高并发扣减的原理
扣减库存其实蕴含两个过程：第一步是超卖校验，第二步是扣减数据的长久化；在传统数据库扣减中，两步是一起实现的。抗写的实现原理其实是奇妙的利用了拆散的思维，分来到防超卖和数据长久化；首先防超卖是由 Redis 来实现的；通过 Redis 防超卖后，只有落库就能够；落库通过工作引擎，业务数据库应用商品分库分表，工作引擎工作通过单据号分库分表，热点商品的落库会被状态机扩散开，打消热点。整体架构如下：
第一关解决超卖测验：能够把数据放入 Redis 中，每次扣减库存，都对 Redis 中的数据进行 incryby 扣减，如果返回的数量大于 0，阐明库存够，因为 Redis 是单线程，能够信赖返回后果。第一关是 Redis，能够抗高并发，性能 Ok。超卖校验通过后，进入第二关。
第二关解决库存扣减：通过第一关后，第二关不须要再判断数量是否足够，只须要傻瓜扣减库存就行，对数据库执行如下语句, 当然还是须要解决防重幂等的，不须要判断数量是否大于 0 了，扣减 SQL 只有如下写就能够。
事务开始
Insert into antiRe(code) value (‘订单号 +Sku’)
Update stockNum set num=num- 下单数量 where skuId= 商品 ID
事务完结要点：最终还是要应用数据库，热点怎么解决的呢？工作库应用订单号进行分库分表，这样针对同一个商品的不同订单会散列在工作库的不同库存，尽管还是数据库抗量，但曾经打消了数据库热点。
整体交互序列图如下：
2.2 热点防刷
但 Redis 也是有瓶颈的，如果呈现过热 SKU 就会打向 Redis 单片，会造成单片性能抖动。库存防刷有个前提是不能卡单的。能够定制设计 JVM 内毫秒级工夫窗的限流，限流的目标是爱护 Redis, 尽可能的不限流。限流的极其状况就是商品原本应该在一秒内卖完，但理论花了两秒，失常并不会产生提早销售，之所以抉择 JVM 是因为如果采纳远端集中缓存限流，还未来得及收集数据就曾经把 Redis 打死。
实现计划能够通过 guava 之类的框架，每 10ms 一个工夫窗，每个工夫窗进行计数，单台服务器超过计数进行限流。比方 10ms 超过 2 个就限流，那么一秒一台服务器就是 200 个，50 台服务器一秒就能够卖出 1 万个货，本人依据理论状况调整阈值就能够。
2.3 Redis 扣减原理
Redis 的 incrby 命令能够用做库存扣减，扣减项可能多个，应用 Hash 构造的 hincrby 命令，先用 Reids 原生命令模仿整个过程，为了简化模型上面将演示一个数据项的操作，多个数据项原理齐全等同。
127.0.0.1:6379> hset iphone inStock 1 #设置苹果手机有一个可售库存
(integer) 1
127.0.0.1:6379> hget iphone inStock #查看苹果手机可售库存为 1
"1"
127.0.0.1:6379> hincrby iphone inStock -1 #卖出扣减一个，返回残余 0，下单胜利
(integer) 0
127.0.0.1:6379> hget iphone inStock #验证残余 0
"0"
127.0.0.1:6379> hincrby iphone inStock -1 #利用并发超卖但 Redis 单线程返回残余 -1，下单失败
(integer) -1
127.0.0.1:6379> hincrby iphone inStock 1 #辨认 -1，回滚库存加一，残余 0
(integer) 0
127.0.0.1:6379> hget iphone inStock #库存恢复正常
"0"2.3.1 扣减的幂等性保障
如果利用调用 Redis 扣减后，不晓得是否胜利，能够针对批量扣减命令减少一个防重码，对防重码执行 setnx 命令，当产生异样的时候，能够依据防重码是否存在来决定是否扣减胜利，针对批量命名能够应用 pipeline 进步成功率。
// 初始化库存
127.0.0.1:6379> hset iphone inStock 1 #设置苹果手机有一个可售库存
(integer) 1
127.0.0.1:6379> hget iphone inStock #查看苹果手机可售库存为 1
"1"
// 利用线程一扣减库存，订单号 a100，jedis 开启 pipeline
127.0.0.1:6379> set a100_iphone
"1"
NX EX 10 #通过订单号和商品防重码
OK
127.0.0.1:6379> hincrby iphone inStock -1 #卖出扣减一个，返回残余 0，下单胜利
(integer) 0
// 完结 pipeline，执行后果 OK 和 0 会一起返回避免并发扣减后校验：为了避免并发扣减，须要对 Redis 的 hincrby 命令返回值是否为正数，来判断是否产生高并发超卖，如果扣减后的后果为正数，须要反向执行 hincrby，把数据进行加回。
如果调用中产生网络抖动，调用 Redis 超时，利用不晓得操作后果，能够通过 get 命令来查看防重码是否存在来判断是否扣减胜利。
127.0.0.1:6379> get a100_iphone #扣减胜利
"1"
127.0.0.1:6379> get a100_iphone #扣减失败
(nil)2.3.2 单向保障
在很多场景中，因为没有应用事务，你很难做到不超卖，并且不少卖，所以在极其状况下，能够抉择不超卖，但有可能少卖。当然还是应该尽量保证数据精确，不超卖，也不少卖；不能齐全保障的前提下，抉择不超卖单向保障，也要通过伎俩来尽可能减少少卖的概率。
比方如果扣减 Redis 过程中，命令编排是先设置防重码，再执行扣减命令失败；如果执行过程网络抖动可能放重码胜利，而扣减失败，重试的时候就会认为曾经胜利，造成超卖，所以下面的命令程序是谬误的，正确写法应该是：
如果是扣减库存，程序为：1. 扣减库存 2. 写入放重码。
如果是回滚库存，程序为：1. 写入放重码 2. 扣减库存。
2.4 为什么应用 Pipeline
在下面命令中，应用了 Redis 的 Pipeline，来看下 Pipeline 的原理。
非 pipeline 模式
request--> 执行 -->responserequest--> 执行 -->responsepipeline 模式
request--> 执行 server 将响应后果队列化 request--> 执行 server 将响应后果队列化 -->response-->response应用 Pipeline, 能尽量保障多条命令返回后果的完整性，读者能够思考应用 Redis 事务来代替 Pipeline，理论我的项目中，集体有过 Pipeline 的胜利抗量教训，并没有应用 Redis 事务，失常状况下事务比 pipeline 慢一些，所以没有采纳。
Redis 事务
1）mutil: 开启事务，尔后的所有操作将被增加到以后链接事务的“操作队列”中
2）exec: 提交事务
3）discard: 勾销队列执行
4）watch: 如果 watch 的 key 被批改，触发 dicard。
2.5 通过工作引擎实现数据库的最终一致性
后面通过工作引擎来保证数据肯定长久化数据库，「工作引擎」的设计如下，把任务调度形象为业务无关的框架。「工作引擎」能够反对简略的流程编排，并保障至多胜利一次。「工作引擎」也能够作为状态机的引擎呈现，反对状态机的调度，所以「工作引擎」也能够称为「状态机引擎」，在此文是同一个概念。
工作引擎设计外围原理：先把工作落库，通过数据库事务保障子工作拆分和父工作实现的事务一致性。
工作库分库分表：工作库应用分库分表，能够撑持程度扩大，通过设计分库字段和业务库字段不同，无数据热点。
2.5.1 工作引擎的外围解决流程
第一步：同步调用提交工作，先把工作长久化到数据库，状态为「锁定解决」，保障这件事肯定失去解决。
注：原来的最后版本，工作落库是待处理，而后由扫描 Worker 进行扫描，为了避免并发反复解决，扫描后进行单个工作锁定，锁定胜利再进行解决。起初优化为落库工作间接标识状态为「锁定解决」，是为了性能思考，省去从新扫描再抢占工作，在过程内间接通过线程异步解决。锁定 Sql 参考：UPDATE 工作表_分表号 SET 状态 = 100,modifyTime = now() WHERE id = #{id} AND 状态 = 0
第二步：异步线程调用内部处理过程，调用内部解决实现后，接管返回子工作列表。通过数据库事务把父工作状态设置为曾经实现，子工作落库。并把子工作退出线程池。要点：保障子工作生成和父工作实现的事务性
第三步：子任务调度执行，并从新把新子工作落库，如果没有子工作返回，则整个流程完结。异样解决 Worker 异样解锁 Worker 来把长时间未解决实现的工作解锁，避免因为服务器重启，或线程池满造成的工作始终锁定无服务器执行。补漏 Worker 避免服务器重启造成的线程池工作未执行实现，补漏程序从新锁定，触发执行。
工作状态转换过程
2.5.2 工作引擎数据库设计
工作表数据库结构设计示例（仅做示例应用，实在应用须要欠缺）
工作引擎数据库容灾
工作库应用分库分表，当一个库宕机，能够把路由到宕机库的流量从新散列到其余存活库中，能够手工配置，或通过系统监控来自动化容灾。如下图，当工作库 2 宕机后，能够通过批改配置，把工作库 2 流量路由到工作库 1 和 3。补漏引擎持续扫描工作库 2 是因为当工作库 2 通过主从容灾复原后，工作库 2 宕机时将来的及解决的工作能够失去补充解决。
工作引擎调度举例
比方用户购买了两个手机和一个电脑，手机和电脑扩散在两个数据库，通过工作引擎先长久化工作，而后驱动拆分为两个子工作，并最终保障两个子工作肯定胜利，实现数据的最终一致性。整个执行过程的工作编排如下：
图 7 工作引擎调度举例工作引擎交互流程
图 8 工作引擎交互流程
总结
只有有异构，肯定会有差别的，为了保障差别的影响可控，终极计划还是要靠差别比照来解决。本文篇幅所限，不再开展，后续再独自成文。DB 和 Redis 差别比照的大略过程为：接管库存变动音讯，一直跟进比照 Redis 和 DB 的数据是否统一，如果间断稳固不统一，则进行数据修复，用 DB 数据来批改 Redis 的数据。
常见问题答疑
问：第一步超卖校验 Redis 内存扣减，第二步扣减数据的长久化，中间断了怎么办？(例：服务重启)
答：如果是服务重启，会在服务器重启之前进行这台服务器的服务；但此计划并不能保证数据的相对统一，比方扣减 redis 后，应用服务器故障间接死机，这种状况下的解决就须要更简单的计划能力保障实时统一（目前没有采取更简单计划），能够通过另一个计划应用库存数据和用户的订单数据进行数据比对修复，达到最终一致性。
