一种网络带宽优化的发布订阅系统和方法

技术领域

本发明属于网络信息传输技术领域，具体涉及一种网络带宽优化的发布订阅系统和方法。

背景技术

发布订阅系统是边缘计算场景中的重要基础设施，目前得到了广泛应用。发布订阅系统通常由一个或多个服务器节点组成，对外提供服务。发布订阅系统的客户端包含发布者和订阅者两类主要角色，发布者向指定的主题(Topic)上发布消息，发布订阅系统将消息推送至订阅了这一主题的所有订阅者节点。在边缘计算场景中，发布订阅系统通常用于在各边缘节点中同步应用容器配置、应用程序配置、关键应用数据等，从而支撑应用部署以及边缘侧传感器数据收集、分析、处理、汇聚等关键功能。

边缘计算场景中发布订阅系统通常部署在边缘集群中的少量高性能边缘计算节点上，然而，边缘集群算力有限，少量的高性能边缘计算服务器需要应对大量的计算任务，并与数以万计的边缘传感器、摄像头等进行交互，可用的网络带宽极为有限，且需要预留一定的带宽保障关键应用和传感器数据的传输时效性。仅依靠边缘计算服务器完成消息和数据的推送任务可能导致网络拥塞，从而影响发布订阅系统的性能。针对这一问题，考虑协调部分订阅同一主题且有空余网络带宽和算力的客户端节点协助完成消息推送是一种可行的方案，可以有效平衡服务器的负载并降低其网络带宽占用。

然而，边缘计算场景中边缘设备等客户端上线离线频繁，导致订阅关系频繁变化，服务器自身需要频繁维护订阅关系，同时在协调客户端完成推送任务时需要附加待推送的客户端列表。现有技术方案需要维护庞大的客户端列表并通知需要协助完成消息推送的客户端节点，考虑到通常配置信息等消息尺寸相对较小，附加一个较长的客户端列表将会占有宝贵的带宽资源。

在另一方面，边缘计算场景中存在大量需要推送到整个集群的配置文件，这些配置文件包含大量的配置项，但在整个集群进行切换数据库、切换服务IP地址等操作时只需要改动配置文件中的某些配置项。现有发布订阅系统通常采用消息全量更新的方式将完整的配置文件推送至相关的客户端，当配置文件中只有少量更新时这一操作会浪费宝贵的网络带宽资源。

综上，亟需设计适用于边缘计算场景的网络带宽优化的发布订阅系统，通过改进消息推送流程并引入优化的消息增量更新方法以降低网络带宽消耗，降低资源利用率并优化消息推送性能。

发明内容

本发明的目的是为了解决背景技术中提及的问题，提供一种网络带宽优化的发布订阅系统和方法，能充分利用客户端的计算能力和网络带宽，在订阅关系频繁变化时有效降低网络带宽占用。

为实现上述技术目的，本发明采取的技术方案为：

一种网络带宽优化的发布订阅系统，包括发布端、服务器端和订阅客户端，所述订阅客户端包括协助推送客户端和被动订阅客户端，发布端和订阅客户端分别与服务器端通信连接，协助推送客户端与被动订阅客户端通信连接，还包括缓存模块、签名生成模块、签名验证模块、压缩模块、参数优化模块、监控模块和数据推送模块；所述压缩模块和数据推送模块设置在服务器端和订阅客户端上，所述缓存模块、签名生成模块和参数优化模块设置在服务器端上；所述签名验证模块和监控模块设置在订阅客户端上；所述各模块接收其他模块请求，并反馈请求对应的信息；

所述缓存模块用于存储并更新映射关系表、客户状态信息表和客户端列表；

所述签名生成模块，用于生成和更新客户端列表的签名，以及签名与客户端列表的对应关系表，并存储对应关系表；

所述签名验证模块用于存储签名与客户端列表的对应关系表、特定的客户端列表、客户端连接信息表，同时用于验证上述表格是否已存储；所述签名验证模块定期清理已存储的一定时间未使用的客户端列表；

所述压缩模块用于识别并生成所推送消息的增量信息或整合增量信息和其对应的原始消息；

所述参数优化模块用于确定推送阈值和失效阈值；

所述监控模块用于定期监控客户端性能；

