CN112187407A - 实时信令消息处理方法、装置、设备及计算机存储介质 - Google Patents

Abstract

本发明实施例提供了一种实时信令消息处理方法、装置、设备及计算机存储介质，该方法包括：获取第一实时信令消息；筛除第一实时信令消息中符合预设筛除规则的实时信令消息，以生成第二实时信令消息；获取用户信息；根据用户信息和第二实时信息消息的匹配情况，确定满足发送条件的用户信息；将第二实时信令消息发送至满足发送条件的用户信息对应的用户；本发明实施例能够解决实时信令消息数据量较大时产生的高延迟问题。

Description

实时信令消息处理方法、装置、设备及计算机存储介质

技术领域

本发明属于通信网络业务支撑领域，尤其涉及一种实时信令消息处理方法、装置、设备及计算机存储介质。

背景技术

随着科技的日益发展，国内电信运营商之间的竞争不断加剧，加大营销力度，是提升竞争力的有效手段；近年来在大数据领域技术发展迅速，基于大数据的数字营销成为可能，也是未来运营商面临的重要挑战之一。其中包括支撑技术方面，也包括内容的转型，从运营商仅提供基础电信服务，再过渡到内容经营上来，近年来运营商之间抢占线上客户的时间和注意力的竞争也日益激烈，因此内容营销变得至关重要。为了帮助大家使用客户化的语言，精心围绕客户需求的内容来取得竞争优势，赢得更好的品牌曝光，赢得更好的销售业绩转化。基于上述背景，大数据技术结合数字化内容成为运营商的重要研究方向。

但是现有的基于大数据技术结合数字化内容的方法在处理实时信令数据量较大的应用场景时，会出现数据积压从而导致消息提醒延迟的情况。

发明内容

本发明实施例提供一种在实时信令消息处理方法、装置、设备及计算机存储介质，能够解决实时信令消息数据量较大时产生的高延迟问题。

第一方面，本发明实施例提供一种实时信令消息处理方法，该方法包括：

获取第一实时信令消息；

筛除第一实时信令消息中符合预设筛除规则的实时信令消息，以生成第二实时信令消息；

获取用户信息；

根据用户信息和第二实时信息消息的匹配情况，确定满足发送条件的用户信息；

将第二实时信令消息发送至满足发送条件的用户信息对应的用户。

进一步地，在一种实施例中，第一实时信令消息包括多个日志文件，该方法还包括：

预存多个日志文件的标签信息列表；

当网络中断并重启后，从标签信息列表中确定网络中断前已获取的最后一个日志文件对应的第一标签信息；

从标签信息列表中确定当前待传输的日志文件对应的第二标签信息；

根据第一标签信息和第二标签信息确定续取策略；

根据续取策略继续获取第一实时信令消息。

进一步地，在一种实施例中，筛除第一实时信令消息中符合预设筛除规则的实时信令消息，以生成第二实时信令消息，包括：

将第一实时信令消息转换为流数据；

将流数据拆分为多个子流数据；

将多个子流数据分别发送至不同数据节点，以供数据节点筛除子流数据中符合预设筛除规则的数据；

将经过筛除数据的多个子流数据进行汇总，以生成第二实时信令消息。

进一步地，在一种实施例中，预设筛除规则，包括：

子流数据的特征字段不满足预设的特征字段格式；和/或，

子流数据的时间戳过期。

进一步地，在一种实施例中，根据用户信息和第二实时信息消息的匹配情况，确定满足发送条件的用户信息，包括：

获取用户位置信息，及第二实时信令消息的发送范围；

筛除用户位置信息不在发送范围内的用户信息。

第二方面，本申请实施例提供一种实时信令消息处理装置，该装置包括：

获取模块，用于获取第一实时信令消息；

生成模块，用于筛除第一实时信令消息中符合预设筛除规则的实时信令消息，以生成第二实时信令消息；

获取模块，还用于获取用户信息；

确定模块，还用于根据用户信息和第二实时信息消息的匹配情况，确定满足发送条件的用户信息；

发送模块，用于将第二实时信令消息发送至满足发送条件的用户信息对应的用户。

