共计 3697 个字符，预计需要花费 10 分钟才能阅读完成。
置信大家从网上学习我的项目大部分人第一个我的项目都是电商，生存中时时刻刻也会用到电商 APP，例如淘宝，京东等。做技术的人都晓得，电商的业务逻辑简略，然而大部分电商都会波及到高并发高可用，对并发和对数据的解决要求是很高的。这里我明天就讲一下高并发状况下是如何扣减库存的？
咱们对扣减库存所须要关注的技术点如下：
以后残余的数量大于等于以后须要扣减的数量，不容许超卖
对于同一个数据的数量存在用户并发扣减，须要保障并发的一致性
须要保障可用性和性能，性能至多是秒级
一次的扣减蕴含多个指标数量
当次扣减有多个数量时，其中一个扣减不胜利即不胜利，须要回滚
必须有扣减能力有偿还
返还的数量必须要加回，不能失落
一次扣减能够有屡次返还
返还须要保障幂等性
第一种计划：纯 MySQL 扣减实现
顾名思义，就是扣减业务齐全依赖 MySQL 等数据库来实现。而不依赖一些其余的中间件或者缓存。纯数据库实现的益处就是逻辑简略，开发以及部署成本低。（实用于中小型电商）。
纯数据库的实现之所以可能满足扣减业务的各项性能要求，次要依赖两点：
基于数据库的乐观锁形式保障并发扣减的强一致性
基于数据库的事务实现批量扣减失败进行回滚
基于上述计划，它蕴含一个扣减服务和一个数量数据库
如果数据量单库压力很大，也能够做主从和分库分表，服务能够做集群等。
一次残缺的流程就是先进行数据校验，在其中做一些参数格局校验，这里做接口开发的时候，要放弃一个准则就是不信赖准则，所有数据都不要置信，都须要做校验判断。其次，还能够进行库存扣减的前置校验。比方以后库存中的库存只有 8 个，而用户要购买 10 个，此时的数据校验中即可前置拦挡，缩小对于数据库的写操作。纯读不会加锁，性能较高，能够采纳此种形式晋升并发量。
update xxx set leavedAmount=leavedAmount-currentAmount where skuid=’xxx’ and leavedAmount>=currentAmount
此 SQL 采纳了相似乐观锁的形式实现了原子性。在 where 前面判断残余数量大于等于须要的数量，能力胜利，否则失败。
扣减实现之后，须要记录流水数据。每一次扣减的时候，都须要内部用户传入一个 uuid 作为流水编号，此编号是全局惟一的。用户在扣减时传入惟一的编号有两个作用：
当用户偿还数量时，须要带回此编码，用来标识此次返还属于历史上的哪次扣减。
进行幂等性管制。当用户调用扣减接口呈现超时时，因为用户不晓得是否胜利，用户能够采纳此编号进行重试或反查。在重试时，应用此编号进行标识防重
当用户只购买某个商品一个的时候，如果校验时残余库存有 8 个，此时校验通过。但在后续的理论扣减时，因为其余用户也在并发的扣减，可能会呈现幻读，此时用户理论去扣减时有余一个，导致失败。这种场景会导致多一次数据库查问，升高整体的扣减性能。这时候能够对 MySQL 架构进行降级
MySQL 架构降级
多一次查问，就会减少数据库的压力，同时对整体性能也有肯定的影响。此外，对外提供的查问库存数量的接口也会对数据库产生压力，同时读的申请要远大于写。
依据业务场景剖析，读库存的申请个别是顾客浏览商品时产生，而调用扣减库存的申请基本上是用户购买时才触发。用户购买申请的业务价值比读申请会更大，因而对于写须要重点保障。针对上述的问题，能够对 MySQL 整体架构进行降级
整体的降级策略采纳读写拆散的形式，另外主从复制间接应用 MySQL 等数据库已有的性能，改变上十分小，只有在扣减服务里配置两个数据源。当客户查问残余库存，扣减服务中的前置校验时，读取从数据库即可。而真正的数据扣减还是应用主数据库。
读写拆散之后，依据二八准则，80% 的均为读流量，主库的压力升高了 80%。但采纳了读写拆散也会导致读取的数据不精确的问题，不过库存数量自身就在实时变动，短暂的差别业务上是能够容忍的，最终的理论扣减会保证数据的准确性。
在下面根底上，还能够降级，减少缓存
纯数据库的计划尽管能够防止超卖和少卖的状况，然而并发量切实很低，性能不是很乐观。所以这里再进行降级
第二种计划：缓存实现扣减
这和后面的扣减库存其实是一样的。然而此时扣减服务依赖的是 Redis 而不是数据库了。
这里针对 Redis 的 hash 构造不反对多个 key 的批量操作问题，咱们能够采纳 Redis+lua 脚本来实现批量扣减单线程申请。
升级成纯 Redis 实现扣减也会有问题
Redis 挂了，如果还没有执行到扣减 Redis 外面库存的操作挂了，只须要返回给客户端失败即可。如果曾经执行到 Redis 扣减库存之后挂了。那这时候就须要有一个对账程序。通过比照 Redis 与数据库中的数据是否统一，并联合扣减服务的日志。java 培训当发现数据不统一同时日志记录扣减失败时，能够将数据库比 Redis 多的库存数据在 Redis 进行加回。
Redis 扣减实现，异步刷新数据库失败了。此时 Redis 外面的数据是准的，数据库的库存是多的。在联合扣减服务的日志确定是 Redis 扣减胜利到但异步记录数据失败后，能够将数据库比 Redis 多的库存数据在数据库中进行扣减。
尽管应用纯 Redis 计划能够进步并发量，然而因为 Redis 不具备事务个性，极其状况下会存在 Redis 的数据无奈回滚，导致呈现少卖的状况。也可能产生异步写库失败，导致多扣的数据再也无奈找回的状况。
第三种计划：数据库 + 缓存
程序写的性能更好
在向磁盘进行数据操作时，向文件开端一直追加写入的性能要远大于随机批改的性能。因为对于传统的机械硬盘来说，每一次的随机更新都须要机械键盘的磁头在硬盘的盘面上进行寻址，再去更新指标数据，这种形式非常耗费性能。而向文件开端追加写入，每一次的写入只须要磁头一次寻址，将磁头定位到文件开端即可，后续的程序写入一直追加即可。
对于固态硬盘来说，尽管防止了磁头挪动，但仍然存在肯定的寻址过程。此外，对文件内容的随机更新和数据库的表更新比拟相似，都存在加锁带来的性能耗费。
数据库同样是插入要比更新的性能好。对于数据库的更新，为了保障对同一条数据并发更新的一致性，会在更新时减少锁，但加锁是非常耗费性能的。此外，对于没有索引的更新条件，要想找到须要更新的那条数据，须要遍历整张表，工夫复杂度为 O(N)。而插入只在开端进行追加，性能十分好。
程序写的架构
通过下面的实践就能够得出一个兼具性能和高牢靠的扣减架构
上述的架构和纯缓存的架构区别在于，写入数据库不是异步写入，而是在扣减的时候同步写入。同步写入数据库应用的是 insert 操作，就是程序写，而不是 update 做数据库数量的批改，所以，性能会更好。
insert 的数据库称为工作库，它只存储每次扣减的原始数据，而不做实在扣减（即不进行 update）。它的表构造大抵如下：
create table task{
id bigint not null comment “ 工作程序编号 ”,
task_id bigint not null
}
工作表里存储的内容格局能够为 JSON、XML 等结构化的数据。以 JSON 为例，数据内容大抵能够如下：
{
“ 扣减号 ”:uuid,
“skuid1″:” 数量 ”,
“skuid2″:” 数量 ”,
“xxxx”:”xxxx”
}
复制代码
这里咱们必定是还有一个记录业务数据的库，这里存储的是真正的扣减名企和 SKU 的汇总数据。对于另一个库外面的数据，只须要通过这个表进行异步同步就好了。
扣减流程
这里 和纯缓存的区别在于减少了事务开启与回滚的步骤，以及同步的数据库写入流程
工作库里存储的是纯文本的 JSON 数据，无奈被间接应用。须要将其中的数据转储至理论的业务库里。业务库里会存储两类数据，一类是每次扣减的流水数据，它与工作表里的数据区别在于它是结构化，而不是 JSON 文本的大字段内容。另外一类是汇总数据，即每一个 SKU 以后总共有多大量，以后还残余多大量（即从工作库同步时须要进行扣减的），表构造大抵如下：
create table 流水表 {
id bigint not null,
uuid bigint not null comment ‘ 扣减编号 ’,
sku_id bigint not null comment ‘ 商品编号 ’,
num int not null comment ‘ 当次扣减的数量 ’
}comment ‘ 扣减流水表 ’
复制代码
商品的实时数据汇总表，构造如下：
create table 汇总表{
id bitint not null,
sku_id unsigned bigint not null comment ‘ 商品编号 ’,
total_num unsigned int not null comment ‘ 总数量 ’,
leaved_num unsigned int not null comment ‘ 以后残余的商品数量 ’
}comment ‘ 记录表 ’
在整体的流程上，还是复用了上一讲纯缓存的架构流程。当新退出一个商品，或者对已有商品进行补货时，对应的新增商品数量都会通过 Binlog 同步至缓存里。在扣减时，仍然以缓存中的数量为准
