“秒杀”是如何实现的?
秒杀系统难做,是因为库存有限,很多人会在集中的时间内读写有限的数据,在短时间内,系统会面临成千上万倍的流量进入。那么如何能做好秒杀系统呢?我认为核心思想有这么两点:
将请求尽量的在上游环节就拦截住(不要轻易到数据库这一级)
充分利用缓存
那么这两点如何实现呢,下面详细说说:
最上层是客户端层,常见的都是浏览器访问。点击一次【秒杀按钮】,然后再点一次【秒杀按钮】,那么是访问了两次后端系统么?如果用户手速快一些的话,或者用第三方插件不停的点击,那么岂不是多出来很多请求。从产品层面,我们会设置点击一次按钮后,将按钮置灰,从技术角度,我们可以通过JS控制几秒内只能提交一次请求。看,这就是“将请求尽量的在上游环节就拦截住”。
当然客户端层做限制,对于在座的程序猿们都是小意思,因为一抓包,请求长什么样子一清二楚,然后写个脚本,循环调用就好了;为了防止这样的情况发生,后端的服务需要做去重的工作。比如按照用户名去重,在N秒内,只允许1个请求访问进来,然后做页面缓存;比如10秒内发送了一万次请求,其中1次请求访问成功并返回了页面,将这个页面进行缓存,剩余9999次请求直接返回这个缓存页面。
再往下走,10秒内一个客户只有一次请求进来,但是如果同时有一百万个客户,那么这10秒内也有有一百万次访问,那么如何应对呢?用【消息队列】,所有的请求过来,都排队吧,每次只让有限的请求去访问数据。
当然访问数据也不是直接去读写数据库,这里还有一层数据缓存,比如可以使用Memcached或者Redis缓存库存剩余,通常在秒杀系统中,这个“库存”可以是粗粒度的,也就是说这个数字可以是不准确的,客户关心的是买到还是买不到,而不会关心剩余数量到底是20件还是10件;数据读操作也可以放在缓存中,再由缓存和数据库做数据同步。
上面几步已经拦截了大多数的请求,到DB这一层的时候,基本上没有什么压力了。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。