CN107634918A - 一种软总线管理方法与装置 - Google Patents

Abstract

本发明公开了一种软总线管理方法与装置，该方法包括：监测软总线上新增事件的类型，其中，事件的类型包括：对象事件和服务事件；使用与事件的类型相对应的预设优化算法对软总线的管理行为进行调整，其中，对象事件对应的预设优化算法为成员管理优化算法，服务事件对应的预设优化算法为消息订阅分发优化算法。本发明通过监测软总线上的新增事件类型，根据不同事件类型使用不同的优化算法对软总线的管理行为进行调整，达到减少软总线的资源占用率，解决了现有技术中软总线资源占用率高的问题。

Description

一种软总线管理方法与装置

技术领域

本发明涉及计算机技术领域，特别是涉及一种软总线管理方法与装置。

背景技术

软总线是支撑异构系统软件间进行交互的软件，通过定义交互的标准接口，使符合标准要求的软件间能够以“即插即用”的方式灵活地互连互通。随着陆、海、空、天、电一体化联合作战概念的形成，仿真试验和训练需要将多个异构仿真设施和靶场进行连接，软总线作为支撑资源互联共享的重要手段得到广泛应用。

LVC(live，virtual and constructive)仿真集成的新需求，对软总线的管理机制方面提出了更高的要求。首先，成员的行为更加多样化，各类实况和虚拟的仿真成员，因人的参与使得系统不可控的因素骤增，需要软总线提供动态的管理策略应对不确定因素；其次，大规模异地的数据交换需求，使得系统的底层资源变得十分紧张，需要软总线压缩管理开销保证仿真系统的执行效率。

目前的软总线采用对软总线成员的粗放管理，缺乏利用仿真过程中的消息余量和网络延迟等统计信息对软总线成员和消息分发方式进行动态调整的能力，导致对网络资源的占用多。软总线作为不同系统之间进行信息交互的通道，资源非常有限，对其的优化非常有必要，现有的软总线管理技术在以下几方面存在不足：

(1)成员管理主要实现对当前状态的监控和管理，其中成员管理功能较为薄弱。成员状态的监控包括对成员接入/断开软总线、加入/退出成员组等行为的监控，但缺乏基于监控统计结果的管理机制。部分系统具备了初步的成员管理能力，可以通过心跳报文周期性的监控成员状态，对于监控到的状态异常的成员，能够执行强制断开软总线、强制退出成员组等操作；对于监控到的未加入成员组的成员，能够执行邀请加入成员组等操作。目前的成员监控仅实现了对成员基本状态的维护，在抽取成员管理的规则和策略方面还存在不足，也无法通过仿真周期内的统计数据收集来优化管理。目前的成员在线状态监控是通过心跳的方式进行监控。而传统的心跳频率是固定的值，但是频率过高会占用大量的软总线资源，而频率过低会使得系统不能及时监控成员的在线状态。

(2)软总线根据所有成员对不同消息的订阅情况建立发布订阅/关系，同时软总线负责将成员产生的消息按照发布订阅关系分发给订阅该类型消息的成员。传统的消息订阅分发技术基于成员间的发布/订阅关系，而软总线成员按需指定消息的订阅方式，导致同一消息需要发送多次才能保证每个成员都收到消息，造成软总线资源的浪费。

因此，需要一种软总线的管理优化方法，以减少软总线的资源占用。

发明内容

本发明提供一种软总线管理方法，用以解决现有技术中软总线资源占用率高的问题。

为解决上述技术问题，一方面，本发明提供一种软总线管理方法，包括：监测软总线上新增事件的类型，其中，所述事件的类型包括：对象事件和服务事件；使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，其中，所述对象事件对应的预设优化算法为成员管理优化算法，所述服务事件对应的预设优化算法为消息订阅分发优化算法。

进一步，使用与所述事件的类型相对应的优化算法对所述软总线的管理行为进行调整之前，还包括：对所述软总线上预设成员在单位时间内的最大消息量、掉线频率以及网络质量进行监测。

