架构搭建是重点,代码或语言实现较简单。
本篇用python+redis+rabbitmq搭建一个秒杀系统。用flask编写后端,只包含秒杀相关程序,省略具体的业务接口。
项目会持续更新,完整代码见github:https://github.com/Sssmeb/seckilling
(如果觉得有帮助的话可以点个star~~~~ )
篇幅有限,不会介绍redis或rabbitmq的基本操作。如果没学过相关知识的只需先了解以下两点,也可以看懂本架构。
- redis是内存型数据库,读写速度远快于mysql这类磁盘型数据库,常用来作缓存。
- rabbitmq消息队列,可以理解为生产者消费者模型,用队列来存储任务,生产与消费解耦。
前言
在介绍架构之前,我们需要先知道秒杀系统面临的难点是什么。
首先在普通的系统中,最大的瓶颈是在于底层的数据库端。因为底层数据库(比如常见的mysql)是磁盘存储的,所以读写IO较慢,而且连接数有限。
而在秒杀业务场景,最大的特点是瞬时的高并发,即在短时间内会有大量的请求到来。如果让所有请求都打到底层数据库上,很大可能数据库会直接崩掉,即使数据库能承受住大量的连接请求,但大量的请求读写都会导致大量的锁冲突,导致响应速度大大减慢。而响应速度对于用户体验来说,无疑是十分重要的。
所以在这里,需要明确第一个目标:让尽可能少、尽可能有效的请求打到底层数据库。
当我们回头再考虑这个业务场景,其实绝大部分的请求都不应该打到底层数据库。因为一般商品库存可能只有抢购用户数的百分之一,甚至更少。所以我们需要一些机制、策略,提前将无效的请求返回。
而站在整个网站设计的角度,第二个目标:越上层越容易实现,越有效。
这里的层指:
- 页面层
- 网络层
- 应用层
- 服务层
- 数据层
例如在前端页面层,如果不做处理,用户在点击抢购按钮以后,见网页没有响应,可能会再点击3-4次甚至更多,这样可能会导致最终有80%的请求都是重复无效的。但只需要前端在设计时,将点击后的按钮置灰,防止用户多次点击发送请求。即简单又有效。
以下简单指出各层可实施的策略:
- 页面层(简单的实现可以屏蔽 90%的请求)
- 按钮置灰,禁止用户重复提交
- 验证码
- 网络层
- 通过ip限制一定时间内的请求次数
- 应用层
- 一个