大家好，我是冰河~~
置信很多小同伴都在大厂的秒杀大促中抢购过商品，那大家有没有想过这样一个疑问：在秒杀这种高并发大流量的场景下，商品的库存是如何设计呢？怎样才干抗住刹时高并发的流量呢？
也有不少小同伴进来面试时，简历上写了秒杀系统，此时面试官通常也会问这样一个疑问：你们的秒杀系统库存是怎样设计的呢？要知道，秒杀系统的库存假设只是繁难的依照普通商品的库存启动设计，是基本撑不住刹时的高并发流量的。
一、前言
对秒杀系统数据库的读写操作启动优化，并不是繁难的启动主从复制和分库分表。而是须要从秒杀特有的刹时高并发、大流量的业务场景登程，针对场景启动数据库优化。
关于秒杀这种场景来说，关键是要撑持刹时的高并发、大流量，少量用户抢购商品下单时，会频繁调用查问和升级商品库存的接口，所以，关于商品库存来说，咱们须要增强数据库的读写性能。
在详细设计上，就是要对商品的库存启动分库分表和分桶设计，使得商品的库存不再由复数据库启动存储，裁减成多台数据库，并且在每个数据库中，又对商品的库存启动分桶设计。同时，在缓存层面，也须要对商品的库存启动分桶设计
二、库存优化目的
在正式对商品库存启动分库分表和分桶设计之前，咱们先来确定下库存优化的目的，也就是分库分表和分桶设计的目的，这样在后续的成功中更有针对性。这里，我关键把库存优化的目的分红了六点：分库设计、分表设计、分桶设计、缓存设计、分歧性设计和兼容性设计，如下图所示。
三、分库分表设计
在分库分表的设计上，这里咱们经常使用了三个库成功（实践场景可以依据详细须要灵敏性能分库和分表的数量），自动一个商品库和两个库存库，将商品的库存信息从商品表中独立进去，独自启动分库分表和分桶设计。
这里须要留意的是：在咱们成功的秒杀系统中，经常使用了一个商品库和两个库存库来成功商品库存的分库分表和分桶设计，在实践场景下，大家可以依据实践的业务须要，灵敏性能分库、分表和分桶的数量。
对商品库存启动分库分表设计时，一个很关键的设计就是对分片键的设计。所谓的分片键就是指定一个字段，经过这个字段将数据路由到对应的数据库和数据表中。在秒杀系统分片键的设计上，尽量将同一个用户的同一次性事务中的关系操作路由到同一个数据库中，降落跨库操作的事务老本。
关于商品库存启动分库分表之后的示用意如下图所示。
可以看到，关于商品商品库存来说，分库分表后，会分红一个商品库和两个库存库，其中商品库中寄存的是秒杀商品信息，关键在用户抢购下单的业务场景中，以读操作为主。
库存库中则寄存的是库存分桶数据，每个库存库中寄存了三个分桶后的库存信息。这些分库分表的数据，大家可以依据实践须要灵敏调整。
关于商品库存的分库分表来说，在实践场景下，可以依据商品id启动分片。也就是说，这里咱们选用的分片键是商品的id，同一个商品的库存会被路由到同一个数据库中，不会出现跨数据库的操作。
四、库存分桶设计
在分库分表的基础上，为了进一步优化数据库的并发写性能，可以对商品的库存启动分桶存储。当运营人员在性能库存信息时，可以设置库存的总量和分桶数量，比如，要将1500个商品调配到5个分桶中，则每个分桶中会分得300个商品库存，如下图所示。
这样，每个分桶就能够承当一局部写压力，从而将商品的库存写压力分担进来，使得秒杀系统的库存数据库能够具有更高的并发写才干。
当用户抢购下单时，会依据分桶的数量对用户的id启动取模来定位对应的库存分桶，比如用户的id为10001，目前库存的分桶数量设置为5，则用户抢购下单时，会将用户抢购下单时，扣减商品库存的恳求路由到分桶1，如下图所示。
用户id为10002的用户抢购下单时，扣减商品库存的恳求会被路由到分桶2，如下图所示。
可以看到，用户抢购下单时，扣减商品库存的恳求会被路由到不同的分桶中，这样就可以大大降落扣减商品库存的并发写抵触疑问，优化扣减商品库存的并发写性能。
这里，还有一个疑问就是对商品的库存启动分桶设计后，每个分桶中保留的是商品的一局部库存信息，那如何确定商品的总库存呢？其实有两种打算和处置这个疑问。
思索到对商品库存的并发写操作，以及后续运营人员或许要调整商品的库存信息，这里咱们驳回的是打算三，也就是在商品数据表中存储商品总库存和分桶数量，每个分桶中存储分桶的商品总库存和可用库存。如下图所示。
运营人员在设置商品库存时，将商品的总库存和分桶数量存储到商品库，每个分桶中存储分桶的总库存和可用库存。
五、分桶库存扣减战略
咱们对库存启动分库分表和分桶设计后，在实践场景中，大局部状况下都是路由到不同库存分桶的流量是存在差异的，这就会造成不同库存分桶中的库存残余量有所不同，比如，id为10001的用户抢购下单时，会被路由到分桶1，id为10002的用户抢购下单时，会被路由到分桶2。
有或许存在的一种状况是：此时分桶1中没有库存了，分桶2中有库存，那关于id为10001的用户来说，该怎样处置呢？此时，咱们可以思索三种打算：
打算1： 设计库存分桶的“争抢”机制，相似Java中的Fork/Join框架，假设分桶中的库存无余，则依照必定的规定“争抢”其余分桶中的库存。
打算2： 每个分桶中预留一些冗余的库存，某个分桶库存无余，向其余分桶借用。
打算3： 路由到不同库存分桶的用户看到的残余库存量不同，假设某个分桶的库存无余，间接向路由到该分桶的用户揭示库存无余。
这三种打算各无利害，经过对秒杀这种场景的掂量，咱们最终驳回的是打算3。要知道，在秒杀绝大局部场景下，都是少量的用户去抢购有限数量的商品，大局部状况下，一切分桶的库存会被瞬间抢购一空。
那有没有一些极其状况，某些分桶中的库存不可售罄呢？这种状况不能说没有，有或许会出现，然而概率极低。
假设确实存在某些分桶中的库存不可售罄的状况，则可以经过人工干预的模式收缩库存分桶，将没有售罄的分桶库存收缩到一个分桶中，这样将相当于库存没有分桶了，后续一切的恳求都会被路由到同一个库存分桶中，最终库存都会被售罄。
打算1和打算2在成功上比拟复杂，要充沛思索在高并发、大流量场景下如何成功库存的争抢机制，并要思索不能出现库存超卖和少卖的疑问，无疑是在系统的架构设计和成功层面参与了复杂度。
在这种秒杀场景下，大可不用非要成功打算1和打算3，换个角度思索，关于平台和商户来说，保障一切商品都能售罄，并保障数据分歧。关于用户来说，齐全必要保障库存数据的强分歧性，只需保障用户能看到对应分桶中的库存就可以了，齐全没必要保障用户看到库存数据的强分歧性。
六、缓存与分歧性设计
关于商品的库存在数据库层面启动分桶设计是远远不够的，要知道MySQL单行并发写的TPS大略在300~500之间，即使咱们对商品启动了分库分表和分桶设计，假设将秒杀系统扣减库存的流量间接打入数据库，哪怕部署了MySQL集群，预计也很难抗下一切的并发流量。所以，咱们雷同要对商品库存在缓存中启动分桶设计。
商品库存在缓存层面的分桶设计与在数据库层面的分桶设计规定坚持分歧，例如，运营人员要将1500个商品调配到5个分桶中，则每个缓存分桶和数据库分桶中都会分得300个商品库存，如下图所示。
当用户抢购下单时，雷同会依据分桶的数量对用户的id启动取模来定位对应的库存分桶，先预扣缓存分桶中的库存，而后启动下单操作，最后扣减数据库分桶中的库存。
比如用户的id为10001，目前库存的分桶数量设置为5，则用户抢购下单时，会将用户抢购下单时，扣减商品库存的恳求路由到分桶1，如下图所示。
此时，就会将id为10001的用户扣减商品库存的恳求路由到缓存分桶1来预扣商品库存，预扣成功就会构建订复数据并保留，最后扣减数据库分桶1中的库存数据。
假设用户的id为10002，目前库存的分桶数量设置为5，则用户抢购下单时，会将用户抢购下单时，扣减商品库存的恳求路由到分桶2，如下图所示。
此时，就会将id为10001的用户扣减商品库存的恳求路由到缓存分桶2来预扣商品库存，预扣成功就会构建订复数据并保留，最后扣减数据库分桶2中的库存数据。
这里，还有一个疑问就是如何同步缓存中分桶中的库存数据与数据库分桶中的库存数据呢？其实，设计起来也比拟繁难，就是运营人员设置或许调整商品库存和分桶数量时，会将计算进去的商品分桶库存写入数据库，写入成功后，升级缓存中的分桶库存数据即可。
缓存中的商品分桶库存坚持弱分歧性，数据库中的商品分桶库存坚持强分歧性。如下图所示。
当运营人员设置商品库存和分桶数量时，会将商品的总库存和分桶数量存储到商品数据表，每个分桶中存储分桶的总库存和可用库存。
当数据库分桶中的商品库存数据设置成功后，将其同步到缓存中，缓存中的商品分桶库存规定与数据库中的商品分桶库存规定相反。
同时，缓存中的分桶库存数据坚持弱分歧性，数据库中的分桶库存数据坚持强分歧性。
七、重置和调整分桶设计
运营人员不免会调整秒杀商品的库存信息，比如原来的商品库存为1500，起初想调整成1000或许2000，所以，秒杀系统要允许运营人员灵活的调整秒杀商品的库存。
以此对秒杀商品的库存启动实时调整，运营人员调整库存时，会触及到三种状况，区分如下所示。
（1）第一种状况是调整商品库存，然而分桶数量不变，如下图所示。
（2）第二种状况是商品库存不变，调大或许调下分桶数量，如下图所示。
（3）第三种状况是既调整了商品库存，又调整了分桶数量，如下图所示。
其实，这三种状况在秒杀系统的成功中，实质上就是对商品库存和分桶数量的调整，秒杀系统要允许运营实时调整这些战略。
八、总结
本章，关键对商品的库存启动了分库分表和分桶设计。首先，繁难形容了本章的需求。随后，对库存优化的目的启动了论述。紧接着对库存的分库分表和分桶启动了设计和说明。
接上去，对商品库存分库分表和分桶触及到的缓存数据启动了设计，并对缓存数据与数据库数据的分歧性启动了设计。最后，对重置和调整商品库存的分桶数据启动了设计。