进一步，在所述事件的类型为对象事件的情况下，使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，包括：按照如下公式确定向预设成员发送的心跳报文的发送频率：其中，R_m为所述预设成员在单位时间内的消息余量与所述预设成员在单位时间内的最大消息量的比值，R_o为所述预设成员在单位时间内的掉线频率，R_q为所述预设成员在单位时间内的网络质量，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率；按照所述优化之后的心跳报文的发送频率向所述预设成员发送心跳报文。

进一步，在所述事件的类型为服务事件的情况下，使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，包括：遍历所述软总线中订阅预设消息的所有成员的端口信息、多播历史丢包率和UDP历史丢包率；根据所述端口信息判断所述所有成员中预设成员是否支持多播方式；在所述预设成员支持多播方式且所述预设成员的多播历史丢包率小于第一阈值的情况下，将所述预设成员的消息订阅方式调整为多播方式；在所述预设成员不支持多播方式或所述预设成员的多播历史丢包率大于或等于所述第一阈值的情况下，判断所述预设成员是否支持UDP方式；在所述预设成员支持UDP方式且所述预设成员的UDP历史丢包率小于第二阈值的情况下，将所述预设成员的消息订阅方式调整为UDP方式；在所述预设成员不支持UDP方式或所述成员的UDP历史丢包率大于或等于所述第二阈值的情况下，将所述预设成员的消息订阅方式调整为TCP方式。

进一步，在所述事件的类型为服务事件的情况下，使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，包括：遍历所述软总线中订阅预设消息的预定成员的端口信息，并根据所述端口信息判断所述端口信息对应的端口是否支持多播方式；在所述端口支持多播方式的情况下，判断预设消息缓存表中是否存在与所述预设成员存在相同端口信息的其它成员，并在存在与所述预设成员存在相同端口信息的其它成员的情况下，将所述预设成员的端口信息与所述其它成员的端口信息合并，在不存在与所述预设成员存在相同端口信息的其它成员的情况下，在所述消息缓存表中所述预设消息对应的缓存数据中添加所述端口信息；在所述端口不支持多播方式的情况下，判断所述端口是否支持UDP方式，并在所述端口支持UDP方式的情况下，在所述缓存数据下添加以UDP方式订阅所述预设消息的端口信息；在所述端口不支持UDP方式的情况下，在所述缓存数据下添加以TCP式方订阅所述预设消息的端口信息。

另一方面，本发明还提供一种软总线管理装置，包括：监测模块，用于监测软总线上新增事件的类型，其中，所述事件的类型包括：对象事件和服务事件；优化模块，用于使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，其中，所述对象事件对应的预设优化算法为成员管理优化算法，所述服务事件对应的预设优化算法为消息订阅分发优化算法。

进一步，所述监测模块还用于对所述软总线上预设成员在单位时间内的最大消息量、掉线频率以及网络质量进行监测。

进一步，所述优化模块，具体用于：在所述事件的类型为对象事件的情况下，按照如下公式确定向预设成员发送的心跳报文的发送频率： 其中，R_m为所述预设成员在单位时间内的消息余量与所述预设成员在单位时间内的最大消息量的比值，R_o为所述预设成员在单位时间内的掉线频率，R_q为所述预设成员在单位时间内的网络质量，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率；按照所述优化之后的心跳报文的发送频率向所述预设成员发送心跳报文。

进一步，所述优化模块，具体用于：在所述事件的类型为服务事件的情况下，遍历所述软总线中订阅预设消息的所有成员的端口信息、多播历史丢包率和UDP历史丢包率；根据所述端口信息判断所述所有成员中预设成员是否支持多播方式；在所述预设成员支持多播方式且所述预设成员的多播历史丢包率小于第一阈值的情况下，将所述预设成员的消息订阅方式调整为多播方式；在所述预设成员不支持多播方式或所述预设成员的多播历史丢包率大于或等于所述第一阈值的情况下，判断所述预设成员是否支持UDP方式；在所述预设成员支持UDP方式且所述预设成员的UDP历史丢包率小于第二阈值的情况下，将所述预设成员的消息订阅方式调整为UDP方式；在所述预设成员不支持UDP方式或所述成员的UDP历史丢包率大于或等于所述第二阈值的情况下，将所述预设成员的消息订阅方式调整为TCP方式。

