秒杀是一个非常典型的活动场景,比如,在双11、618等电商促销活动中,都会有秒杀场景。秒杀场景的业务特点是限时限量,业务系统要处理瞬时的大量高并发请求,而Redis就经常被用来支撑秒杀活动。
不过,秒杀场景包含了多个环节,可以分成秒杀前、秒杀中和秒杀后三个阶段,每个阶段的请求处理需求并不相同,Redis并不能支撑秒杀场景的每一个环节。
那么,Redis具体是在秒杀场景的哪个环节起到支撑作用的呢?又是如何支持的呢?清楚了这个问题,我们才能知道在秒杀场景中,如何使用Redis来支撑高并发压力,并且做好秒杀场景的应对方案。
接下来,我们先来了解下秒杀场景的负载特征。
秒杀场景的负载特征对支撑系统的要求
秒杀活动售卖的商品通常价格非常优惠,会吸引大量用户进行抢购。但是,商品库存量却远远小于购买该商品的用户数,而且会限定用户只能在一定的时间段内购买。这就给秒杀系统带来两个明显的负载特征,相应的,也对支撑系统提出了要求,我们来分析下。
第一个特征是瞬时并发访问量非常高。
一般数据库每秒只能支撑千级别的并发请求,而Redis的并发处理能力(每秒处理请求数)能达到万级别,甚至更高。所以,当有大量并发请求涌入秒杀系统时,我们就需要使用Redis先拦截大部分请求,避免大量请求直接发送给数据库,把数据库压垮。
第二个特征是读多写少,而且读操作是简单的查询操作。
在秒杀场景下,用户需要先查验商品是否还有库存(也就是根据商品ID查询该商品的库存还有多少),只有库存有余量时,秒杀系统才能进行库存扣减和下单操作。
库存查验操作是典型的键值对查询,而Redis对键值对查询的高效支持,正好和这个操作的要求相匹配。
不过,秒杀活动中只有少部分用户能成功下单,所以,商品库存查询操作(读操作)要远多于库存扣减和下单操作(写操作)。
当然,实际秒杀场景通常有多个环节,刚才介绍的用户查验库存只是其中的一个环节。那么,Redis具体可以在整个秒杀场景中哪些环节发挥作用呢?这就要说到秒杀活动的整体流程了,我们来分析下。
Redis可以在秒杀场景的哪些环节发挥作用?
我们一般可以把秒杀活动分成三个阶段。在每一个阶段,Redis所发挥的作用也不一样。
第一阶段是秒杀活动前。
在这个阶段,用户会不断刷新商品详情页,这会导致详情页的瞬时请求量剧增。这个阶段的应对方案,一般是尽量把商品详情页的页面元素静态化,然后使用CDN或是浏览器把这些静态化的元素缓存起来。这样一来,秒杀前的大量请求可以直接由CDN或是浏览器缓存服务&#x