秒杀图解

类似于秒杀这类的业务,一个主要的特点就是短时间内流量的突增

整体的一个原则就是尽量减少不必要的请求进入到我们的数据库

或者延缓请求到达数据库的过程

系统每日PV大约是3百万,UV大约在50万

nginx层作为请求的入口,我们主要是用来做反向代理和负载均衡,把大量的请求分发到不同的服务器减轻单独某台服务器的压力,此外我们还在nginx层做了流控限制作为一个流量网关,把检测到的恶意请求的ip地址做为黑名单ip给屏蔽掉

在流量网关和业务系统之间采用了springCloudGateway作为我们的一个业务网关在这层我们配置了些全局性的过滤限制和针对性某些接口的访问限制比如我们在gateway层使用了基于redis的RateLimiter针对每个ip的访问频率也进行了流控限制

另外针对秒杀接口的过滤我们也对每个用户的请求频率做了限制,防止单个用户频繁请求

系统监控到最高的时候有两千多的QPS,极端情况下接口会有被打垮掉甚至引发服务雪崩的情况进而导致整体服务不可用,当请求进入到我们具体的微服务接口中,对于下单和支付的接这些关键接口除了使用到ribbon的客户端负载均衡减轻单台服务器压力之外,还配置的springCloud的Hytrix做了服务的熔断和降级配置防止服务的雪崩

秒杀抢购的业务中抢购的商品数量有限读请求是多远多于写请求的,我们把具体的商品id最为key,商品的库存和一些其他的商品属性信息存放到redis缓存中,当请求时间校验不通过或者缓存中库存不足时,直接就返回了避免了大量不必要的读请求到达mysql数据库

此外,当下单的条件都满足时,我们引入了消息队列把用户信息和商品信息投递到mq中,监听下单的队列进行异步下单延缓了请求到达数据库的过程

之前有次系统并发数上不去时,还修改过-Xss来减少分配给单个线程的空间，也可以增加系统总共内生产的线程数提供系统的并发性能,不过也不能设置太小容易导致堆栈溢出