进一步，所述优化模块，具体用于：在所述事件的类型为服务事件的情况下，遍历所述软总线中订阅预设消息的预定成员的端口信息，并根据所述端口信息判断所述端口信息对应的端口是否支持多播方式；在所述端口支持多播方式的情况下，判断预设消息缓存表中是否存在与所述预设成员存在相同端口信息的其它成员，并在存在与所述预设成员存在相同端口信息的其它成员的情况下，将所述预设成员的端口信息与所述其它成员的端口信息合并，在不存在与所述预设成员存在相同端口信息的其它成员的情况下，在所述消息缓存表中所述预设消息对应的缓存数据中添加所述端口信息；在所述端口不支持多播方式的情况下，判断所述端口是否支持UDP方式，并在所述端口支持UDP方式的情况下，在所述缓存数据下添加以UDP方式订阅所述预设消息的端口信息；在所述端口不支持UDP方式的情况下，在所述缓存数据下添加以TCP方式订阅所述预设消息的端口信息。

本发明通过监测软总线上的新增事件类型，根据不同事件类型使用不同的优化算法对软总线的管理行为进行调整，达到减少软总线的资源占用率的目的，解决了现有技术中软总线资源占用率高的问题。

附图说明

图1是本发明第一实施例中软总线管理方法的流程图；

图2是本发明第二实施例中软总线管理装置的结构示意图；

图3是本发明第三实施例中软总线管理优化流程示意图。

具体实施方式

为了解决现有技术中软总线资源占用率高的问题，本发明提供了一种软总线管理方法与装置，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

本发明的第一实施例提供了一种软总线管理方法，其方法流程图如图1所示，包括步骤S101和S102：

S101，监测软总线上新增事件的类型，其中，事件的类型包括：对象事件和服务事件；

S102，使用与事件的类型相对应的预设优化算法对软总线的管理行为进行调整，其中，对象事件对应的预设优化算法为成员管理优化算法，服务事件对应的预设优化算法为消息订阅分发优化算法。

软总线的新增事件可分为对象事件和服务事件两类。其中，对象事件包括软总线成员的接入和断开，服务事件包括软总线成员新增、变更和取消对某类型消息的订阅事件。

由于软总线需要对当前接入到软总线中的成员进行管理和监控，其中监控行为包括但不限于对成员接入/断开总线、加入/退出成员组等行为的监控，为了达到更好的成员监控目的，在事件的类型为对象事件的情况下，使用与事件的类型相对应的预设优化算法，即成员管理优化算法对软总线的管理行为进行调整，包括：

按照如下公式确定向预设成员发送的心跳报文的发送频率：

其中，R_m为预设成员在单位时间内的消息余量与预设成员在单位时间内的最大消息量的比值，R_o为预设成员在单位时间内的掉线频率，R_q为预设成员在单位时间内的网络质量，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率；在确定优化之后的心跳报文的发送频率后，按照优化之后的心跳报文的发送频率向预设成员发送心跳报文。优选地，在进行心跳报文发送频率的优化之前，还需要对软总线上预设成员在单位时间内的最大消息量、掉线频率以及网络质量进行监测，并使用不断监测更新的上述数据对心跳报文发送频率进行优化。

可选地，R_m的计算方法为：

其中，Msg_max表示该成员单位时间内能够处理的最大消息量，Msg_curren表示该成员当前处理的消息数量；

R_o的计算方法为：

其中，Count_max表示软总线在单位时间内能够容忍该成员掉线次数的最大值，Count_current表示该成员在单位时间内实际掉线的次数，掉线次数的计算为将其他成员上报的该成员的掉线情况进行累加求和；

R_q的计算方法为：

其中，Delay_max表示软总线设定的该成员延迟的最大值，Delay_current表示该成员单位时间内延迟的平均值，平均值的计算方法为该成员与其他所有成员网络延迟的算数平均值。

