下面用电商库存为示例，来解释如何高并发扣减库存，事理同样适用于其他须要并发写和数据同等性的场景。
库存数量模型示例为了描述方便，我们利用简化的库存数量模型，真实场景中库存数据项会比我的示例多很多，但已经够解释事理。如下表，库存数量表(stockNum)包含商品标识和库存数量两个字段，库存数量代表有多少货可以卖。
字段名
英文名
字段类型
商品标识
skuId
长整型
库存数量
num
整数
传统通过数据库担保不超卖库存管理的传统方案为了担保不超卖，都是利用数据库的事务来担保的：通过Sql判断剩余的库存数够用，多个并发实行update语句只有一个能实行成功；为了担保扣减不重复，汇合营一个防重表来防止重复的提交，做到幂等性，防重表示例（antiRe）设计如下：
字段名
英文名
字段类型
标识
id
长整型
防重码
code
字符串（唯一索引）
比如一个下单过程的扣减过程示例如下：
事务开始Insert into antiRe(code) value (‘订单号+Sku’)Update stockNum set num=num-下单数量 where skuId=商品ID and num-下单数量>0事务结束复制代码
面临系统流量越来越大，数据库的性能瓶颈就会暴露出来：就算分库分表也是没用的，匆匆销的时候高并发都是针对少量商品的，终极并发流量会打向少数表，只能去提升单分片的抗量能力。我们接下来设计一种利用Redis缓存做库存扣减的方案。
综合利用数据库和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事务结束复制代码
要点：终极还是要利用数据库，热点怎么办理的呢？任务库利用订单号进行分库分表，这样针对同一个商品的不同订单会散列在任务库的不同库存，虽然还是数据库抗量，但已经肃清了数据库热点。
整体交互序列图如下：
热点防刷
但Redis也是有瓶颈的，如果涌现过热SKU就会打向Redis单片，会造成单片性能抖动。库存防刷有个条件是不能卡单的。可以定制设计JVM内毫秒级韶光窗的限流，限流的目的是保护Redis,尽可能的不限流。限流的极度情形便是商品本来该当在一秒内卖完，但实际花了两秒，正常并不会发生延迟发卖，之以是选择JVM是由于如果采取远端集中缓存限流，还未来得及网络数据就已经把Redis打去世。
实现方案可以通过guava之类的框架，每10ms一个韶光窗，每个韶光窗进行计数，单台做事器超过计数进行限流。比如10ms超过2个就限流，那么一秒一台做事器便是200个，50台做事器一秒就可以卖出1万个货，自己根据实际情形调度阈值就可以。
Redis扣减事理
Redis的incrby 命令可以用做库存扣减，扣减项可能多个，我们利用Hash构造的hincrby命令，先用Reids原生命令仿照全体过程，为了简化模型我们演示一个数据项的操作，多个数据项事理完备等同。
127.0.0.1:6379> hset iphone inStock 1 #设置苹果手机有一个可售库存(integer) 1127.0.0.1:6379> hget iphone inStock #查看苹果手机可售库存为1"1"127.0.0.1:6379> hincrby iphone inStock -1 #卖出扣减一个，返回剩余0，下单成功(integer) 0127.0.0.1:6379> hget iphone inStock #验证剩余0"0"127.0.0.1:6379> hincrby iphone inStock -1 #运用并发超卖但Redis单线程返回剩余-1，下单失落败(integer) -1127.0.0.1:6379> hincrby iphone inStock 1 #识别-1，回滚库存加一，剩余0(integer) 0127.0.0.1:6379> hget iphone inStock #库存规复正常"0"复制代码扣减的幂等性担保
如果运用调用Redis扣减后，不知道是否成功，可以针对批量扣减命令增加一个防重码，对防重码实行setnx命令，当发生非常的时候，可以根据防重码是否存在来决定是否扣减成功，针对批量命名可以利用pipeline提高成功率。
// 初始化库存127.0.0.1:6379> hset iphone inStock 1 #设置苹果手机有一个可售库存(integer) 1127.0.0.1:6379> hget iphone inStock #查看苹果手机可售库存为1"1"// 运用线程一扣减库存，订单号a100，jedis开启pipeline127.0.0.1:6379> set a100_iphone "1" NX EX 10 #通过订单号和商品防重码OK127.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)复制代码单向担保
在很多场景中，由于没有利用事务，你很那做到不超卖，并且不少卖，以是在极度情形下，我的决议是选择不超卖，但有可能少卖。当然还是该当只管即便担保数据准确，不超卖，也不少卖；不能完备担保的条件下，选择不超卖单向担保，也要通过手段来尽可能减少少卖的概率。
比如如果扣减Redis过程中，命令编排是先设置防重码，再实行扣减命令失落败；如果实行过程网络抖动可能放重码成功，而扣减失落败，重试的时候就会认为已经成功，造成超卖，以是上面的命令顺序是缺点的，精确写法该当是：
如果是扣减库存，顺序为：1.扣减库存 2.写入放重码。
如果是回滚库存，顺序为 1.写入放重码 2.扣减库存。
为什么利用PiPeline在上面命令中，我们利用了Redis的Pipeline，来看下Pipeline的事理。
非pipeline模式 request-->实行 -->response request-->实行 -->response pipeline模式 request-->实行 server将相应结果行列步队化 request-->实行 server将相应结果行列步队化 -->response -->response
利用Pipeline,能只管即便担保多条命令返回结果的完全性，读者可以考虑利用Redis事务来代替Pipeline，实际项目中，个人有过Pipeline的成功抗量履历，并没有利用Redis事务，正常情形下事务比pipeline慢一些，以是没有采取。
Redis事务 1）mutil:开缘由务，此后的所有操作将被添加到当前链接事务的“操作行列步队”中 2）exec:提交事务 3）discard:取消行列步队实行 4）watch:如果watch的key被修正，触发dicard。
通过任务引擎实现数据库的终极同等性前面通过任务引擎来担保数据一定持久化数据库，「任务引擎」的设计如下，我们把任务调度抽象为业务无关的框架。「任务引擎」可以支持大略的流程编排，并担保至少成功一次。「任务引擎」也可以作为状态机的引擎涌现，支持状态机的调度，以是「任务引擎」也可以称为「状态机引擎」，在此文是同一个观点。
任务引擎设计核心事理：先把任务落库，通过数据库事务担保子任务拆分和父任务完成的事务同等性。
任务库分库分表：任务库利用分库分表，可以支撑水平扩展，通过设计分库字段和业务库字段不同，无数据热点。
任务引擎的核心处理流程：第一步：同步调用提交任务，先把任务持久化到数据库，状态为「锁定处理」，担保这件事一定得到处理。
注：原来的最初版本，任务落库是待处理，然后由扫描Worker进行扫描，为了防止并发重复处理，扫描后进行单个任务锁定，锁定成功再进行处理。后来优化为落库任务直接标识状态为「锁定处理」，是为了性能考虑，省去重新扫描再抢占任务，在进程内直接通过线程异步处理。
锁定Sql参考：
UPDATE 任务表_分表号 SET 状态 = 100,modifyTime = now() WHERE id = #{id} AND 状态 = 0复制代码
第二步：异步线程调用外部处理过程，调用外部处理完成后，吸收返回子任务列表。通过数据库事务把父任务状态设置为已经完成，子任务落库。并把子任务加入线程池。
要点：担保子任务天生和父任务完成的事务性
第三步：子任务调度实行，并重新把新子任务落库，如果没有子任务返回，则全体流程结束。
非常处理Worker
非常解锁Worker来把永劫光未处理完成的任务解锁，防止由于做事看重启，或线程池满造成的任务一贯锁定无做事器实行。
补漏Worker防止做事看重启造成的线程池任务未实行完成，补漏程序重新锁定，触发实行。
任务状态转换过程
任务引擎数据库设计
任务表数据库构造设计示例（仅做示例利用，真实利用须要完善）
字段
类型
解释
任务ID标识
Long
主键
状态
Int
0待处理，100锁定处理，1完成
数据
String
Json格式的业务数据
实行韶光
Date
实行韶光
任务引擎数据库容灾：
任务库利用分库分表，当一个库宕机，可以把路由到宕机库的流量重新散列到其他存活库中，可以手工配置，或通过系统监控来自动化容灾。如下图，当任务库2宕机后，可以通过修正配置，把任务库2流量路由到任务库1和3。补漏引擎连续扫描任务库2是由于当任务库2通过主从容灾规复后，任务库2宕机时未来的及处理的任务可以得到补充处理。
任务引擎调度举例
比如用户购买了两个手机和一个电脑，手机和电脑分散在两个数据库，通过任务引擎先持久化任务，然后驱动拆分为两个子任务，并终极担保两个子任务一定成功，实现数据的终极同等性。全体实行过程的任务编排如下：
任务引擎交互流程：
差异比拟-异构数据的终极办理方案
只要有异构，一定会有差异的，为了担保差异的影响可控，终极方案还是要靠差异比拟来办理。本文篇幅所限，不再展开，后续再单独成文。DB和Redis差异比拟的大概过程为：吸收库存变革，不断跟进比拟Redis和DB的数据是否同等，如果连续稳定不一致，则进行数据修复，用DB数据来修正Redis的数据。