所述数据推送模块用于推送消息；设置在服务器端的数据推送模块在推送消息时会附加上该消息所述订阅主题对应的客户端列表的签名。

作为优选，所述映射关系表记录订阅客户端与订阅主题的映射关系；

所述客户端状态信息表记录订阅客户端的信息，具体如下：

(1)客户端连接信息表，具体包括各个客户端的以下信息：

(1.1)客户端ID:一个从1开始递增的整型数值，用于在列表中唯一确定

客户端节点；

(1.2)客户端IP地址：用于识别客户端节点；

(1.3)客户端端口号：用于识别客户端节点；

(1.4)客户端连接状态：用于标记客户端在线或离线；

(2)客户端当前负载比：包括客户端当前CPU时间、内存使用率、磁盘I/O和网络I/O与当前订阅客户端集群对应指标的平均值的比值；

(3)客户端当前已承担的待协助推送的客户端总数；

每个订阅主题设有一个与其对应的独立的客户端列表，所述客户端列表记录订阅客户端的信息；所述客户端列表中每一项包括以下信息：

(4.1)客户端ID；

(4.2)该客户端的下游客户端节点ID；

(4.3)该客户端的上游客户端节点ID；当该客户端上游为服务器端时，其上游客户端节点ID设为“-1”；

所述客户端列表中每一项包含的客户端ID互不重复，且总项数为该客户端列表中客户端的数量。

作为优选，所述缓存模块持续监测订阅客户端，并更新客户端状态信息表；所述缓存模块定期剔除离线时间超过设定时长的订阅客户端，并更新客户端状态信息表；

所述缓存模块定期与监控模块交互，用于更新客户端状态信息表；

所述缓存模块定期与参数优化模块交互，当任一协助推送客户端的下游客户端节点数量超过推送阈值时，对全部客户端列表进行更新；当某客户端列表的离线客户端的数量超过失效阈值时，如通离线客户端仅为被动订阅客户端，则剔除该客户端列表中的所有离线客户端，如果离线客户端包括协助推送客户端，则对全部客户端列表进行更新；

所述缓存模块更新全部客户端列表过程如下：

S01、将列表中所有客户端的上游客户端节点ID设置为“-1”；

S02、将客户端根据当前负载比由小到大排序；

S03、将客户端负载比最小的客户端作为协助推送客户端A

S04、在剩下的客户端中重复步骤S03直至i满足：

该公式的结果向上取整，其中，K为订阅客户端所有客户端的数量，T为推送阈值。

作为优选，所述签名生成模块生成签名的工作步骤如下：

S11、对客户端列表中的每一项包含的信息单独求和并对INT_MAX取模，得到一个单独的整型值；

S12、将步骤S11得到的所有整型值拼接，得到一个整型数组；

S13、在步骤S12得到的整型数组前附加一个随机的UUID；

S14、计算步骤S13得到的整个结果的MD5值作为签名值；

所述签名生成模块将生成的签名与其对应的客户端列表，建立对应关系表，并存储对应关系表；

所述签名生成模块与缓存模块持续交互，当监测到客户端列表变化时，更新该客户端列表对应的签名，同时将原签名标记为失效并更新对应关系表。

作为优选，所述签名验证模块接收到签名后的工作步骤如下：

S21、查找签名验证模块是否存储客户端连接信息表和签名与客户端列表的对应关系表，如果都已存储则进入步骤S23，否则进入步骤S22；

S22、如果未存储客户端连接信息表，向连接的服务器端上的缓存模块请求客户端连接信息表；如果未存储对应关系表，向签名生成模块请求对应关系表，并保存反馈结果，然后进入步骤S23；

S23、查找对应关系表是否有传入消息附加的签名，如果有则进入步骤S25，否则进入步骤S24；

S24、向连接的签名生成模块请求该签名与客户端列表的对应关系，并存储反馈结果，然后进入步骤S25；

S25、根据传入信息附带的签名查找签名验证模块是否存储有该签名对应的客户端列表，如果已存储进入步骤S27，如果未存储则进入步骤S26；

S26、向连接的服务器端上的缓存模块，请求该签名对应的客户端列表，并存储反馈结果，然后进入步骤S27；

S27、确认客户端列表中每个客户端的连接信息是否存在，如果存在进入步骤S29，如果不存在则进入步骤S28；