在本实施例中，单位时间均为1分钟，在实际情况下，可以根据需求进行自定义单位时间。

成员在接入到软总线后，按照其自身需求指定订阅的消息类型，同时有能力产生所有类型的消息，一般只根据功能需要产生特定类型的消息即可。软总线根据所有成员对不同消息的订阅情况建立消息缓存表以保存发布订阅关系，同时软总线负责将成员产生的消息按照消息缓存表的发布订阅关系分发给订阅该类型消息的成员。软总线支持一个成员在本机的一组端口(Endpoint)上提供订阅服务，端口中包含传输控制协议(TCP，Transmission Control Protocol)、用户数据报协议(UDP，User Datagram Protocol)和网际协议多播(简称多播，multicast)中的一种或多种通信方式的端口信息，并存储在发布消息缓存表中。TCP方式没有消息的丢包，但是占用软总线资源较多，传输消息量小，多播和UDP方式存在一定程度的丢包，但是占用总线资源较少，传输消息量大。为了减少软总线资源的占用率，在事件的类型为服务事件的情况下使用与事件的类型相对应的预设优化算法，即消息订阅分发优化算法对软总线的管理行为进行调整，包括：

S11，遍历软总线中订阅预设消息的所有成员的端口信息、多播历史丢包率和UDP历史丢包率；

S12，根据端口信息判断所有成员中预设成员是否支持多播方式；

S13，在预设成员支持多播方式且预设成员的多播历史丢包率小于第一阈值的情况下，将预设成员的消息订阅方式调整为多播方式；

S14，在预设成员不支持多播方式或预设成员的多播历史丢包率大于或等于第一阈值的情况下，判断预设成员是否支持UDP方式；

S15，在预设成员支持UDP方式且预设成员的UDP历史丢包率小于第二阈值的情况下，将预设成员的消息订阅方式调整为UDP方式；

S16，在预设成员不支持UDP方式或成员的UDP历史丢包率大于或等于第二阈值的情况下，将预设成员的消息订阅方式调整为TCP方式。

应当了解的是，每个成员的历史丢包率均为定期统计的，第一阈值和第二阈值可以由软总线自行设定合理的数值范围。

进一步地，在事件的类型为服务事件的情况下使用消息订阅分发优化算法对软总线的管理行为进行调整，还包括：

S21，遍历软总线中订阅预设消息的预定成员的端口信息，并根据端口信息判断端口信息对应的端口是否支持多播方式；

S22，在端口支持多播方式的情况下，判断预设消息缓存表中是否存在与预设成员存在相同端口信息的其它成员，并在存在与预设成员存在相同端口信息的其它成员的情况下，将预设成员的端口信息与其它成员的端口信息合并，在不存在与预设成员存在相同端口信息的其它成员的情况下，在消息缓存表中预设消息对应的缓存数据中添加端口信息；

S23，在端口不支持多播方式的情况下，判断端口是否支持UDP方式，并在端口支持UDP方式的情况下，在缓存数据下添加以UDP方式订阅预设消息的端口信息；在端口不支持UDP方式的情况下，在缓存数据下添加以TCP方式订阅预设消息的端口信息。

应当了解的是，本实施例中所涉及的所有预设成员，可以为新接入到软总线的成员，也可以为已经接入到软总线中成员。

本实施例通过监测软总线上的新增事件类型，根据不同事件类型使用不同的优化算法对软总线的管理行为进行调整，达到减少软总线的资源占用率，解决了现有技术中软总线资源占用率高的问题。

本发明的第二实施例提供了一种软总线管理装置，其结构示意图如图2所示。

图2中示出软总线管理装置包括互相耦合的监测模块201和优化模块202。其中，监测模块201用于监测软总线上新增事件的类型，其中，事件的类型包括：对象事件和服务事件；优化模块202用于使用与事件的类型相对应的预设优化算法对软总线的管理行为进行调整，其中，对象事件对应的预设优化算法为成员管理优化算法，服务事件对应的预设优化算法为消息订阅分发优化算法。