进一步地，在一种实施例中，第一实时信令消息包括多个日志文件，该装置还包括：预存模块；

预存模块，用于预存多个日志文件的标签信息列表；

确定模块，用于当网络中断并重启后，从标签信息列表中确定网络中断前已获取的最后一个日志文件对应的第一标签信息；

确定模块，还用于从标签信息列表中确定当前待传输的日志文件对应的第二标签信息；

确定模块，还用于根据第一标签信息和第二标签信息确定续取策略；

获取模块，还用于根据续取策略继续获取第一实时信令消息。

进一步地，在一种实施例中，生成模块，具体用于：

将第一实时信令消息转换为流数据；

将流数据拆分为多个子流数据；

将多个子流数据分别发送至不同数据节点，以供数据节点筛除子流数据中符合预设筛除规则的数据；

将经过筛除数据的多个子流数据进行汇总，以生成第二实时信令消息。

第三方面，本申请实施例提供一种实时信令消息处理设备，该设备包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，计算机程序被处理器执行时实现实时信令消息处理方法。

第四方面，本身实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有信息传递的实现程序，程序被处理器执行时实现实时信令消息处理方法。

本发明实施例的实时信令消息处理方法、装置、设备及计算机存储介质，首先基于预设筛出规则进行第一实时信令消息的分拣，进而生成第二实时信令消息，避免发送不必要的实时信令消息，从而避免了数据链超出计算资源负荷时形成数据积压进而导致消息提醒延迟较长的情况，保证信令消息推送的及时性；然后根据用户信息与第二实时信令消息的匹配性进行相应发送，保证信令消息推送的准确性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一个实施例提供的实时消息提醒系统架构图；

图2是本发明一个实施例提供的实时信令消息处理方法的流程示意图；

图3-a是本发明一个实施例提供的第一信令拦截方案的流程示意图；

图3-b是本发明一个实施例提供的第二信令拦截方案的流程示意图；

图4是本发明一个实施例提供的信令断点续采方案的流程示意图；

图5是本发明一个实施例提供的实时信令消息处理装置的结构示意图；

图6是本发明一个实施例提供的实时信令消息处理设备的结构示意图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例，为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本发明进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本发明，并不被配置为限定本发明。对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

现有的基于大数据技术结合数字化内容的方法在处理实时信令数据量较大的应用场景时，会出现数据积压从而导致消息提醒延迟的情况。例如，申请号为CN201811058166.3的专利申请提供了一种基于网络数据的分布式实时营销系统和方法，该方法包括：收集原始网络数据；分析处理原始网络数据，形成交易信息和交易行为；令交易信息和交易行为推送至指定目标；接收交易信息和交易行为，令交易信息和交易行为与营销产品匹配，获得匹配后的营销产品信息，发送至营销产品推荐与展示模块；接收匹配后的营销产品信息，令匹配后的产品信息发送至终端设备或展示。通过对网络数据的实时采集处理，并实时发送到营销平台，并实施智能匹配，体现网络营销实时性；适用于用户行为及交易的所有环节，对业务系统无依赖性，适用于不同的业务系统和平台；无需对业务系统进行改造，即刻上线投产，无需侵入到业务系统，且不会对业务系统造成性能影响。

首先，上述专利未对实时信令消息(原始网络数据)进行分拣，当数据量超出计算资源超负荷时，会出现数据积压从而导致消息提醒延迟较高的情况；其次，上述专利未对当采集位置数据出现断点时进行断点续采的方法设计，如不能断点续采则将需要重新采集全部原始网络数据，继而导致数据积压和资源的浪费。