S28、根据该客户端ID向连接的服务器端上的缓存模块请求其连接信息，并将反馈结果更新至客户端连接信息表，然后进入步骤S29；

S29、反馈客户端列表和客户端连接信息表；

所述签名验证模块定期清除已存储但一定时间未使用的客户端列表。

作为优选，设置在服务器端的压缩模块接收数据推送模块的请求，按照消息的如下类型计算增量信息并返回结果：

类型1、对于数组类型的数据，对新数组中的每个元素，依次在旧数组中进行查找，以确定增减项目；将增减项目存储至独立的数组中，附加上修改类型，将该列表作为增量信息返回；

类型2、对于以JSON或“Key＝Value”形式记录的配置，对比每个Key对应的Value值，以、确定增减和修改的项目，将增减及修改的项目存储至独立的列表中，附加上修改类型，将该列表作为增量信息返回；

类型3、对于文本类消息，按换行符分隔后，依次查找最长匹配字符串，并以字符为粒度计算修改位置和修改内容，将其存储至独立的列表中，附加上修改类型，将该列表作为增量信息返回；

类型4、对于非以上类型的消息，不作处理，直接返回原消息；

设置服务器端和订阅客户端的压缩模块将收到的增量信息内容，根据增量信息记载的修改类型，与增量信息对应的原始消息完成消息合并。

作为优选，所述参数优化模块确定推送阈值的步骤如下：

S31、参数优化模块定期与监控模块交互，获得当前订阅客户端集群的平均负载；

S32、使用给定的平均客户端推送阈值乘以步骤S31上一次监测到平均负载与当前平均负载的比值，即得到推送阈值；若上述平均负载比值大于给定缩放倍数则将平均负载比值修改为给定缩放倍数；

所述参数优化模块确定失效阈值步骤如下：

S41、参数优化模块定期与缓存模块交互，获得客户端离线比例Q

S42、按照如下公式计算失效阈值：

/>

F＝F

其中Q

作为优选，所述监控模块定期监测的客户端性能，包括以下信息：

(5.1)CPU时间：包括内核态和用户态的CPU时间；

(5.2)内存使用：包括已用内存和总内存；

(5.3)磁盘I/O：包括当前各磁盘的随机读写速率以及吞吐率；

(5.4)网络I/O：包括当前各网络接口的上传及下载速率。

作为优选，所述发布端在发送消息时附加增量发送需求信号；

设置在服务器端的数据推送模块的工作步骤如下：

S51、将发布端发送的原始消息存储至本服务器端的本地存储；

S52、解析发布端发送的原始消息中附加的增量发送需求信号，确定是否需要增量推送，如果需要增量推送先进入步骤S52，否则直接进入步骤S53；

S53、调用压缩模块计算并反馈增量信息，然后进入步骤S53；

S54、将原始消息或增量信息附加上相该消息所述订阅主题对应的客户端列表的签名，推送至客户端列表中上游客户端节点ID为“-1”的客户端；

设置在协助推送客户端的数据推送模块工作步骤如下：

S61、将接收到的消息存储至协助推送客户端的本地存储；接收到的消息为原始消息是，直接存储；接收到的消息为增量信息时，调用压缩模块将该增量信息与其对应的原始消息合并后存储；

S62、调用签名验证模块，反馈接收到的消息附加的签名对应的客户端列表和客户端连接信息表；

S63、根据步骤S62获得的客户端连接信息表和客户端列表，将接收到的消息推送至本客户端的所有下游客户端。

一种利用上述任一系统的网络带宽优化的发布订阅方法，包括以下步骤：

S101、在发布的新消息中添加增量发送需求信号；

S102、服务器端解析接收到的新消息中的增量发送需求信号，判断是否指需要只发送增量信息，如果是则先进入步骤S103，否则直接进入步骤S104；

S103、计算新消息中的增量信息，然后进入步骤S104；

S104、将新消息或增量信息推送至协助推送客户端，同时推送新消息所述订阅主题对应的客户端列表的签名；所述客户端列表定期更新，其对应的签名随之更新；

S105、协助推送客户端根据签名验证本地是否存储有对应的客户端列表，以及客户端连接信息表；如果有直接进入步骤S106,否则先向连接的服务器端请求该客户端列表和客户端连接信息表并存储至本地，再进入步骤S106；