进一步地，优化模块202具体用于在事件的类型为对象事件的情况下，按照如下公式确定向预设成员发送的心跳报文的发送频率：

其中，R_m为预设成员在单位时间内的消息余量与预设成员在单位时间内的最大消息量的比值，R_o为预设成员在单位时间内的掉线频率，R_q为预设成员在单位时间内的网络质量，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率；在确定优化之后的心跳报文的发送频率后，按照优化之后的心跳报文的发送频率向预设成员发送心跳报文。优选地，监测模块201还用于对软总线上预设成员在单位时间内的最大消息量、掉线频率以及网络质量进行监测，并使用不断监测更新的上述数据对心跳报文发送频率进行优化。

可选地，R_m的计算方法为：

其中，Msg_max表示该成员单位时间内能够处理的最大消息量，Msg_curren表示该成员当前处理的消息数量；

R_o的计算方法为：

其中，Count_max表示软总线在单位时间内能够容忍该成员掉线次数的最大值，Count_current表示该成员在单位时间内实际掉线的次数，掉线次数的计算为将其他成员上报的该成员的掉线情况进行累加求和；

R_q的计算方法为：

其中，Delay_max表示软总线设定的该成员延迟的最大值，Delay_current表示该成员单位时间内延迟的平均值，平均值的计算方法为该成员与其他所有成员网络延迟的算数平均值。

在本实施例中，单位时间均为1分钟，在实际情况下，可以根据需求进行自定义单位时间。

成员在接入到软总线后，按照其自身需求指定订阅的消息类型，同时有能力产生所有类型的消息，一般只根据功能需要产生特定类型的消息即可。软总线根据所有成员对不同消息的订阅情况建立消息缓存表以保存发布订阅关系，同时软总线负责将成员产生的消息按照消息缓存表的发布订阅关系分发给订阅该类型消息的成员。软总线支持一个成员在本机的一组端口(Endpoint)上提供订阅服务，端口中包含传输控制协议(TCP，Transmission Control Protocol)、用户数据报协议(UDP，User Datagram Protocol)和网际协议多播(简称多播)中的一种或多种通信方式的端口信息，并存储在发布消息缓存表中。TCP方式没有消息的丢包，但是占用软总线资源较多，传输消息量小，多播和UDP方式存在一定程度的丢包，但是占用总线资源较少，传输消息量大。为了减少软总线资源的占用率，优化模块202还用于：

S31，在所述事件的类型为服务事件的情况下，遍历软总线中订阅预设消息的所有成员的端口信息、多播历史丢包率和UDP历史丢包率；

S32，根据端口信息判断所有成员中预设成员是否支持多播方式；

S33，在预设成员支持多播方式且预设成员的多播历史丢包率小于第一阈值的情况下，将预设成员的消息订阅方式调整为多播方式；

S34，在预设成员不支持多播方式或预设成员的多播历史丢包率大于或等于第一阈值的情况下，判断预设成员是否支持UDP方式；

S35，在预设成员支持UDP方式且预设成员的UDP历史丢包率小于第二阈值的情况下，将预设成员的消息订阅方式调整为UDP方式；

S36，在预设成员不支持UDP方式或成员的UDP历史丢包率大于或等于第二阈值的情况下，将预设成员的消息订阅方式调整为TCP方式。

应当了解的是，每个成员的历史丢包率均为定期统计的，第一阈值和第二阈值可以由软总线自行设定合理的数值范围。

进一步地，优化模块202还用于：

S41，在所述事件的类型为服务事件的情况下，遍历软总线中订阅预设消息的预定成员的端口信息，并根据端口信息判断端口信息对应的端口是否支持多播方式；

S42，在端口支持多播方式的情况下，判断预设消息缓存表中是否存在与预设成员存在相同端口信息的其它成员，并在存在与预设成员存在相同端口信息的其它成员的情况下，将预设成员的端口信息与其它成员的端口信息合并，在不存在与预设成员存在相同端口信息的其它成员的情况下，在消息缓存表中预设消息对应的缓存数据中添加端口信息；

