Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

秒杀活动的并发问题

  去年我就提了关于前端服务的降级方案,但一直没有机会实现,终于在最经的业务中得到了应用。由于最经有一些秒杀活动,在同一时刻会有海量的请求发到服务器,这些海量的请求会把服务器的并发连接数给打爆。于是最终的方案就是直接在前端临时阻止掉一部分请求然它们不发到服务器。
  其实很多人反感前端限流,特别是在秒杀活动中。因为前端毕竟是可以绕过去的,也就是会导致一些秒杀软件的诞生。但我觉得,前端限流也是可以在一定程度上保护服务器的,即使平时不开启也应该留着这个降级开关。
  后端虽然可以限流,但是如果秒杀这个业务如果没有单独定制,而是和其它业务耦合在一起的话后端限流就会遇到问题。或者说,只要秒杀相关的 API 的入口 IP 没有和其它业务分离出来就会有问题。如果秒杀业务和其它业务部署在同一个集群上,后端限流就需要走 7 层代理,因为需要分析请求的 URL,把秒杀的请求和普通请求区分出来,这样才能只针对秒杀的 API 做限流,不误杀其它业务的请求。可是一旦基于 7 层代理来限流,那就意味着服务器必须和客户端建立连接。对于秒杀这种业务而言,并发的连接数是对服务器最大的挑战之一。即使我们有后端限流,所有请求也会在建立连接并收到请求报文后被判断是秒杀的请求才断开,在这一系列动作完成前,如果有海量请求进入服务器,服务器的连接数就可能被打爆。
  前端限流的降级方案只是一个非常规的方案,在其它方案无法快速部署上线的情况下,使用前端限流确实是可以临时解决问题的。但这确实不是一个长期方案,因为后续确实可能有秒杀软件诞生。
  正确的处理方式应该是把秒杀的 API 域名和其它业务独立开来,在最外层终端服务器上直接做无差别的连接数限制。一旦超出限制就不再建立更多连接,前端一旦建连失败就提示用户稍后重试之类的信息。
  秒杀是个麻烦的东西,并发问题只是其中很小的一部分,还有大堆问题需要解决呢。
网名:
54.198.108.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^