为了解决现有技术问题，本申请实施例提供了一种实时消息提醒系统，图1示出了该系统架构图，如图1所示，相较于现有的实时消息提醒系统，本申请提出的实时消息提醒系统依托大数据平台，对位置提醒功能进行改造，在前端对B域(business support system的数据域，有用户数据和业务数据，比如用户的消费习惯、终端信息、ARPU的分组、业务内容，业务受众人群等)和O域(operation support system的数据域，O域有网络数据，比如信令、告警、故障、网络资源等)进行数据整合，减少数据输入量；优化高速缓冲存储器(cache)命中，增加相关事件日志留痕，增加作业质量控制模块识别上游系统异常数据并及时告警，保障业务质量。提升省内实时信息提醒中心应用能力，增加省外移动用户位置实时提醒服务，扩大公共安全短信提醒受众范围；增加对接云移动代理服务器(Mobile Agent Server，MAS)平台，以实现提醒短信收费，在满足政府、管局业务需求的同时，实现市县政府对实时场景短信的有偿服务，为集团客户部拓宽信息化收入来源提供支撑能力。

基于本申请实施例提供的实时消息提醒系统。本发明实施例提供了一种实时信令消息处理方法、装置、设备及计算机存储介质。本申请的实施例首先基于预设筛出规则进行第一实时信令消息的分拣，进而生成第二实时信令消息，避免发送不必要的实时信令消息，从而避免了数据链超出计算资源负荷时形成数据积压进而导致消息提醒延迟较长的情况，保证信令消息推送的及时性；然后根据用户信息与第二实时信令消息的匹配性进行相应发送，保证信令消息推送的准确性。下面首先对本发明实施例所提供的实时信令消息处理方法进行介绍。

图2示出了本发明一个实施例提供的实时信令消息处理方法的流程示意图。该方法的执行主体可以是消息中间件，该消息中间件包括：Kafka平台、日志收集系统Flume、以及计算引擎Spark。如图2所示，该方法可以包括以下步骤：

S200，获取第一实时信令消息。

第一实时信令消息来源于大数据平台的O域数据和B域数据，O域数据和B域数据的数据类型包括移动管理节点功能(Mobility Management Entity，MME)信令、切换(Handover，HO)信令、以及移动管理(Mobility Management，MM)信令。在该步骤实际应用时，可基于上述三类信令分别形成相应的独立主题，并基于独立主体对信令字段进行裁剪，以形成第一实时信令消息。

S202，筛除第一实时信令消息中符合预设筛除规则的实时信令消息，以生成第二实时信令消息。

该步骤可基于分布式计算框架进行信令消息的筛除。

在一种实施例中，S202提供了一种第一信令拦截方案，图3-a示出了第一信令拦截方案的流程示意图，如图3-a所示，S202可以包括：

S2020，将第一实时信令消息转换为流数据；

S2022，将流数据拆分为多个子流数据；

S2024，将多个子流数据分别发送至不同数据节点，以供数据节点筛除子流数据中符合预设筛除规则的数据。

为了实现大规模的并行实时计算，通过分布式计算框架将第一实时信令消息转换为流数据，将一个大计算任务(流数据)拆分成多个小计算任务(子流数据)分布到若干个数据节点进行计算进而筛除子流数据中符合预设筛除规则的数据，提高了海量数据处理能力。并且该分布式计算框架还设有分布式锁机制，保证了每批次计算结果的唯一性，避免同一数据多次提交。

在一种实施例中，该预设筛除规则，包括：

子流数据的特征字段不满足预设的特征字段格式，和/或，子流数据的时间戳过期。

预设的特征字段格式可以包括：信令类型、时间戳、地市、号码、国际移动设备识别码(International Mobile Equipment Identity，IMEI)、国际移动用户识别码(International Mobile Subscriber Identity，IMSI)、位置区码(location area code，LAC)、跟踪区码(Tracking Area Code，TAC)、小区识别码(Cell Identity，CI)、应用程序(application，APP)大类、APP小类、主叫号码、被叫号码、发短信、以及收短信。

基于预设的特征字段格式筛除子流数据后，可以将经过筛除的子流数据存储在日志收集系统Flume中，然后Kafaka从Flume中获取第二实时信令消息，并基于第二实时信令消息配置Kafaka的标题信息topic，计算引擎Spark基于topic计算子流数据的时间戳，筛除时间戳过期的子流数据。

将经过筛除数据的多个子流数据进行汇总，以生成第二实时信令消息。

S204，获取用户信息。

S206，根据用户信息和第二实时信息消息的匹配情况，确定满足发送条件的用户信息。