S43，在端口不支持多播方式的情况下，判断端口是否支持UDP方式，并在端口支持UDP方式的情况下，在缓存数据下添加以UDP方式订阅预设消息的端口信息；在端口不支持UDP方式的情况下，在缓存数据下添加以TCP方式订阅预设消息的端口信息。

应当了解的是，本实施例中所涉及的所有预设成员，可以为新接入到软总线的成员，也可以为已经接入到软总线中成员。

本实施例通过监测软总线上的新增事件类型，根据不同事件类型使用不同到的优化算法对软总线的管理行为进行调整，达到减少软总线的资源占用率，解决了现有技术中软总线资源占用率高的问题。

下面将结合图3对本发明的第三实施例的软总线优化过程进行详细的描述。

软总线的新增事件可分为对象事件和服务事件两类。其中，对象事件包括软总线成员的接入和断开，服务事件包括软总线成员新增、变更和取消对某类型消息的订阅事件。软总线通过实时监测对象事件和服务事件的出现，并在相应事件出现的时候进行相应的管理行为决策，主要包括确定向软总线上成员发送心跳报文的频率、如何更新消息缓存表等，在软总线根据管理行为决策的结果进行执行后，还需要对软总线成员在单位时间内的最大消息量、掉线频率以及网络质量等信息进行监测，并通过优化算法根据监测结果实时调整管理行为决策的结果，使软总线以更优化的方式进行运转。

例如，成员管理优化算法实现了变频心跳监测成员在线状态，通过监控每个总线成员节点的以下三类信息来完成对心跳报文发送频率的调整：

1、当前消息余量占该节点能够提供的最大消息量的比值R_m(RateOfMsg)；

2、单位时间内成员的掉线频率R_o(RateOfOffline)；

3、单位时间内成员的网络质量R_q(QualityOfNet，相当于本发明第一实施例的网络延迟)；

优选地，R_m的计算方法为：

其中，Msg_max表示该成员单位时间内能够处理的最大消息量，Msg_curren表示该成员当前处理的消息数量；

R_o的计算方法为：

其中，Count_max表示软总线在单位时间内能够容忍该成员掉线次数的最大值，Count_current表示该成员在单位时间内实际掉线的次数，掉线次数的计算为将其他成员上报的该成员的掉线情况进行累加求和；

R_q的计算方法为：

其中，Delay_max表示软总线设定的该成员延迟的最大值，Delay_current表示该成员单位时间内延迟的平均值，平均值的计算方法为该成员与其他所有成员网络延迟的算数平均值。

在计算出上述三类信息的具体数值之后，利用如下公式对心跳报文的发送频率进行优化：

其中，，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率，除以3表示归一化。

消息订阅分发优化算法主要从三方面进行优化，

(a)动态改变消息的订阅分发方式；

(b)将多个成员对相同消息的不同订阅方式进行合并；

(c)采用三级缓存的结构维护成员本地的“订阅/发布”关系表(相当于本发明第一实施例中的消息缓存表)。

在本实施例中，软总线会定期统计当前所有成员的三种分发方式的历史丢包率，同时会统计每一类消息被不同成员订阅的方式，用户可以在发布消息的时候选择是否需要软总线进行优化。如果需要，则软总线会自动根据当前该成员的历史丢包率和不同成员的订阅方式对消息的订阅方式进行自动的优化，以达到减少资源占用的目的。其中，历史丢包率会有一个初始值，上述初始值由实验人员或软总线自行设定。

当不同成员以不同的方式订阅某一种消息时，在数据分发的过程中出现同一消息发送多次才能覆盖所有成员，会造成消息发送的网络资源浪费。所以，在本实施例中，软总线将多个成员对相同消息的不同订阅方式进行合并，例如：成员甲对消息MSG1的订阅方式在Endpoint上表示为：

MSG1：udp 70.3.1.150:11001；multicast 239.255.1.1:12000；

新增的成员乙对消息MSG1的订阅方式在Endpoint上表示为：

MSG1：multicast 239.255.1.1:12000

