背景

  • 大量用户请求同一数据，也就是热点数据
  • 允许大部分用户不被响应，保证服务可用
  • 如果使用轮询，会导致中心压力太大

  • 中心请求数不做不范围技改前提

    前置

  • 倒计时

  • 与服务器时间校准
  • 请求是否可秒杀，进入支付页或者真实下单页

基本思路，限流

  • 把前端资源，分发到cdn，解决请求数的负载问题

  • 每个节点服务统计在线人数，中心统计出总在线人数，根据中心可负载数量，计算出能够流转到后端的请求比例，其他请求被搁置，等待状态

    其他秒杀性质

  • 双十一，要保证真实的高并发，所以中心一定要做支持

  • 买火车票，多品类秒杀

    • 分批段放票，包括分时间段以及分票源
    • 预售，根据库存概率性告知预售结果

      其他案例

  • 某东，服务限流，单机限流，限制流量根据压测得出，缓存定时下载库存，当缓存减库存成功，并且数据库减库存成功，代表下单成功

  • 微信红包，直接前端概率性过滤，部分人可到达真实页面，其他人排队状态

    其他延伸

  • 限流不能保证绝对的公平，只能是保证服务可用

  • 限流不仅仅是这样，还有根据区域，ip，用户特征等等的限流策略
  • 压测时，如果发现某些特征用户被分配的概率较低，应该调整其应用部署数量或者概率值
  • cdn也可以部署程序类，需要与服务商沟通做定制需求
  • 本文最大的一个方向是告诉大家做秒杀，不一定要中心真的支持这么大并发，可以在边缘计算，限流，或者其他角度做一些思考和尝试