在一种实施例中，S206提供了一种第二信令拦截方案，图3-b示出了第二信令拦截方案的流程示意图，如图3-b所示，S206可以包括：

S2060，获取用户位置信息，及第二实时信令消息的发送范围。

用户位置信息可以从大数据平台获取，该用户位置信息包括用户所属的LAC和CI。

基于该用户所属的LAC和CI能够获取用户所处的场景，例如，景区、机场、以及住宅区等。

S2062，筛除用户位置信息不在发送范围内的用户信息。

将用户所处的场景与第二实时信令消息的发送范围进行比对即可实现用户信息的筛除。

在一种实施例中，在筛除用户位置信息不在发送范围内的用户信息前，该S206还可以包括：

获取用户的号码信息。

根据用户的号码信息判断用户所属省份，并进行标记。

进而实现对外省来访人员的识别。

在一种实施例中，S206还可以包括：

根据预设的防打扰规则确定匹配第二实时消息的多个用户信息，筛除该多个用户信息中属于预设黑名单中的用户信息，最终确定满足发送条件的用户信息。

S208，将第二实时信令消息发送至满足发送条件的用户信息对应的用户。

在一种实施例中，第一实时信令消息包括多个日志文件，本申请提供的方法还包括了一种信令断点续采方案，图4示出了该信令断点续采方案的流程示意图，如图4所示，该方案可以包括：

S210，预存多个日志文件的标签信息列表。

S212，当网络中断并重启后，从标签信息列表中确定网络中断前已获取的最后一个日志文件对应的第一标签信息。

S214，从标签信息列表中确定当前待传输的日志文件对应的第二标签信息。

S216，根据第一标签信息和第二标签信息确定续取策略。

S218，根据续取策略继续获取第一实时信令消息。

具体的，在Kafka获取到第一实时信令消息后，可将日志文件的全部标签信息以列表的形式记录到记录(Record)文件，该标签信息包括日志文件的标签和日志文件的行号；例如日志文件的某一行的标签信息可以是：debug.log，2019-09-18-1，265。第一个字段为日志文件的标签，第二个字段为时间槽或者该行的最后修改的long型毫秒时间，第三个字段为该行的行数。

当网络中断并重启后，从Rceord文件的标签信息列表中读取网络中断前已获取的最后一个日志文件对应的第一标签信息、再读取当前待传输的日志文件对应的第二标签信息；

根据第一标签信息和第二标签信息确定续取策略，根据续取策略继续获取第一实时信令消息。

续取策略包括：

当第一标签信息与第二标签信息对应的两个日志文件相同，且第一标签信息中的最后一个行数信息与第二标签信息中的第一个行数信息差距小于预设个数(具体可以根据实际应用需求配置，例如设为1000)时，直接从Flume从第一标签信息中的最后一个行数信息加一的行数信息对应的日志文件开始续取日志文件，其命令为tail-f-n+${上次抽完的行号+1}--pid${flume的进程号}debug.log。

当第一标签信息与第二标签信息对应的两个日志文件相同，且第一标签信息中的最后一个行数信息与第二标签信息中的第一个行数信息差距大于预设个数；或者第一标签信息与第二标签信息对应的两个日志文件不同时，直接基于第二标签信息中的第一个行数信息对应的日志文件开始续取日志文件，并从Flume中获取第一标签信息中的最后一个行数信息与第二标签信息中的第一个行数信息间对应的落下的日志文件，记录在快照文件Snapshot中，Kafaka再从Snapshot中获取落下的日志文件，例如，可以是标签debug.log，2019-09-18-2，5432与标签debug.log，2019-09-18-17-3，1234之间对应的所有日志文件，保证了传输文件的完整性。

本申请提供的上述断点续采方案，能够根据网络断点时落下文件的大小相应给出不同的续采方案，解决了当采集位置数据出现断点时，如不能断点续采将需要重新采集，继而导致数据积压和资源的浪费的问题。

本申请的实施例首先基于预设筛出规则进行第一实时信令消息的分拣，进而生成第二实时信令消息，避免发送不必要的实时信令消息，从而避免了数据链超出计算资源负荷时形成数据积压进而导致消息提醒延迟较长的情况，保证信令消息推送的及时性；然后根据用户信息与第二实时信令消息的匹配性进行相应发送，保证信令消息推送的准确性。