由于成员乙的端口信息中“multicast 239.255.1.1:12000”与成员甲的端口信息相同，所以，合并成员甲和成员乙的消息订阅方式，即MSG1在进行分发时，只需要以多播方式通过地址为239.255.1.1的端口12000发送一次，成员甲和成员乙均能收到MSG1，减少了消息分发的次数，进而减少了软总线的资源占用。

软总线上每个成员在其本地均会保存有发布订阅关系表(相当于本发明第一实施例中的消息缓存表)，用于存储该成员与其他成员之间的消息订阅分发关系。本发明的实施例中，采用三级缓存结构管理成员发布订阅关系表，解决了传统的消息订阅关系维护的不足：仿真运行过程中动态变更消息订阅方式时，消息订阅和消息分发线程相互堵塞的问题。

本实施例中，发布订阅关系表的第一级缓存以消息名称为索引，保存各个消息有哪些成员订阅，同时保存这些成员最新的订阅时间和端口信息；第二级缓存在第一级缓存的基础上，合并出每个消息的有效端口集合，并跟随第一级缓存的变化而变化；第三级缓存在第二级缓存的基础上，准备每个消息可以直接使用的远程过程调用协议(RPC，RemoteProcedure Call Protocol)对象。当应用层需要发送数据时，直接在本级获取RPC对象集合，完成发送即可。

所有的消息最后直接查找第三级缓存表进行消息的发送，通过第一级表对消息的缓存，第二级表对消息订阅方式的优化和合并，当仿真运行过程中某个消息订阅关系发生变化时，第三级表会发生较少的变动，而不是每一个成员有消息订阅方式发生变动时消息订阅分发表都要发生变动，这样消息订阅和消息分发线程就会发生更少相互堵塞，提升了总线的性能。

尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。

Claims (10)

1.一种软总线管理方法，其特征在于，包括：

监测软总线上新增事件的类型，其中，所述事件的类型包括：对象事件和服务事件；

使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，其中，所述对象事件对应的预设优化算法为成员管理优化算法，所述服务事件对应的预设优化算法为消息订阅分发优化算法。

2.如权利要求1所述的软总线管理方法，其特征在于，使用与所述事件的类型相对应的优化算法对所述软总线的管理行为进行调整之前，还包括：

对所述软总线上预设成员在单位时间内的最大消息量、掉线频率以及网络质量进行监测。

3.如权利要求2所述的软总线管理方法，其特征在于，在所述事件的类型为对象事件的情况下，使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，包括：

按照如下公式确定向预设成员发送的心跳报文的发送频率： 其中，R_m为所述预设成员在单位时间内的消息余量与所述预设成员在单位时间内的最大消息量的比值，R_o为所述预设成员在单位时间内的掉线频率，R_q为所述预设成员在单位时间内的网络质量，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率；

按照所述优化之后的心跳报文的发送频率向所述预设成员发送心跳报文。

4.如权利要求1所述的软总线管理方法，其特征在于，在所述事件的类型为服务事件的情况下，使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，包括：

遍历所述软总线中订阅预设消息的所有成员的端口信息、多播历史丢包率和UDP历史丢包率；

根据所述端口信息判断所述所有成员中预设成员是否支持多播方式；

在所述预设成员支持多播方式且所述预设成员的多播历史丢包率小于第一阈值的情况下，将所述预设成员的消息订阅方式调整为多播方式；

在所述预设成员不支持多播方式或所述预设成员的多播历史丢包率大于或等于所述第一阈值的情况下，判断所述预设成员是否支持UDP方式；

在所述预设成员支持UDP方式且所述预设成员的UDP历史丢包率小于第二阈值的情况下，将所述预设成员的消息订阅方式调整为UDP方式；

在所述预设成员不支持UDP方式或所述成员的UDP历史丢包率大于或等于所述第二阈值的情况下，将所述预设成员的消息订阅方式调整为TCP方式。

5.如权利要求4所述的软总线管理方法，其特征在于，在所述事件的类型为服务事件的情况下，使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，包括：

遍历所述软总线中订阅预设消息的预定成员的端口信息，并根据所述端口信息判断所述端口信息对应的端口是否支持多播方式；

