Web 技术研究所

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

秒杀的核心是什么?

  一谈到秒杀,大家就会想到是各种缓存、限流等东西。虽然对于秒杀这种类型的业务,缓存、限流等东西是必须的,但它们算不上核心。它们只是解决一些问题的具体方式而已。我觉得,秒杀的核心应该是消峰,只有消峰才能保住后端。至于 QPS 瓶颈之类的问题本身和秒杀关系不大。
  「消峰」不是会降龙十八掌的那个「萧峰」,就算会降龙十八掌,摊上秒杀这种不讲道理的业务也是闹不住的。对于秒杀而言,最重要的事情就是如何把洪峰给消掉,把瞬时的请求平摊到更长的时间段上。对于这一点,解决的办法就是限流。无论是从前端直接阻止用户把请求发到后端还是在入口服务器上限制连接数,或者是内部的七层代理负载均衡服务器上限制访问量。总之就是把连接数先干掉,让服务器只支持自己能够承受的并发量,其余建连请求全部打回去。
  但是如此暴力的招架会把很大一部分用户挡掉,此时就需要前端来发出各种萌萌哒的提示,让用户等待但却不要失去耐心。前端还可以阻止单个用户在短时间内重复发请求,避免用户疯狂的点击对服务器造成压力。如果连入口服务器都快要扛不住时还可以让前端把请求直接拦下来直接提示用户等待,暂时不与后端交互。
  至于缓存的问题其实和秒杀的关系并不是特别大。因为即使没有秒杀,我们的业务代码中也会做各种缓存来提高业务性能。只不过对于秒杀这样的业务,我们需要更加认真地设计整体架构,设计更有效的缓存机制并且充分利用而已。实际上最终还是有很多无法完全缓存掉的东西,比如库存检查等。
  另外也经常会有人在秒杀优化方案中提到 QPS,这和缓存一样和秒杀的关系不大。当我们设计秒杀优化方案时就已经默认业务本身是极致优化的状态了。也就是说很难再有什么方式可以提升业务的 QPS 了(如果有这样的方案,不用等秒杀也早就在业务里实施了)。所以秒杀优化这件事讨论的核心问题是如何在目前的 QPS 瓶颈下更好地应对这块业务。
  当然,有时候业务本身的设计也不怎么好,这时候对业务本身的优化确实非常有必要。比如重新设计数据库结构,使用更好的方式来存储「库存」字段。然而,这种程度的优化又脱离的秒杀,变成了一般的业务流程优化。
  真正属于秒杀的优化,在程序方面就是限流,各种限流!剩下的就是在产品设计上优化,而且其优化的核心思想依然是消峰。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^