秒杀系统设计
可参考技术文档:
压力挑战:
短暂的高流量,对现有网站业务造成冲击
秒杀是一个网站营销的一个附加活动,时间短,并发量大。
如果和网站原有应用部署在一起,必然会对现有业务造成冲击,稍有不慎可能导致整个网站瘫痪。
高并发,数据库高负载
用户秒杀开始前,通过不断刷新浏览器来保证不会错过秒杀活动。
频繁的访问程序、数据库会对应用服务器和数据库服务器造成负载压力
网络及服务器带宽增长压力,网络带宽的问题比超过平时好多倍
如果秒杀页面的大小为200K,如果最大并发数为10000次,那么需要的网络和服务器带宽是2G(200K×10000)。
这些网络带宽是因为秒杀活动新增的,超过网站平时使用的带宽
业务逻辑的简化
避免直接下单
秒杀的游戏规则是到了秒杀才能开始对商品下单购买,在此时间点之前,只能浏览信息不可下单。
而下单页面也是一个普通的URL,如果得到这个URL,不用等到秒杀开始就可以下单了
解决策略:
1.公平保证:
秒杀用户筛选策略:一般是先到先得,10个商品放100个人进来
防秒杀器和机器人:验证码等手段
2.系统压力:
秒杀系统独立部署,避免对主站造成压力和堵死
如果需要还可以使用独立域名,使其与网站完全隔离,即使秒杀系统崩溃了,也不会对网站造成影响
秒杀商品页面静态化和缓存化,减少后端请求
将商品描述、参数、详情,全部写到一个静态页面,不用进行程序的逻辑处理,不需访问数据库,不用部署动态的服务器和数据库服务器
租借秒杀活动网络带宽
为了减轻服务器的压力,需要将秒杀商品页面缓存在CDN,同样CDN服务器也需要临时租借带宽
动态生成随机下单页面的URL
为了避免用户直接访问下单URL,需要将URL动态化,用随机数作为参数,只能秒杀开始的时候才生成
关键点
业务拆分,独立并发访问
高并发控制,请求量拦截。
读写分离(查询库存和下订单拆分独立)
请求队列控制接受数,从而控制并发量
订单和支付的一致性
3.系统层级的划分: 前端 -> web层 -> 业务服务 -> DB持久层
前端
A:扩容,加机器,这是最简单的方法,通过增加前端池的整体承载量来抗峰值。
B:静态化,将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素。通过CDN来抗峰值。
C:限流一般都会采用IP级别的限流,即针对某一个IP,限制单位时间内发起请求数量。
web层
A: 集群负载均衡,节点能线性扩展。
B:采用短连接,连接池。
业务服务
A:查询模块(查询库存)并发查询,库存数存在缓存中,(商品信息和图片信息等等)静态化处理和库存剩余数量缓存化处理。
B: 下订单模块(秒杀关键部分),队列控制异步化处理,首先判断这个队列是否已满, 如果没满就将请求放入队列中排队,队列满以后的所有请求直接返回秒杀失败。
C: 支付模块,异步付款,等待付款成功结果。(付款成功更新库存,也可下单的时候扣库存)。
DB持久层
A: 各个系统的业务数据分库存储,主从读写分离,单个子系统的数据,可以通过分库/分表的方法。
B: 构建合理数据库索引,如对购买记录添加唯一索引,数据更新检测库存,如update number set x=x-1 where (x -1 ) >= 0。
4.监控系统
A: 操作系统的cpu, memory,i/o 。
B: 各个系统的log:访问次数,warning, error log的条数。
C: dba对数据库的监控。
D: 业务层面的监控:每分钟各个子系统的交易量(DB查询)。
E: 核心路径监控,非常重要的部分,单笔请求在交易系统中的流程,一笔实时交易,从接收到http请求,到各个子系统之间的互相访问,到DB的读写,到返回抢购结果
相关推荐
yaodilu 2020-05-10
SXIAOYI 2020-09-16
有心就有方向 2012-09-03
zfyaixue 2013-06-14
pigsmall 2020-11-19
Ladyseven 2020-07-25
whileinsist 2020-06-24
gufudhn 2020-06-12
冰蝶 2020-06-05
LinuxAndroidAI 2020-06-04
supperme 2020-05-28
e度空间 2020-04-27
云端漂移 2020-04-09
peterwzc 2020-03-17
ebuild 2013-05-14
donghedonghe 2013-05-31
tdeclipse 2011-02-28
linuxprobe0 2013-04-15