前面我们介绍的秒杀系统系列主要是基础实战部分，但是对于一些细节方面的话，我们在后面的文章中来挨个梳理下。本文我们主要梳理的是库存热点散列的问题。
我们先构建一个场景：
电商搞或者，很多商品进行秒杀，对于同一个商品秒杀的话，我们在查询库存的时候是否都需要去数据库进行查询呢？
像上面的场景，我们在抢购的时候，会涉及到对同一个商品每秒成百上千次的库存查询，此时由于有很多产品参与秒杀，所以每秒钟对数据库的查询能达到上千，上万次，如果没有强大的技术实力保障的话，这样的系统，数据库很容易就会崩坏了。上面的问题其实就是库存热点的问题。
既然成为了热点，那么我们如果把热点分散呢？
此时网上大多的方案都是依靠redis来进行操作。不错，解决库存热点的问题就是通过redis进行散列。所以此时的话，我们涉及到的方案主要就是提前把某个商品的库存打散，然后分布在不同的实例里面去，所以整个流程图如下：
这里我们画一个简易的流程图，流程如下：
1、提前把用户的库存分配到多个redis实例里面去 2、现查询redis的实例，看库存是否满足要求。如果不满足，则返回库存不足的错误信息，如果满足，则先在redis减库存，然后到数据库扣减库存（大型秒杀系统减库存细节方面做的会更多，这里暂不做过多介绍）
上诉是我们程序执行流程上的散列。那么对于商品如何进行散列呢？其实也很简单：
假设我们现在有一个productid=1000的商品，库存是100，然后我们的redis分片实例是5个（假设是5个，真实情况会更多，这里主要介绍思路）。那么由于我们的秒杀活动比较激烈，用户太多，所以这里我们可以把productid=1000的商品散列5分，那么也就是：
product:1000:0 ----20 product:1000:1 ----20 product:1000:2 ----20 product:1000:3 ----20 product:1000:4 ----20
此时我们把当前productid=1000的商品分成了5份，每份的库存值是20。然后把当前库存的数据给写到redis不同的分片上去。
接下来开始秒杀，秒杀的话我们如何让用户请求散列到不同的redis分片里面呢？这里其实我们大多采用的策略是根据userid进行取模，也就是userid%5。 如果当前userid去模后的值是0，name我们就去redis里面get prodyct:1000:0查询/扣减库存。
大家看懂了吧。
以上就是关于秒杀系统中对于商品库存散列的操作方案。
还没有评论，来说两句吧...