图1-4描述了实时信令消息处理方法，下面结合附图5和附图6描述本发明实施例提供的装置。

图5示出了本发明一个实施例提供的实时信令消息处理装置的结构示意图，图5所示装置中各模块具有实现图2中各个步骤的功能，并能达到其相应技术效果。如图5所示，该装置可以包括：

获取模块500，用于获取第一实时信令消息。

第一实时信令消息来源于大数据平台的O域数据和B域数据，O域数据和B域数据的数据类型包括移动管理节点功能(Mobility Management Entity，MME)信令、切换(Handover，HO)信令、以及移动管理(Mobility Management，MM)信令。在该步骤实际应用时，可基于上述三类信令分别形成相应的独立主题，并基于独立主体对信令字段进行裁剪，以形成第一实时信令消息。

生成模块502，用于筛除第一实时信令消息中符合预设筛除规则的实时信令消息，以生成第二实时信令消息。

该步骤可基于分布式计算框架进行信令消息的筛除。

在一种实施例中，生成模块502可以具体用于：

将第一实时信令消息转换为流数据；将流数据拆分为多个子流数据；将多个子流数据分别发送至不同数据节点，以供数据节点筛除子流数据中符合预设筛除规则的数据。

为了实现大规模的并行实时计算，通过分布式计算框架将第一实时信令消息转换为流数据，将一个大计算任务(流数据)拆分成多个小计算任务(子流数据)分布到若干个数据节点进行计算进而筛除子流数据中符合预设筛除规则的数据，提高了海量数据处理能力。并且该分布式计算框架还设有分布式锁机制，保证了每批次计算结果的唯一性，避免同一数据多次提交。

在一种实施例中，该预设筛除规则，包括：

子流数据的特征字段不满足预设的特征字段格式，和/或，子流数据的时间戳过期。

预设的特征字段格式可以包括：信令类型、时间戳、地市、号码、国际移动设备识别码(International Mobile Equipment Identity，IMEI)、国际移动用户识别码(International Mobile Subscriber Identity，IMSI)、位置区码(location area code，LAC)、跟踪区码(Tracking Area Code，TAC)、小区识别码(Cell Identity，CI)、应用程序(application，APP)大类、APP小类、主叫号码、被叫号码、发短信、以及收短信。

基于预设的特征字段格式筛除子流数据后，可以将经过筛除的子流数据存储在日志收集系统Flume中，然后Kafaka从Flume中获取第二实时信令消息，并基于第二实时信令消息配置Kafaka的标题信息topic，计算引擎Spark基于topic计算子流数据的时间戳，筛除时间戳过期的子流数据。

将经过筛除数据的多个子流数据进行汇总，以生成第二实时信令消息。

获取模块500，用于获取用户信息。

确定模块504，用于根据用户信息和第二实时信息消息的匹配情况，确定满足发送条件的用户信息。

在一种实施例中，确定模块504可以具体用于：

获取用户位置信息，及第二实时信令消息的发送范围。

用户位置信息可以从大数据平台获取，该用户位置信息包括用户所属的LAC和CI。

基于该用户所属的LAC和CI能够获取用户所处的场景，例如，景区、机场、以及住宅区等。

筛除用户位置信息不在发送范围内的用户信息。

将用户所处的场景与第二实时信令消息的发送范围进行比对即可实现用户信息的筛除。

在一种实施例中，本申请实施例提供的装置还包括标记模块506，用于：

获取用户的号码信息。

根据用户的号码信息判断用户所属省份，并进行标记。

进而实现对外省来访人员的识别。

在一种实施例中，确定模块504还可以用于：

根据预设的防打扰规则确定匹配第二实时消息的多个用户信息，筛除该多个用户信息中属于预设黑名单中的用户信息，最终确定满足发送条件的用户信息。

发送模块508，将第二实时信令消息发送至满足发送条件的用户信息对应的用户。

在一种实施例中，第一实时信令消息包括多个日志文件，本申请提供的装置还包括预存模块510，用于预存多个日志文件的标签信息列表。