在所述端口支持多播方式的情况下，判断预设消息缓存表中是否存在与所述预设成员存在相同端口信息的其它成员，并在存在与所述预设成员存在相同端口信息的其它成员的情况下，将所述预设成员的端口信息与所述其它成员的端口信息合并，在不存在与所述预设成员存在相同端口信息的其它成员的情况下，在所述消息缓存表中所述预设消息对应的缓存数据中添加所述端口信息；

在所述端口不支持多播方式的情况下，判断所述端口是否支持UDP方式，并在所述端口支持UDP方式的情况下，在所述缓存数据下添加以UDP方式订阅所述预设消息的端口信息；在所述端口不支持UDP方式的情况下，在所述缓存数据下添加以TCP方式订阅所述预设消息的端口信息。

6.一种软总线管理装置，其特征在于，包括：

监测模块，用于监测软总线上新增事件的类型，其中，所述事件的类型包括：对象事件和服务事件；

优化模块，用于使用与所述事件的类型相对应的预设优化算法对所述软总线的管理行为进行调整，其中，所述对象事件对应的预设优化算法为成员管理优化算法，所述服务事件对应的预设优化算法为消息订阅分发优化算法。

7.如权利要求6所述的软总线管理装置，其特征在于，所述监测模块还用于对所述软总线上预设成员在单位时间内的最大消息量、掉线频率以及网络质量进行监测。

8.如权利要求7所述的软总线管理装置，其特征在于，所述优化模块，具体用于：

在所述事件的类型为对象事件的情况下，按照如下公式确定向预设成员发送的心跳报文的发送频率：其中，R_m为所述预设成员在单位时间内的消息余量与所述预设成员在单位时间内的最大消息量的比值，R_o为所述预设成员在单位时间内的掉线频率，R_q为所述预设成员在单位时间内的网络质量，H_d为心跳报文的默认发送频率，H_f为优化之后的心跳报文的发送频率；

按照所述优化之后的心跳报文的发送频率向所述预设成员发送心跳报文。

9.如权利要求6所述的软总线管理装置，其特征在于，所述优化模块，具体用于：

在所述事件的类型为服务事件的情况下，遍历所述软总线中订阅预设消息的所有成员的端口信息、多播历史丢包率和UDP历史丢包率；

根据所述端口信息判断所述所有成员中预设成员是否支持多播方式；

在所述预设成员支持多播方式且所述预设成员的多播历史丢包率小于第一阈值的情况下，将所述预设成员的消息订阅方式调整为多播方式；

在所述预设成员不支持多播方式或所述预设成员的多播历史丢包率大于或等于所述第一阈值的情况下，判断所述预设成员是否支持UDP方式；

在所述预设成员支持UDP方式且所述预设成员的UDP历史丢包率小于第二阈值的情况下，将所述预设成员的消息订阅方式调整为UDP方式；

在所述预设成员不支持UDP方式或所述成员的UDP历史丢包率大于或等于所述第二阈值的情况下，将所述预设成员的消息订阅方式调整为TCP方式。

10.如权利要求6所述的软总线管理装置，其特征在于，所述优化模块，具体用于：

在所述事件的类型为服务事件的情况下，遍历所述软总线中订阅预设消息的预定成员的端口信息，并根据所述端口信息判断所述端口信息对应的端口是否支持多播方式；

在所述端口支持多播方式的情况下，判断预设消息缓存表中是否存在与所述预设成员存在相同端口信息的其它成员，并在存在与所述预设成员存在相同端口信息的其它成员的情况下，将所述预设成员的端口信息与所述其它成员的端口信息合并，在不存在与所述预设成员存在相同端口信息的其它成员的情况下，在所述消息缓存表中所述预设消息对应的缓存数据中添加所述端口信息；

在所述端口不支持多播方式的情况下，判断所述端口是否支持UDP方式，并在所述端口支持UDP方式的情况下，在所述缓存数据下添加以UDP方式订阅所述预设消息的端口信息；在所述端口不支持UDP方式的情况下，在所述缓存数据下添加以TCP方式订阅所述预设消息的端口信息。