S106、根据签名对应的客户端列表和客户端连接信息表，协助推送客户端将新消息或增量信息推送至其下游客户端；

S107、协助推送客户端直接存储新消息，对增量信息与其对应的原始信息合并后再存储；协助推送客户端的下游客户端对收到的消息做同样的处理。

本发明的有益效果是：

1.通过协助推送客户端协助服务器端推送消息，能够充分利用客户端的计算能力和网络带宽，减轻服务器端的计算压力，同时提高推送效率。

2.通过设置在服务器端的数据推送模块，对发布端发送的消息，先进行解析，确认是否只要推送增量信息，这样可以避免仅做了小范围改动的消息再完整的向后推送，无效占用了大量网络带宽，提升了网络带宽的利用率。

3.通过签名验证的方式，避免了每次发送消息时，都需要附加一个冗长的客户端列表，只需要附加一个占用网络宽带小的签名即可，在订阅关系频繁变化时有效降低网络带宽占用。

附图说明

图1是本发明系统模块连接示意图；

图2是系统部署示意图。

具体实施方式

以下结合附图对本发明的实施例作进一步详细描述。

需要注意的是，发明中所引用的如“上”、“下”、“左”、“右”、“前”、“后”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

如图1所示，一种网络带宽优化的发布订阅系统，包括发布端、服务器端(此处服务器端也可以分为第一服务器端和后续服务器端，其中第一服务器端与发布端通信连接，后续服务器端与第一服务器端通信连接，对发布的新消息是否只推送增量信息也仅有第一服务器端处理判断，后续服务器端起协助推送的作用；将服务端分为两部分可以提高计算处理效率)和订阅客户端，所述订阅客户端包括协助推送客户端和被动订阅客户端，发布端和订阅客户端分别与服务器端通信连接，协助推送客户端与被动订阅客户端通信连接；需注意，协助推送客户端和被动订阅客户端并不是固定的，而是根据客户端列表的更新而随之发生变化；

还包括缓存模块、签名生成模块、签名验证模块、压缩模块、参数优化模块、监控模块和数据推送模块；所述压缩模块和数据推送模块设置在服务器端和订阅客户端上，所述缓存模块、签名生成模块和参数优化模块设置在服务器端上；所述签名验证模块和监控模块设置在订阅客户端上；所述各模块接收其他模块请求，并反馈请求对应的信息；

所述缓存模块用于存储并更新映射关系表、客户状态信息表和客户端列表；

所述签名生成模块，用于生成和更新客户端列表的签名，以及签名与客户端列表的对应关系表，并存储对应关系表；

所述签名验证模块用于存储签名与客户端列表的对应关系表、特定的客户端列表(即推送过来的消息附加的签名所对应的客户端列表，此列表根据推送的消息会持续更新)、客户端连接信息表，同时用于验证上述表格是否已存储；所述签名验证模块定期清理已存储的一定时间未使用的客户端列表；

所述压缩模块用于识别并生成所推送消息的增量信息或整合增量信息和其对应的原始消息；

所述参数优化模块用于确定推送阈值和失效阈值；

所述监控模块用于定期监控客户端性能；

所述数据推送模块用于推送消息；设置在服务器端的数据推送模块在推送消息时会附加上该消息所述订阅主题对应的客户端列表的签名。

所述缓存模块存储的信息及其工作过程如下：

存储的信息：

(一)、映射关系表，记录订阅客户端与订阅主题的映射关系；映射关系表可用于后续查找订阅主题对应的客户端列表；

(二)、客户端状态信息表，记录的是订阅客户端的对应信息，具体如下：

(1)客户端连接信息表，具体包括各个客户端的以下信息：

(1.1)客户端ID:一个从1开始递增的整型数值，用于在列表中唯一确定

客户端节点；

(1.2)客户端IP地址：用于识别客户端节点；

(1.3)客户端端口号：用于识别客户端节点；

(1.4)客户端连接状态：用于标记客户端在线或离线；

(2)客户端当前负载比：包括客户端当前CPU时间、内存使用率、磁盘I/O和网络I/O与当前订阅客户端集群对应指标的平均值的比值；