获取模块500，用于当网络中断并重启后，从标签信息列表中确定网络中断前已获取的最后一个日志文件对应的第一标签信息。

确定模块504，用于从标签信息列表中确定当前待传输的日志文件对应的第二标签信息。

确定模块504，用于根据第一标签信息和第二标签信息确定续取策略。

获取模块500，用于根据续取策略继续获取第一实时信令消息。

具体的，在Kafka获取到第一实时信令消息后，可将日志文件的全部标签信息以列表的形式记录到记录(Record)文件，该标签信息包括日志文件的标签和日志文件的行号；例如日志文件的某一行的标签信息可以是：debug.log，2019-09-18-1，265。第一个字段为日志文件的标签，第二个字段为时间槽或者该行的最后修改的long型毫秒时间，第三个字段为该行的行数。

当网络中断并重启后，从Rceord文件的标签信息列表中读取网络中断前已获取的最后一个日志文件对应的第一标签信息、再读取当前待传输的日志文件对应的第二标签信息；

根据第一标签信息和第二标签信息确定续取策略，根据续取策略继续获取第一实时信令消息。

续取策略包括：

当第一标签信息与第二标签信息对应的两个日志文件相同，且第一标签信息中的最后一个行数信息与第二标签信息中的第一个行数信息差距小于预设个数(具体可以根据实际应用需求配置，例如设为1000)时，直接从Flume从第一标签信息中的最后一个行数信息加一的行数信息对应的日志文件开始续取日志文件，其命令为tail-f-n+${上次抽完的行号+1}--pid${flume的进程号}debug.log。

当第一标签信息与第二标签信息对应的两个日志文件相同，且第一标签信息中的最后一个行数信息与第二标签信息中的第一个行数信息差距大于预设个数；或者第一标签信息与第二标签信息对应的两个日志文件不同时，直接基于第二标签信息中的第一个行数信息对应的日志文件开始续取日志文件，并从Flume中获取第一标签信息中的最后一个行数信息与第二标签信息中的第一个行数信息间对应的落下的日志文件，记录在快照文件Snapshot中，Kafaka再从Snapshot中获取落下的日志文件，例如，可以是标签debug.log，2019-09-18-2，5432与标签debug.log，2019-09-18-17-3，1234之间对应的所有日志文件，保证了传输文件的完整性。

本申请的实施例能够根据网络断点时落下文件的大小相应给出不同的续采方案，解决了当采集位置数据出现断点时，如不能断点续采将需要重新采集，继而导致数据积压和资源的浪费的问题。

本申请的实施例首先基于预设筛出规则进行第一实时信令消息的分拣，进而生成第二实时信令消息，避免发送不必要的实时信令消息，从而避免了数据链超出计算资源负荷时形成数据积压进而导致消息提醒延迟较长的情况，保证信令消息推送的及时性；然后根据用户信息与第二实时信令消息的匹配性进行相应发送，保证信令消息推送的准确性。

图6示出了本发明一个实施例提供的实时信令消息处理设备的结构示意图。如图6所示，该设备可以包括处理器601以及存储有计算机程序指令的存储器602。

