构网络中，消费端系统 2005只有通过客户端MQ中间件平台2003建立连接，才能接收到MQ推送的消息。由于MQ消息 模式限制以及性能限制，目前MQ客户端不支持直接获取消息队列中的消息积存数量。因此， 根据本公开的实施例，监控子系统2071可以基于消费一类消息的各消费节点在单位时间段 内消费该类消息的平均数量来计算该类消息的积存度量，和/或基于一消费节点在单位时 间段内消费的所有消息的数目来计算该消费节点的处理压力度量。
[0056]具体地，根据本公开的实施例，监控子系统2071可以采用通过监控消费节点的消 费频率来达到监控各消费节点处理压力的目的。在此，一消费节点对一类消息ΠΗ的消费频 率叫可以定义为N/t，其中N是该消费节点W在预定时间段t内消费的该类消息nu的数目。 aiJ 表示消息nu对消费节点W造成的压力值。
[0057]消费端系统2005的处理压力可以用矩阵A表示，简称压力矩阵：
[0059] 如果资源矩阵MC中的元素mClj为0，则在压力矩阵A中，相应的压力值(?也为0，因 为mClj = 0表示消费节点并未订阅消息πη，即在预定时间段t内消费的该类消息nu的数目为 0〇
[0060] 消费节点订阅处理的消息种类越多，该消费节点的处理压力越大。因此，消费节点 Cj处总的处理压力值或处理压力度量可以表示为：
[0062]由于一种MQ消息可以由多个消费节点进行消费，并且消息中间件服务平台的负载 均衡确保了消费节点的处理压力值相差不多。于是，该消息对应的各消费节点的平均处理 压力直接反应了该消息的积压情况。因此，对于一类消息nu，其积存值或积存度量Μ可以表 示为：
[0064] 根据本公开的实施例，采用两种原则来调整MQ消息的消费节点资源。具体地，一方 面，当MQ消息mi在其现有的分配消费节点资源mci = (mcii，mci2,. . .mcin)下，其积存值超过某 一阈值?时，表明消费节点计算资源不足，需要重新调整计算处理资源。另一方面，当消费 节点q压力值超过某一阈值万时，则表明需要对节点q的现有MQ消息进行计算资源重分配。 上面两种情况就是本文需要调整MQ消息的消费节点资源的两种调控原则。
[0065] 根据这两个原则，当某一类消息nu的积存度量\超过阈值称为"第一阈值"）时， 可以为该类消息nu分配一新的消费节点；和/或，当某一消费节点的处理压力度量比超过 阈值及（称为第二阈值)时，可以为该消费节点W中积存度量最大的一类消息分配一新的消 费节点。
[0066] 图3示出了根据本公开实施例的监控子系统进行资源分配的流程图。
[0067]如图3所示，在操作301，监控子系统2003可以根据以上计算得到的积存度量 处理压力度量氏，查找超过积存阈值1的消息πη。如不存在（即，"否"），则操作进行到307;否 贝1J，操作进行到303，对消息nu进行资源预分配操作。
[0068] 根据本公开的实施例，资源预分配操作可以包括:查找当前并不消费该类消息的 消费节点中处理压力度量最小的消费节点，假设从当前消费该类消息的各消费节点所消费 的该类消息中分出一定数量由所查找的消费节点来处理。
[0069] 具体地，可以查找没有被消息nu分配的消费节点中处理压力值最小的消费节点Cj 作为预分配资源，并对处理压力矩阵A作如下变换：
[0071]
当且仅当mci，y关0〇
[0072] 在该示例中，将δ设为原积存值M/(当前订阅消息mi的节点数+1)，但是本公开不限 于此，可以按其他方式设定δ。
[0073] 之后，在操作305,可以基于资源预分配操作的结果(例如，体现为变化后的处理压 力矩阵Α)，重新计算各类消息的积存度量以及各消费节点的处理压力度量。
[0074] 接着，在操作307,可以查找超过处理压力阈值:罗的消费节点q。若存在（即，"是"）， 则可以查找节点W中积存值最大的消息nu，且操作进行到303,针对该类消息nu执行资源预 分配操作(例如，如上所述变化压力矩阵）；否则，操作进行到309,以得到收敛的最终资源分 配结果。
[0075] 具体地，可以进行如下处理获得MQ消息的资源矩阵MC:
[0077] 其中，mcij = l 当且仅当 aij>〇，mcij = 0 当且仅当 aij = 〇。
[0078] 根据本公开的原理，压力矩阵A最多经过k(n-l)次矩阵变换即可得到一个变换收 敛值。这是因为如上所述设定消费端系统现有的消费节点计算资源能够满足订阅的各种MQ 消息处理，因为每种消息最多经过(n-1)次压力矩阵变换处理，即可分配完所有的消费节 点。
[0079]这样，监控子系统2071获得了新的资源分配方案(体现为得到的新资源矩阵MC)， 其中可能向某一类消息nu新分配了一个或多个消费节点。
[0080] 当然，如果最终不能收敛(例如，经过预定次数的资源预分配操作或者说压力矩阵 变换之后，例如由于消费端系统现有的消费节点事实上并不能满足消息处理的需求），则可 以返回错误，以告知系统管理员。
[0081] 监控子系统2071可以实时或者按预定的定时持续进行监控操作。
[0082] 分配子系统
[0083]根据监控子系统2071获得的新资源分配方案，分配子系统2073可以自动更新各消 费节点的订阅信息。
[0084]图4示出了根据本公开实施例的分配子系统更新消费节点订阅信息的流程图。 [0085]如图4所示，分配子系统2073可以按预定的同步时刻，来进行这种更新操作。具体 地，在操作401，可以判断是否达到同步时刻。如果尚未到达（即，"否"），则分配子系统2073 可以继续等待同步时刻的到达;否则（g卩，"是"），则分配子系统2073可以从监控子系统2071 获得新的资源分配方案(例如，资源矩阵MC)。
[0086]然后，在操作403,分配子系统2073可以判断获得的新资源分配方案是否与前次资 源分配方案相同。具体地，分配子系统2073可以判断获得的新资源矩阵MC与当前使用的资 源矩阵MC是否相同（即，判断MC中各元素是否相同，也就是说，判断某一消费节点是否被分 配了新的一类消息）。
[0087]如果资源分配方案未发生变化，则操作返回401，继续等待下次同步时刻的到来。 如果资源分配方案发生了变化，则操作进行到407,分配子系统2073可以根据新的资源分配 方案（即，新的资源矩阵MC)，来更新节点的订阅信息。具体地，如果一消费节点被分配了新 的一类消息，则可以更新该消费节点的订阅信息。例如，可以通过MQ的应用编程接口（API) 对消费节点上的MQ consumerListener的监听者信息进行更新，其中每一监听者负责监听 一类信息。
[0088] 本案中的同步工具可以是一个循环线程，也可以是一个定时worker工具，该同步 工具最重要的特征是要具有循环定时执行任务的功能。
[0089] 在现有多消息处理的应用系统中，当出现MQ消息积压时，大部分采取人工干预措 施，不但增加了系统运维成本，导致系统服务器资源的浪费，并且从根本上无法解决MQ消息 的积压问题。在此提出的基于反馈机制的M