(3)客户端当前已承担的待协助推送的客户端总数；

(三)、客户端列表；每个订阅主题设有一个与其对应的独立的客户端列表，所述客户端列表记录的是订阅客户端对应的信息；所述客户端列表中每一项为该列表中每个客户端的对应信息，具体包括以下信息：

(4.1)客户端ID；

(4.2)该客户端的下游客户端节点ID；

(4.3)该客户端的上游客户端节点ID；当该客户端上游为服务器端时，其上游客户端节点ID设为“-1”；

所述客户端列表中每一项包含的客户端ID互不重复，且总项数为该客户端列表中客户端的数量(即确保客户端列表中的每个客户端对应的信息都有)。

工作过程：

所述缓存模块持续监测订阅客户端，并更新客户端状态信息表，根据监测结果缓存模块定期从客户状态信息表中剔除离线时间超过设定时长的订阅客户端，以节省内存空间；

所述缓存模块定期与监控模块交互，用于更新客户端状态信息表(更新其中的客户端当前负载比)；

所述缓存模块定期与参数优化模块交互，当任一协助推送客户端的下游客户端节点数量超过推送阈值时，对全部客户端列表进行更新；当某客户端列表的离线客户端的数量超过失效阈值时，如通离线客户端仅为被动订阅客户端，则剔除该客户端列表中的所有离线客户端，如果离线客户端包括协助推送客户端，则对全部客户端列表进行更新；

所述缓存模块更新全部客户端列表过程如下：

S01、将列表中所有客户端的上游客户端节点ID设置为“-1”；

S02、将客户端根据当前负载比由小到大排序；

S03、将客户端负载比最小的客户端作为协助推送客户端A

S04、在剩下的客户端中(步骤S03每次都是在上一次选择过后剩下的客户端中再重新进行选择)重复步骤S03直至i满足：

该公式的结果向上取整，其中，K为订阅客户端所有客户端的数量，T为推送阈值；比如订阅客户端总数K＝100，推送阈值T＝10，那么每个协助推送客户端的下游客户端节点数量最多为10个，需要从100个订阅客户端中选择出100/(10+1)≈9.09个协助推送客户端，向上取整，即需要选取出10个协助推送客户端，也就是步骤S03要进行10次，对全部客户端列表的更新才完成。

所述签名生成模块生成签名的工作步骤如下：

S11、对客户端列表中的每一项包含的信息(即客户端自身ID、上游客户端节点ID和下游客户端节点ID)单独求和并对INT_MAX取模，得到一个单独的整型值(这个整型值的数量为客户端列表包含的总项数)；

S12、将步骤S11得到的所有整型值拼接，得到一个整型数组；

S13、在步骤S12得到的整型数组前附加一个随机的UUID；

S14、计算步骤S13得到的整个结果的MD5值作为签名值；

所述签名生成模块将生成的签名与其对应的客户端列表，建立对应关系表，并存储对应关系表(签名生成模块设有本地缓存)；

所述签名生成模块与缓存模块持续交互，当监测到客户端列表变化时，更新该客户端列表对应的签名，同时将原签名标记为失效并更新对应关系表。

所述签名验证模块接收到签名后的工作步骤如下：

S21、查找签名验证模块是否存储客户端连接信息表和签名与客户端列表的对应关系表，如果都已存储则进入步骤S23，否则进入步骤S22；

S22、如果未存储客户端连接信息表，向连接的服务器端上的缓存模块请求客户端连接信息表；如果未存储对应关系表，向签名生成模块请求对应关系表，并保存反馈结果，然后进入步骤S23；

S23、查找对应关系表是否有传入消息附加的签名，如果有则进入步骤S25，否则进入步骤S24；

S24、向连接的签名生成模块请求该签名与客户端列表的对应关系，并存储反馈结果，然后进入步骤S25；

S25、根据传入信息附带的签名查找签名验证模块是否存储有该签名对应的客户端列表，如果已存储进入步骤S27，如果未存储则进入步骤S26；

S26、向连接的服务器端上的缓存模块，请求该签名对应的客户端列表，并存储反馈结果，然后进入步骤S27；

S27、确认客户端列表中每个客户端的连接信息是否存在，如果存在进入步骤S29，如果不存在则进入步骤S28；

