突发性异步队列堵塞的解决方案（队列按照优先级分配资源）

文章目录

• 场景
• 分析
• 解决

场景

• 新客户在介入我们接口的时候，会跑大量的数据；导致线上的服务(服务流程: 客户的请求，放到消费队列中;队列任务将运算的结果，推送给客户) 杜塞， 影响的其他客户的调用
• 接口的并发能力
  • 50/s
  • 分析每个请求中所携带的参数,平均需要我们发送会有300个请求(调用我们另外一个项目组的接口)

分析

• 瓶颈
  • 系统的并发能力弱
  • 提高并发能力
    • 分析log发现主要的瓶颈是在调用另外一个项目组的接口(没有人维护了), 而建立请求连接,请求队列等待, 断开连接占用了非常多的时间, 所以做了一个批量的接口, 300次=> 缩减到了3次请求
    • mysql redis 使用长连接
    • 引入服务容器的概念,一次请求中一个服务只实列化一次
    • nginx 客户的请求有一定等待时间(物理)
      • 可能是客户的出口带宽满了
      • 可能是我们的入口带宽满了
      • 我们带宽 10M ==> 20M
  • 队列的执行能力耗尽
    • 4台机器 ==> 6台机器（物理）
    • 队列中充斥着新客户的请求, 导致没有能力去消费其他的客户的请求
      • 服务器资源分配不合理

解决

• 上面分析针对问题，都给了一些解决方案; 下面着重说下队列资源分配的问题
  • 初期
    • 运营人员和每个客户沟通，一旦某个客户的请求突然上来了(日常1万请求突然上升到了10万的请求); 那么单独的给这个客户开一个队列
      • 开始的时候效果很显著
      • 后来发现每个客户都会说 今天我的量非常大， 请给我开vip通道 ; 但是实际请求和平常一样；这导致越来越多的客户开了vip通道，大家都挺慢的
  • 现在
    • 设置队列优先级, 服务器全力消费高优先级队列，只有高优先级的消费完的时候才会开始消费低优先级的队列； 为了确保高优先级队列的稳定， 没有客户只允许在高优先级队列中存在400个请求， 其他多出来的请求填充到低优先级队列

标签：异步,优先级,请求,队列,带宽,接口,客户,分配资源
来源： https://blog.csdn.net/cominglately/article/details/97009529