秒杀系统的一点思考

17348人阅读 评论(7) 收藏 举报
分类:

秒杀系统难点往往是短时间内对数据进行读写,然后造成读写上的一些冲突,甚至锁非常严重.当然知道难点在哪里,我们自然就有办法解决,人类智慧无限,办法总比困难多. 简单说来也就两点,限流和提升关键点的性能.

 

(1)限流,将请求尽量拦截在系统上游,流量层层过滤,当请求到达稀缺资源比如数据库的时候,流量变小,数据库的压力已经可以忽略.传统秒杀系统之所以挂,请求都压倒了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,流量虽大,下单成功的有效流量甚小。

(2)提升关键点的性能,充分利用缓存便是一个不错的提升性能的方式.因为数据库的性能提升往往比较困难,而人们换个思考问题的方式, 既然数据库性能提升不容易,那换一个性能高的数据存储的地方总可以,缓存便是这种思路下产生的,缓存数据存放在内存中,处理的速度远大于数据库,这样便换角度的提升了数据访问的性能

 

常见的站点架构基本是这样的,这个图主要展示为了能够架构秒杀系统所需要改变的点.


浏览器端,最上层,会执行到一些JS代码,这个地方往往进行第一次流量过滤,主要是过滤重复提交的数据

代理,再一次对流量进行过滤

网站,这一层会访问后端数据,拼html页面返回给浏览器,这里再次对流量进行过滤

服务层,向上游屏蔽底层数据细节,提供数据访问

数据层,最终的库存是存在这里的,缓存也是使用在这里,传统的是使用数据库

 

各层次优化细节

客户端怎么优化(浏览器层,APP层)

  • 设计:用户点击一次提交以后不再允许能够提交,比如将按钮置灰.
  • 技术:可以使用js限制用户点击,提交的次数,例如一分钟之内只能点击一次.

这样在最上层,通过设计与技术手段就能够阻拦80%以上的流量,虽然如何但剩余的流量依然很大.所以还需要继续阻击.

 

代理层面的请求拦截

这里我们为了分担后端服务器压力,往往使用反向代理服务器,例如nginx, 这个地方可以配置nginx限流措施,比如单位时间只能有5万的访问量,这个时候再一次的阻拦了一部分流量.

 

站点层面的请求拦截

在站点层面,对用户id(当然需要登录)进行请求计数和去重。一个用户id,单位时间内(比如5)只准透过1个请求,这样又能拦住一大部分的请求。只透过一个请求,其余的请求怎么办?缓存,页面缓存,同一个用户id,限制访问频度,做页面缓存,单位时间内到达站点层的请求,均返回同一页面。同一个item的查询。 

 

服务层来拦截

对于写请求,做请求队列,每次只透有限的写请求去数据层 

对于读请求,用缓存,不管是memcached还是redis,单机抗个每秒10w应该都是没什么问题的。如此限流,只有非常少的写请求,和非常少的读缓存mis的请求会透到数据层去,又有99.9%的请求被拦住了。

 

数据库层

当数据经过层层阻击到达数据层的时候,流量已经过滤掉了绝大部分,服务层又做了写请求队列与数据缓存,每次透到数据库层的请求都是可控的。db基本就没什么压力了,闲庭信步,单机也能扛得住. 

 

总结

秒杀系统是对单个请求的无限放大,解决方式总结一句话,限流与增加性能.

13
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:759400次
    • 积分:14555
    • 等级:
    • 排名:第843名
    • 原创:231篇
    • 转载:14篇
    • 译文:6篇
    • 评论:2482条
    欢迎联系我
    Email: bemavery@163.com
    文章分类
    最新评论