前面我们介绍的秒杀系统系列主要是基础实战部分,但是对于一些细节方面的话,我们在后面的文章中来挨个梳理下。本文我们主要梳理的是库存热点散列的问题。
我们先构建一个场景:
电商搞或者,很多商品进行秒杀,对于同一个商品秒杀的话,我们在查询库存的时候是否都需要去数据库进行查询呢?
像上面的场景,我们在抢购的时候,会涉及到对同一个商品每秒成百上千次的库存查询,此时由于有很多产品参与秒杀,所以每秒钟对数据库的查询能达到上千,上万次,如果没有强大的技术实力保障的话,这样的系统,数据库很容易就会崩坏了。上面的问题其实就是库存热点的问题。
既然成为了热点,那么我们如果把热点分散呢?
此时网上大多的方案都是依靠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查询/扣减库存。
大家看懂了吧。
以上就是关于秒杀系统中对于商品库存散列的操作方案。
还没有评论,来说两句吧...