秒杀火了这么久,不管是不是做电商系统的,多线程,高并发。经常会遇到。但其实,只有用户规模达到一定级别的时候才能实现。见过太多的app,最终没用户而凉凉的。但是为什么还要搞这个?从整体项目设计上来说,前期不设计好整个架构,后期再改造投入的成本是非常大的。而且对于程序员来说,初级到中高级,这也是必备知识。
秒杀的业务逻辑有很多。心爱的显卡上架了,几万人去预约,结果还没开始,就结束了。茅台开始预约了,想给老丈人整一瓶,时间一到,今年又失去了一个孝敬老丈人的机会。罗老师又开直播了要剁手,好吧,我也不隐瞒了,以上的我都没抢到。
首先,从业务场景开始说起。秒杀概况下来就是,时间极短,请求极大。时间极短,指的是秒杀很多都是在特定时间开始抢购,在一瞬间,会有大量用户请求进来。开始设计之前,先搞懂影响秒杀的因素有哪些?
1 网络 分为服务器和客户端。带宽,吞吐量,丢包率,甚至DNS解析能力,也会影响秒杀。
2 CPU 现在都是多线程的CPU,有条件的购买更强的CPU可以处理更多的请求。
3 内存 把数据放在内存中处理,效率会大大提升。
4 I/O 如果请求多时,I/O的使用率在百分百,那I/O就是瓶颈了,更换SSD或者更高读写的硬盘。也可以使用redis或者缓存来降低I/O的读写。
5 代码 设计模式的运用,长时间占用资源,接口的响应时间,异常捕获。
6 数据库 表结构设计是否合理,索引,主键,SQL语句的优化
7 请求 恶意请求,脚本攻击,通过非法手段竞争。
接下来是对应的设计思路。
一 服务器
从服务器的角度来讲,需要提高服务器的配置了。好在现在很多公司对于服务器的预算还是充足的。而且小公司的话,可以采用租用服务器。除此之外,nginx,redis,分布式事务都可以考虑的,实际开发过程中,往往只需要负责软件开发部分就可以了,一句话,服务器性能越强越好。
二 数据库
先从数据库开始说起。数据库表的设计越简单,查询的效率越高。秒杀时,每秒几万甚至更高的请求直接访问数据库,基本上库就会挂掉。那整个程序基本就GG了,这个时候就赶紧准备后事吧,灾难性事故可不只是背个锅这么简单。所以要从以下几个方面来考虑,
第一,在设计表时,表的结构要尽可能的根据业务逻辑来精简。
第二,表的索引一定要建,避免全表索引。
第三,主从配置,实现读写分离,减轻数据库压力。
第四,根据业务逻辑,来确定是否分表分库。还可以使用redis,nginx等一些技术,来达到减轻数据库压力,提高数据库处理能力。
三 前端
对,没错,前端同学说的就是你,不要以为秒杀控制请求就完事了。前端在秒杀中,是直接与用户交互的。是用户体验感最直接的一个环节。常见的优化方法有
第一 资源静态化,商品所用到的图片,等所有可以静态化的东西,完全可以做成静态,在秒杀时,就可以减少请求资源,从而就更快一步。
第二 限流 秒杀没开始前,很多用户都会去重复的尝试去刷新页面,去试着点击按钮请求数据,这种都是无效的请求。所以此时在秒杀未开始前,按钮都是灰色的,这样就避免了这些无意义的请求。再比如现在抢东西动不动就要先预约,不预约的用户不能够抢购,其实也是变相控制请求的一种手段 。
四 后台
第一 对于恶意请求的地址进行过滤和拦截。之前自动抢茅台的脚本,就是模拟用户请求。对于这种同一个IP大量时间请求,明显超过人类极限的,就直接红牌out吧。此外现在稍有点规模的电商,还有风控组存在。监测账号是否是活跃账号,是否多设备登录,等等一系列风控。毕竟秒杀的目的,是把东西卖给合适的用户。
第二 选择合适设计模式,设计的时候要注意高扩展性和高可用。设计一套秒杀,总不能老板明天让你再拿一套再重新设计一边。或者某位领导拍脑袋决定,加个优惠卷,或者会员等级优惠,或者在搞一个排队的功能。 所以要选择好用的设计模式,个人还是倾向单一职责。这样就把秒杀单独拆分为一个服务。
第三 消息队列 引用消息队列的话,其实会引起其他更多的问题。但是同一时间内,大量的请求到达数据库,数据库还是可能会挂掉的。主要是将秒杀请求缓存在消息队列中,来达到削峰填谷的需求。 第四 代码的优化 比如使用缓存,事务,锁。根据业务逻辑,去优化代码,减少不必要的资源开销。
总上所述,秒杀系统的设计和开发,其实是一个复杂的过程,从设计和开发,从架构到实现,开发不应该只限于后台代码优化,对项目的流程,更应该有一个整体的认识。现在是人才辈出的时代,这是最好的时代,也是最坏的时代。对于可能出现的情况,一定要有一个解决思路和方案,才会有所进步。
本文基于作者个人认知和学习,属于学习笔记,如果有不对之处,请予指正。
心有所向,日复一日,必有精进。