随着电商行业的快速发展，面对庞大的库存数据，我们应如何找到合适的库存管理法，实现数据高并发！

库存管理法：redis缓存

面对库存扣减的场景，我们第一个考虑到是数据一致性问题，因为超卖会对我们的履约和客户信誉造成影响。所以一般情况下，在数据库更新时进行加锁操作，以保证系统不会发生超卖情况。所以更多方案是提高数据库性能方法，比如增加硬件性能，优化乐观锁，提升锁效率，优化SQL性能等。对于一些大型系统，也衍生出一些基于分片的库存方案，通过分库分表增加并发吞吐量。

当然那这样不够，因为MySQL数据库的读写的并发上线能力是有限的，我们还是需要再进一步优化我们的方案。这里就要参考之前我写的那篇文章中的思维导论了，这里常见解决方案就是，引入缓存机制。

如下图所示，我们把读请求进行缓存，每次库存校验时，我们引入redis缓存，读请求通过缓存，增加接口性能，然后库存扣减时，在进行缓存同步。

 

但这种方式存在很大问题： 所有请求都会在这里等待锁，获取锁有去扣减库存。在并发量不高的情况下可以使用，但是一旦并发量大了就会有大量请求阻塞在这里，导致请求超时，进而整个系统雪崩；而且会频繁的去访问数据库，大量占用数据库资源，所以在并发高的情况下这种方式不适用。同时这个方案还会存在mysq和redis的数据同步不一致的情况，导致高并发情况下，出现超卖。

所以这种方案虽然简单，但是无法满足高并发场景，我们必须得pass。

库存管理法：更新MySQL数据

为此，我们可以进行一次优化，通过架构维度进行调整。

在这个方案中，我们将库存操作封装成一个单独模块，这个方案的优化点在于，所有库存的查询和扣减都围绕redis进行。当发生库存扣减操作时，会直接更新redis，同时采用异步流程，更新MySQL数据库。这样以来，我们的性能会比直接访问MySQL数据库高效不少，并发能力会有不少提升。

流程如下：

 

但这个方案依然有缺陷，它的点在于redis的单点性能问题。该方案的最大并发性能取决于redis的单点处理能力。而如果想要进一步提升并发能力，该方案不具备水平扩展能力。那么，这个方案，依然不是我们最优的选择。

库存管理法：大显身手

那么接下来，我们需要考虑的是如何可以实现我们业务系统并发能力的水平扩展能力。当然这里也不是凭空来想，我们可以思考一下，业内成熟的一些公司是如何实现高并发的，对此，结合自身情况，可以通过一些常用的支持大数据分析的软件进行，比如九数云。

总结

通过这次的案例分析，我们可以了解到除了结合实际业务场景，设计系统架构，还可以通过一些数据软件来实现。

上一篇: 1篇文章告诉你存货库存管理与资产管理的不同点，不来看看吗？——九数云BI
下一篇: 库存管理保姆级流程：教会你如何库存管理！——九数云BI