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

分手后的思念是犯贱 2021-11-27 03:38 166阅读 0赞

### 文章目录 ###

*   *   *  场景
         *  分析
         *  解决

### 场景 ###

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

### 分析 ###

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

### 解决 ###

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