S28、根据该客户端ID向连接的服务器端上的缓存模块请求其连接信息，并将反馈结果更新至客户端连接信息表，然后进入步骤S29；

S29、反馈客户端列表和客户端连接信息表；

所述签名验证模块也设有本地缓存，且定期清除已存储但一定时间未使用的客户端列表。

设置在服务器端的压缩模块接收数据推送模块的请求，按照消息的如下类型计算增量信息并返回结果：

类型1、对于数组类型的数据，对新数组中的每个元素，依次在旧数组中进行查找，以确定增减项目；将增减项目存储至独立的数组中，附加上修改类型，将该列表作为增量信息返回；

类型2、对于可反序列化的以JSON或“Key＝Value”形式记录的配置，对比每个Key对应的Value值，以、确定增减和修改的项目，将增减及修改的项目存储至独立的列表中，附加上修改类型，将该列表作为增量信息返回；

类型3、对于文本类消息，按换行符分隔后，依次查找最长匹配字符串，并以字符为粒度计算修改位置和修改内容，将其存储至独立的列表中，附加上修改类型，将该列表作为增量信息返回；

类型4、对于非以上类型的消息，不作处理，直接返回原消息；因为本发明主要针对类型1-3三种消息进行增量推送，如果是其他类型的消息，计算其增量信息的计算量过大，就没必要进行增量推送了；

设置服务器端和订阅客户端的压缩模块将收到的增量信息内容，根据增量信息记载的修改类型，与增量信息对应的原始消息完成消息合并。

所述参数优化模块确定推送阈值的步骤如下：

S31、参数优化模块定期与监控模块交互，获得当前订阅客户端集群的平均负载；

S32、使用给定的平均客户端推送阈值乘以步骤S31上一次监测到平均负载与当前平均负载的比值，即得到推送阈值；若上述平均负载比值大于给定缩放倍数则将平均负载比值修改为给定缩放倍数；缩放倍数相当于一个给定的推送阈值放大比例上限。

所述参数优化模块确定失效阈值步骤如下：

S41、参数优化模块定期与缓存模块交互，获得客户端离线比例Q

S42、按照如下公式计算失效阈值：

/>

F＝F

其中Q

所述监控模块定期监测的客户端性能，包括以下信息：

(5.1)CPU时间：包括内核态和用户态的CPU时间；

(5.2)内存使用：包括已用内存和总内存；

(5.3)磁盘I/O：包括当前各磁盘的随机读写速率以及吞吐率；

(5.4)网络I/O：包括当前各网络接口的上传及下载速率。

所述发布端在发送消息时附加增量发送需求信号；

设置在服务器端的数据推送模块的工作步骤如下：

S51、将发布端发送的原始消息存储至本服务器端的本地存储；

S52、解析发布端发送的原始消息中附加的增量发送需求信号，确定是否需要增量推送，如果需要增量推送先进入步骤S52，否则直接进入步骤S53；

S53、调用压缩模块计算并反馈增量信息，然后进入步骤S53；

S54、将原始消息或增量信息附加上相该消息所述订阅主题对应的客户端列表的签名，推送至客户端列表中上游客户端节点ID为“-1”的客户端。

设置在协助推送客户端的数据推送模块工作步骤如下：

S61、将接收到的消息存储至协助推送客户端的本地存储；接收到的消息为原始消息是，直接存储；接收到的消息为增量信息时，调用压缩模块将该增量信息与其对应的原始消息合并后存储；

S62、调用签名验证模块，反馈接收到的消息附加的签名对应的客户端列表和客户端连接信息表；当客户端连接信息表中的表明客户端已离线，协助推送客户端便可以不向此客户端推送消息；

S63、根据步骤S62获得的客户端连接信息表和客户端列表，将接收到的消息推送至本客户端的所有下游客户端。

一种利用上述任一系统的网络带宽优化的发布订阅方法，包括以下步骤：

S101、在发布的新消息中添加增量发送需求信号；

S102、服务器端解析接收到的新消息中的增量发送需求信号，判断是否指需要只发送增量信息，如果是则先进入步骤S103，否则直接进入步骤S104；

S103、计算新消息中的增量信息，然后进入步骤S104；