具体地，上述处理器601可以包括中央处理器(Central Processing Unit，CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本发明实施例的一个或多个集成电路。

存储器602可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器602可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在一个实例中，存储器602可以包括可移除或不可移除(或固定)的介质，或者存储器602是非易失性固态存储器。存储器602可在综合网关容灾设备的内部或外部。

在一个实例中，存储器602可以是只读存储器(Read Only Memory，ROM)。在一个实例中，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。

处理器601通过读取并执行存储器602中存储的计算机程序指令，以实现图2所示实施例中的方法，并达到图2所示实例执行其方法达到的相应技术效果，为简洁描述在此不再赘述。

在一个示例中，该实时信令消息处理设备还可包括通信接口603和总线610。其中，如图6所示，处理器601、存储器602、通信接口603通过总线610连接并完成相互间的通信。

通信接口603，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。

总线610包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industry Standard Architecture，ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线610可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。

该实时信令消息处理设备可以执行本发明实施例中的实时信令消息处理方法，从而实现图2描述的实时信令消息处理方法对应的技术效果。

另外，结合上述实施例中的实时信令消息处理方法，本发明实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种实时信令消息处理方法。

需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RadioFrequency，RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本发明的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种实时信令消息处理方法，其特征在于，包括：

获取第一实时信令消息；

筛除所述第一实时信令消息中符合预设筛除规则的所述实时信令消息，以生成第二实时信令消息；

获取用户信息；

根据所述用户信息和所述第二实时信息消息的匹配情况，确定满足发送条件的所述用户信息；

将所述第二实时信令消息发送至满足发送条件的所述用户信息对应的用户。

2.如权利要求1所述的实时信令消息处理方法，其特征在于，所述第一实时信令消息包括多个日志文件，所述方法还包括：

预存所述多个日志文件的标签信息列表；

当网络中断并重启后，从所述标签信息列表中确定网络中断前已获取的最后一个日志文件对应的第一标签信息；

从所述标签信息列表中确定当前待传输的日志文件对应的第二标签信息；

根据所述第一标签信息和所述第二标签信息确定续取策略；

根据所述续取策略继续获取所述第一实时信令消息。

3.如权利要求1所述的实时信令消息处理方法，其特征在于，所述筛除所述第一实时信令消息中符合预设筛除规则的所述实时信令消息，以生成第二实时信令消息，包括：

将所述第一实时信令消息转换为流数据；

将所述流数据拆分为多个子流数据；

将所述多个子流数据分别发送至不同数据节点，以供所述数据节点筛除所述子流数据中符合所述预设筛除规则的数据；

将经过筛除数据的所述多个子流数据进行汇总，以生成所述第二实时信令消息。

4.如权利要求3所述的实时信令消息处理方法，其特征在于，所述预设筛除规则，包括：

所述子流数据的特征字段不满足预设的特征字段格式；和/或，

所述子流数据的时间戳过期。

5.如权利要求1所述的实时信令消息处理方法，其特征在于，所述根据所述用户信息和所述第二实时信息消息的匹配情况，确定满足发送条件的所述用户信息，包括：

获取用户位置信息，及所述第二实时信令消息的发送范围；

筛除所述用户位置信息不在所述发送范围内的所述用户信息。

6.一种实时信令消息处理装置，其特征在于，所述装置包括：

获取模块，用于获取第一实时信令消息；

生成模块，用于筛除所述第一实时信令消息中符合预设筛除规则的所述实时信令消息，以生成第二实时信令消息；

所述获取模块，还用于获取用户信息；

确定模块，用于根据所述用户信息和所述第二实时信息消息的匹配情况，确定满足发送条件的所述用户信息；

发送模块，用于将所述第二实时信令消息发送至满足发送条件的所述用户信息对应的用户。

7.如权利要求6所述的实时信令消息处理装置，其特征在于，所述第一实时信令消息包括多个日志文件，所述装置还包括：预存模块；

所述预存模块，用于预存所述多个日志文件的标签信息列表；

所述确定模块，用于当网络中断并重启后，从所述标签信息列表中确定网络中断前已获取的最后一个日志文件对应的第一标签信息；

所述确定模块，还用于从所述标签信息列表中确定当前待传输的日志文件对应的第二标签信息；

所述确定模块，还用于根据所述第一标签信息和所述第二标签信息确定续取策略；

所述获取模块，还用于根据所述续取策略继续获取所述第一实时信令消息。

8.如权利要求6所述的实时信令消息处理装置，其特征在于，所述生成模块，具体用于：

将所述第一实时信令消息转换为流数据；

将所述流数据拆分为多个子流数据；

将所述多个子流数据分别发送至不同数据节点，以供所述数据节点筛除所述子流数据中符合所述预设筛除规则的数据；

将经过筛除数据的所述多个子流数据进行汇总，以生成所述第二实时信令消息。

9.一种实时信令消息处理设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至5中任一项所述的实时信令消息处理方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有信息传递的实现程序，所述程序被处理器执行时实现如权利要求1至5中任一项所述的实时信令消息处理方法。

Images