MCP2.0平台几个比较重的队列堵塞问题分析

MCP，即多渠道接入平台，是中联集团早期推出的前置产品，目前还有不少城商行在使用，主要有中间业务系统、卡系统、支付系统等，但是在运维的过程大家会经常发现队列堵塞的问题，但是整个平台大约有十六七个队列，如何区分这些队列的功能和如何根据堵塞定位问题呢？下面我们主要分析和业务处理相关的4个队列在MCP平台中所处的位置和功能。

上图为MCP2.0逻辑架构图，此图主要描述交易报文在MCP平台的流转流程，跟据此图我们可以看出，在一个正常的交易处理过程中，交易报文主要经历了7号队列、9号队列、10号队列和8号队列。从此架构图中我们可以看出一个交易的处理基本就和这四个队列有关，从此图还可以看出这四个队列在整个MCP平台中分别承载的功能：

7号队列：通信适配器和路由进进程之间的交互，主要是通信层接到请求报文后对报文头做一些加工处理然后放到7号队列，路由进进程从7号队列无条件读走相关报文然后做路由分拣，路由进进程加上相关交易信息后放到9号队列。

9号队列：路由进服务和业务逻辑处理服务之间交互用队列，此队列是MCP平台最常见的出现堵塞现象的队列，当路由进服务放入9号队列的消息包速度大于业务服务读取的速度此队列就会堵塞，在早期的MCP版本中，在通信接入层并没有对并发量的控制，也就是只要有请求上来就会无条件接进来，而不管业务服务处理的性能，如果业务服务起的个数比较少或者有些交易处理的比较慢对业务服务占用时间比较长都会导致9号队列堵塞。

10号队列：此队列堵塞现象比较少见，一般只有路由出队列出现问题死掉的时候才会出现堵塞现象。

8号队列：此队列也是比较常见的堵塞队列，在MCP平台处理的过程中监管进程会定时查看其子进程（监听端口的进程）状态一般短子进程是否出现问题、是否要重启，但是在时间处理的时候监管进程会对其孙子进程（监听端口的进程的子进程，也就是接受服务请求负责通讯的进程）一并检查，但是根据unix的waitpid规则，其父进程只能检查子进程的状态而不能检查孙子进程的状态，这就会使监管进程在检查孙子进程的出现问题，导致孙子进程被从动态路由表中删除，就会导致请求方收不到响应。在系统处理某个交易超时时通讯服务会首先退出然后再通知父进程更改动态路由表里的状态，只就有一个时间差，就会导致路由出进程在放消息进8号队列的时候通信服务还在，刚放进去而通信服务又超时退出了，导致此队列堵塞。