S104、将新消息或增量信息推送至协助推送客户端，同时推送新消息所述订阅主题对应的客户端列表的签名；所述客户端列表定期更新，其对应的签名随之更新；

S105、协助推送客户端根据签名验证本地是否存储有对应的客户端列表，以及客户端连接信息表；如果有直接进入步骤S106,否则先向连接的服务器端请求该客户端列表和客户端连接信息表并存储至本地，再进入步骤S106；

S106、根据签名对应的客户端列表和客户端连接信息表，协助推送客户端将新消息或增量信息推送至其下游客户端；

S107、协助推送客户端直接存储新消息，对增量信息与其对应的原始信息合并后再存储；协助推送客户端的下游客户端对收到的消息做同样的处理。

如图2所示，下面以一个实例阐述具体步骤：

1.不失一般性，假设集群由2个服务器与4个客户端组成，客户端1和客户端2连接至服务器1，客户端3和客户端4连接至服务器2；客户端1作为协助推送客户端，客户端2作为被动订阅客户端，客户端3作为发布端；服务器1作为协助推送的服务器端，服务器2作为接收处理发布消息的服务器端，实际情况中也可以选择将服务器1和服务器2合并，即在同一台服务器上完成这两台服务器的功能，但是这样会导致计算效率低下；

2.客户端1向服务器1订阅主题“test”。

3.服务器1将客户端1加入主题“test”的客户端列表中9(通过缓存模块存储)，并通过签名生成模块生成签名，以及签名和该客户端列表的对应关系表，同时将客户端1的上游客户端节点ID设置为“-1”。

4.客户端2向服务器1订阅主题“test”。

5.服务器1将客户端2加入主题“test”的客户端列表中，并更新签名和对应关系表；然后客户端2的上游客户端节点ID被设置为“1”，客户端1的下游客户端节点ID被设置为“2”(本实施例被动订阅客户端只给出了客户端2，如果有其他被动订阅客户端，比如客户端3、4，那么将客户端1的下游客户端节点ID设置为2,3,4,这样消息就会由客户端1推送到客户端2、3和4)，也即后续由客户端1向客户端2推送消息，而不是由服务器2直接向其推送。

6.客户端3向服务器2发布主题“test”的最新消息“testKey＝testValue”，并附加增量发送需求信号(信号内容为“否”)。

7.服务器2接收到客户端3发送的消息，通过解析增量发送需求信号确定不需要进行增量信息推送，将消息持久化至本地存储，并将消息直接推送至服务器1。

8.服务器1将消息推送至客户端1，并附加上该消息所属订阅主题“test”对应的客户端列表的签名。

9.当客户端1首次作为协助推送客户端时，向服务器1请求所有连接到服务器1的客户端(客户端1和2)连接信息表、对应关系表(签名和客户端列表的对应关系表)，以及签名对应的客户端列表；如果客户端1不是首次作为协助推送客户端，则根据服务器1所发送的消息附加的签名，在本地存储(也即签名验证模块中的本地缓存)中先确认是否有该订阅主题的对应关系表，如果没有向服务器1请求发送并存储；如果有的话则根据对应关系表查找本地存储中是否有签名对应的客户端列表，然后通过客户端列表去人客户连接信息表是否完整，如果不完整向服务器1请求更新。

10.客户端1根据上一步最终得到的客户端列表和客户连接信息表，确认其下游客户端(客户端2)，以及对应的通信地址(由客户端连接信息表获取)，将消息推送到客户端2，并将消息存储至本地。

11.客户端2收到消息后更新本地存储。

需注意，上述客户端3发布的消息为不需要增量推送的消息，如果仅是对本次发送的“testKey＝testValue”消息，作部分改动，那可以将增量发送需求信号的内容设置为“是”，那么服务器2就会解析该消息内容得到消息的增量信息，之后仅将增量信息向后推送(推送到服务器1、客户端1和客户端2)，到消息到达后续服务器端或订阅客户端，通过其本地的处理，将增量信息和其对应的之前发送的原始消息进行合并处理，得到完整的新消息，这样大大节省了网络带宽资源，提升了推送效率。

通过引入本发明，可以充分利用客户端的计算能力和网络带宽，在订阅关系频繁变化时无需每次都附加推送完整的客户端列表，有效降低网络带宽占用。

以上仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，应视为本发明的保护范围。