CN103020056A - 一种跨开放平台社交消息优化计算的订阅推送引擎 - Google Patents

Abstract

本发明公开了一种跨开放平台社交消息优化计算的订阅推送引擎，联接于业务系统业务模块和社交开放平台之间，实现两者的用户社交消息互联互通。设计本引擎时首要考虑的是与具体订阅服务无关，任何业务系统均可接入；与开放平台类型无关，任何开放平台均可适配。本引擎包括社交信息订阅规则采集、订阅规则解析计算、结果异步推送三部分。其中，订阅规则采集，实现并发收集来自业务系统的社交订阅请求，并采用自描述XML结构封装数据；订阅规则解析计算，实现跨社交开放平台计算；结果异步推送，实现以优化策略回推计算结果；本发明具有跨开放平台，通用非阻塞订阅推送机制，计算算法优化等特点，满足个性化订阅需求，提高业务系统使用价值。

Description

一种跨开放平台社交消息优化计算的订阅推送引擎

技术领域

本发明涉及互联网社交应用领域，特别是涉及一种跨开放平台社交消息优化计算的订阅推送引擎，联接于业务系统和社交开发平台两者之间，为业务系统业务模块屏蔽开放平台的差异，实现业务系统和开放平台之间的用户社交消息的互联互通。

背景技术

在互联网时代，把网站的服务封装成一系列计算机易识别的数据接口开放出去，供第三方开发者使用，这种行为就叫做Open API，提供开放API的平台本身就被称为开放平台。通过开放平台，网站不仅能提供对Web网页的简单访问，还可以进行复杂的数据交互，将它们的Web网站转换为与操作系统等价的开发平台。第三方开发者可以基于这些已经存在的、公开的Web网站而开发丰富多彩的应用。

在现在流行社交交互中，用户使用开放平台的客户端产生社交数据内容，这个社交数据，内容均存在于其所属的开放平台上，接入客户端应用(包括我们的引擎)想要获取社交数据只能通过它提供的开放api去查询获取。这样问题来了，如果某用户的社交数据有变更(比如用户使用开放平台客户端发送某些社交数据消息)我们的业务系统业务模块应用是不知道的，但业务系统业务模块的用户却要求实时获取这一数据变更的消息，那么业务系统业务模块编程适配开放平台的开放接口，并只能通过不断的api查询才知道用户的社交内容有变更。因此必须引入一个中间机制，建立一套订阅推送引擎，去使用轮询机制不断调用开放平台的api去发现社交数据变更的消息，当发现有变更后订阅引擎内部触发一项推送服务，将这一个变更的消息推送回业务系统业务模块，业务系统客户端提供回调接口能处理这一则社交数据变更的消息，并做界面消息提醒给用户。由此看来，引擎服务中必须包含这一项订阅推送服务。可能要定制一套订阅规则，对接入的业务系统业务模块约定规则内容，通过多种协议接口将其传递给引擎的订阅服务管理中。引擎服务维护和解析这些订阅服务规则，并异步将结果回馈给业务系统业务模块。

本跨开放平台社交消息优化计算的订阅推送引擎，对外以客户端身份连接大部分的开放平台，适配其提供的开放服务以供我们内部业务系统、业务模块应用调用，将内部应用的采集的用户信息内容传播到开放平台上，并关注开放平台上的用户关心图谱中产生的社交信息内容，促进用户社交互动，以达到内部业务系统、业务模块应用的社交化而提升用户体验的目的。

发明内容

本发明所要解决的技术问题是业务系统业务模块的社交化需求，其需要关注的社交消息可能牵涉到多个社交平台，不同社交平台消息存储以及获取方式不同，并且还分别处于不同类型的开放系统中，本订阅引擎处在业务角度上考虑，引入一种内联所有开放平台的机制为业务系统业务模块屏蔽开放平台的差异，业务系统业务模块的信息与社交信息的互联互通；

为实现上述发明目的，本发明提供一种跨开放平台社交消息优化计算的订阅推送引擎，涉及对接交互的系统包括有内部业务服务系统、公网的社交开放平台，包括社交信息订阅规则采集、订阅规则解析计算、结果异步推送三部分，其中这三部分涉及的对接交互的系统包括有内部业务服务系统、公网的社交开放平台；

所述第一部分社交信息订阅规则采集，用于：接收业务系统中各个服务模块的社交信息订阅需求，同时处理多个业务系统并多个模块中的请求，不需要阻塞引擎系统，引擎根据上下文环境将请求数据以自描述的XML结构封装元数据和请求数据成订阅规则数据包，使其不必依赖静态定于的服务接口和数据结构，订阅规则数据包以队列形式存储并排队等候处理；

所述第二部分订阅规则解析计算，用于：对第一步中收集的订阅请求进行跨开放平台的关联解析，订阅规则一般包括业务系统或者业务模块的社交信息需求，以XML格式封装起来，按照解析器所认知的约定规则格式。引擎内有一个集中式全局统筹的调度器，负责从第一步中采集的订阅规则数据队列中提取数据集，对规则数据按不同开放平台连接目标进行分拆和合并，再分发到开放平台类型相同的解析器解析执行，最后在集中式全局解析器中统筹合并结果，并存放到订阅结果队列中待推送；

所述第三部分结果异步推送，用于：订阅请求经过解析器解析计算后存放在结果存储结构中，由统一集中的推送器将结果回推给业务系统，其中回推使用回推策略包括有主动推送和储存待拉两种策略，灵活地化解业务系统接收超时致使消息堵塞；

本发明还提供一种跨开放平台社交消息分类计算方法，包括：

社交消息计算是跨开放平台的，其计算牵涉的社交信息是跨业务系统和开放平台的，这里采用分类计算的方法；

本引擎联接于业务系统和社交开发平台两者之间，其中开放平台包括目前主流两类，社交网和微博平台；

对于业务系统业务模块，其订阅关注的社交信息可以跨开放平台类型，即需要订阅请求的用户，某用户作为唯一个体在业务系统范围内存在，并存在一定用户关系图谱集，在多个开放平台上也分别存在一定范围的社交关系图谱集，而业务范围内的用户关系图谱集与开放平台上的社交关系图谱集存在一定的关联，如果将用户关系图谱集和社交关系图谱集看成是全局范围内的有唯一标识的用户关系集，那么上述的业务范围内与多个开放平台范围内的关系图谱集的关联就指他们的用户集存在交集，或者1对1相交、或者是1对N相交，其交集为唯一用户集，这里的用户可以是真实个人或虚拟用户；

跨开放平台社交信息订阅的计算就是基于这种用户交集的基础上展开计算的；

譬如，某用户在业务系统范围内存在并持有一定量好友关系集，该用户在社交网上存在唯一帐号身份并持有多个关注好友，该用户在微博平台上也存在对应的唯一帐号并持有多个关注好友。该用户的好友关系集合分别在业务系统范围与社交网范围和微博平台范围内存在交叉的地方，即用户交集，该用户在两种开放平台上均存在帐号并持有各自的好友关系列表，并且当中与该用户在业务系统范围内的好友群刚好有部分共同好友，存在好友关系交集；

交集数据按照开放平台类型划分类，主要分为两类，第一类为1对1相交，例如业务范围内关系集与社交网范围内关系集的交集、业务范围内关系集与微博平台范围内关系集的交集；第二类为1对N相交，业务范围内关系集与多个开放平台范围内关系集的交集；

所述第一类划分法为1对1相交，分别指业务范围内关系集和单个开放平台范围内关系集，即业务范围内关系集中存在的某个用户同时也在单个开放平台范围内关系集中，基于这种情况，采用单种开放平台类型解析器可以计算变更结果；

所述第二类划分法为1对N相交，1为业务范围内关系集，N为开放平台范围内关系集，N大于等于2，即业务范围内关系集中存在的某个用户同时也在多个开放平台范围内关系集中，基于这种情况，采用内联多种开放平台类型解析器可以计算变更结果；

现在该用户需要关注他的业务范围内好友的社交动态，该用户通过业务系统与引擎的接口向引擎发起一则订阅请求，请求的数据格式为一自描述的XML数据包，内里封装包括解析器能识别的元数据和订阅好友社交信息变更的数据，表示该用户关注其好友的在社交平台信息变更情况，需要引擎解析器去解析他的这个订阅包并需要得到返回结果，再回传反馈给该用户。

优选的有，上述方法中，还包括：采用集中式全局统筹的调度和全局解析的计算方法；引擎内的一个集中式全局统筹的调度器，负责从第一步中采集的订阅规则数据队列中提取数据集，对规则数据按不同开放平台连接目标进行分拆和合并，再分发到开放平台类型相同的解析器解析执行，最后在集中式全局解析器中统筹合并结果，并存放到订阅结果队列中待推送；

所述的集中式全局调度器，负责统一调度解析过程，包括从订阅规则数据队列中提取数据集、分类分拆数据、委托特定开放平台类型解析器解析执行；

所述分类分拆数据，采用前面特征所描述的分类法分拆；

各个解析器解析过程支持并发；

所述集中式全局解析器，负责收集结果并汇总统计、将结果丢放到待返回的推送队列中。其中汇总过程，涉及到获取并发线程执行结果，并内联全局的订阅规则进行综合汇总结果。

优选的有，上述方法中，还包括：跨开放平台社交信息的计算方法是采用优化策略；所述优化策略指减少引擎资源开销和减少对开放平台api调用，以提升解析引擎性能和解析速度为目的；

优化策略包括按照开放平台类型分类批量计算、定期间隔计算；

对订阅数据包按照开放平台类型划分能有效地支持优化计算；

所述按照开放平台类型分类批量计算策略，指同一种开放平台类型的社交信息计算，例如是社交网平台类型的社交信息计算，其社交平台类型相同并且计算规则类似，即存在类似的开放api，因此可以将这类社交信息计算合并为批量计算，这类批量集中计算比单条计算提高计算速度和效率；

所述定期间隔计算策略，指设定一定时间间隔进行计算，引擎采用定时调度机制，定期向开放平台查询计算订阅包含的社交信息是否存在变更。在固定间隔内，调度引擎会收集本时间段内的计算请求，再集中在一个时间点开始计算，这样可以减少不必要的冗余请求，因为大部分社交信息的变更间隔并不频繁；

定时间隔动态地可配置。

本发明还提供一种社交信息订阅结果的推送机制，包括：

采用自动调节的推送策略，自动机制会根据当前引擎调用业务系统客户端的耗时自动调整推送策略，以达到合理利用服务端引擎资源的效果；

推送策略包括主动推送策略和存储待拉策略；

所述主动推送策略，指服务引擎主动将订阅计算产生的结果，通过调用业务系统客户端提供的回调api，将结果回推给业务系统；

所述存储待拉策略，指服务引擎将订阅计算产生的结果存储在服务引擎端提供的增强存储容器中，等待业务系统客户端的主动查询请求，查询是否积压大量的结果消息未推送，若是则主动拉取并清除这些结果消息；

存储待拉策略的选取是基于解决主动推送策略时引起的堵塞问题而引入的，当存在网络不稳定时，主动推会因大量的io传送而消耗服务端引擎的性能资源，致使主动推送频频超时，结果消息不能发出而出现堵塞；

当主动推送遇到网络不畅或者业务系统客户端繁忙时，超时过一段阀值后，服务引擎会自动切换推送策略，而将结果消息存放在本地的缓存结构中，待业务系统客户端主动来拉取。

由上述方案可以看出，本发明中订阅推送引擎联接于业务系统和社交开发平台两者之间，实现业务系统和开放平台之间的用户社交消息的互联互通。每个业务系统都有社交化需求，订阅变化的用户社交信息，所以在设计本引擎时首要考虑的是与具体服务无关，任何业务系统均可接入；与开放平台类型无关，任何开放平台均可适配。本引擎包括社交信息订阅规则采集、订阅规则解析计算、结果异步推送三部分。其中，订阅规则采集，用于收集来自业务系统的社交信息订阅请求，支持并发处理不需阻塞；结果异步推送，用于对解析计算的结果推送回给业务系统，推送方式采用主动推送与储存待拉两种策略；订阅规则以及计算结果均采用自描述的XML格式封装元数据和数值数据，实现计算引擎与业务系统之间的解耦；订阅规则解析计算，实现跨社交开放平台计算，采取内联监听并轮询查询方式计算。本发明主要针对业务服务系统社交化需求，实现业务系统与开放平台的社交信息互联互通，将业务系统接通开放平台为实现用户社交信息传递提供集中式通道，提高业务系统使用价值和增强用户满意度。

附图说明

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

图1为本发明实施例一中系统交互结构示意图；

图2为本发明实施例一中系统订阅推送之订阅请求采集流程示意图；

图3为本发明实施例一中系统订阅推送之规则解析计算流程示意图；

图4为本发明实施例一中系统订阅推送之结果推送流程示意图；

图5为本发明实施例二中跨开放平台优化计算算法1示意图；

图6为本发明实施例二中跨开放平台优化计算算法2示意图；

图7为本发明实施例三中跨开放平台优化计算算法3示意图；

图8为本发明实施例三中跨开放平台优化计算算法4示意图；

图9为本发明实施例三中系统所依赖的外部应用环境示意图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一，参见图1。

本发明提供一种跨开放平台社交消息优化计算的订阅推送引擎，涉及对接交互的系统包括有内部业务服务系统、公网的社交开放平台，包括社交信息订阅规则采集、订阅规则解析计算、结果异步推送三部分，其中这三部分涉及的对接交互的系统包括有内部业务服务系统、公网的社交开放平台；

上述引擎部分的系统交互结构示意图参见图1，具体包括以下步骤：

图中1表示：接入的客户端系统，指业务系统业务模块，引擎通过公共IP网或者内部网与其连接；

图中2表示：订阅推送引擎核心服务部分，提供订阅推送服务；

图中3表示：开放平台部分，引擎通过公共IP网与其连接；

其中引擎部分包括：

所述第一部分社交信息订阅规则采集，用于：接收业务系统中各个服务模块的社交信息订阅需求，同时处理多个业务系统并多个模块中的请求，不需求阻塞引擎系统，请求数据以自描述的XML结构封装，使其不必依赖静态定于的服务接口和数据结构，引擎自动根据其封装的元数据格式抽取消息数据，再委托给订阅规则解析器解析执行，订阅规则数据以队列形式存储并排队等候处理；

上述引擎部分的工作过程参见图2，具体包括以下步骤：

步骤S201，用户通过业务系统业务模块发起订阅请求，关注社交信息内容；

步骤S202，接收业务系统中各个服务模块的社交信息订阅需求，同时处理多个业务系统并多个模块中的请求，这个过程是并发执行的，，不需要阻塞引擎系统；

步骤S203，引擎根据上下文环境将请求数据以自描述的XML结构封装元数据和请求数据成订阅规则数据包，使其不必依赖静态定于的服务接口和数据结构；

步骤S204，订阅规则数据包以队列形式存储并排队等候处理，这便是待解析计算队列。

所述第二部分订阅规则解析计算，用于：对第一步中收集的订阅请求进行跨开放平台的关联解析，订阅规则一般包括业务系统或者业务模块的社交信息需求，以XML格式封装起来，按照解析器所认知的约定规则格式。引擎内有一个集中式全局统筹的调度器，负责从第一步中采集的订阅规则数据队列中提取数据集，对规则数据按不同开放平台连接目标进行分拆和合并，再分发到开放平台类型相同的解析器解析执行，最后在集中式全局解析器中统筹合并结果，并存放到订阅结果队列中待推送；

上述引擎部分的工作过程参见图3，具体包括以下步骤：

对第一步中收集的订阅请求进行跨开放平台的关联解析，订阅规则一般包括业务系统或者业务模块的社交信息需求，以XML格式封装起来，按照解析器所认知的约定规则格式；

步骤S301，全局统筹调度器扫描待解析的订阅规则请求队列，按需提取部分订阅规则；

步骤S302，订阅规则数据按不同开放平台连接目标进行分拆和合并，再分发到开放平台类型相同的解析器解析执行；

步骤S303，解析器解析订阅规则，并转换为开放接口调用，这里可能使用是轮询方式、也可能是监听事件方式的策略；

若检测出消息则发起回调通知；

步骤S304，解析器委托开放平台api调用来解析计算订阅结果，再转换成订阅结果格式；

步骤S305，将订阅解析计算的结果汇总合并，并存放到待返回的结果推送队列中，等待统一回调；

所述第三部分结果异步推送，用于：订阅请求经过解析器解析计算后存放在结果存储结构中，由统一集中的推送器将结果回推给业务系统，其中回推使用回推策略包括有主动推送和储存待拉两种策略，灵活地化解业务系统接收超时致使消息堵塞。

上述引擎部分的工作过程参见图4，具体包括以下步骤：

步骤S401，引擎部分后台线程自维护监测待推送的结果存储队列；

步骤S402，根据定制回调调度机制，采用不同的回推策略，主动推送策略或者存储待拉策略；

步骤S403，对于主动推送策略，由引擎端发起，业务系统客户端提供回调接口，接收订阅结果；

步骤S404，对于存储待拉策略，由引擎端发起，当引擎端调用回调时候发现网络繁忙导致堵塞，则会将返回结果消息存放在本地的缓存结构；

步骤S405，业务系统业务模块客户端向引擎服务端发起主动拉起请求；

步骤S406，引擎从缓存结构中提取未读消息，并清除缓存，将结果数据封装返回给调用者；

步骤S407，业务系统业务模块客户端收到结果，并反馈给用户；

实施例二，参见图5、图6、图7、图8，具体包括以下步骤：

本实例说明一种跨开放平台社交消息分类计算方法的实施过程，

社交消息计算是跨开放平台的，其计算牵涉的社交信息是跨业务系统和开放平台的，这里采用分类计算的方法；

对于业务系统业务模块，其订阅关注的社交信息可以跨开放平台类型，即需要订阅请求的用户，这里的用户可以是真实个人或虚拟用户，需要关注其在开放平台上的好友关系的消息状态；

跨开放平台社交信息订阅的计算就是基于一种用户关系的基础上展开计算的；

譬如，某用户在业务系统范围内存在并持有一定量好友关系集，该用户在社交网上存在唯一帐号身份并持有多个关注好友，该用户在微博平台上也存在对应的唯一帐号并持有多个关注好友；

所述图5，具体步骤包括：

图中P501表示：

假定存在两种开放平台，一是社交网平台(人人网)，一是微博平台(新浪)；

假定存在业务系统接入用户有4个(真实个人)，分别以1234代表，这4人分别在开放平台上有对应帐号，其对应关系在图上用符号表示；

图中P502表示：

现在这4人分别接入订阅推送引擎内部，并有订阅请求需要被响应；

假定有下面的上下文绑定关系；

用户1，已绑定连接新浪微博(S)和人人网(R)；

用户2，已绑定连接新浪微博(S)；

用户3，已绑定连接新浪微博(S)；

用户4，已绑定连接新浪微博(S)和人人网(R)；

图中P503表示：

假定在业务系统范围内这4人存在以下关系：

用户1，有2个好友，分别是用户2和用户3；

用户2，有2个好友，分别是用户3和用户4；

用户1和用户2，存在共同的好友用户3；

所述图6，具体步骤包括：

下面是订阅推送的响应过程，

图中P601表示：订阅推送流程-订阅请求采集

用户1通过业务系统对其好友用户2和用户3的社交信息变更状态表示关注，因此发起订阅请求；用户2绑定连接新浪微博(S)；用户3绑定连接新浪微博(S)

用户2通过业务系统对其好友用户3和用户4的社交信息变更状态表示关注，因此发起订阅请求；用户3绑定连接新浪微博(S)；用户4绑定连接新浪微博(S)和人人网(R)

引擎将用户1的订阅请求根据上下文分拆封装成规则包后，丢入待计算队列中；

图中P602表示：订阅推送流程-解析计算

引擎从待计算队列中提取待解析的订阅规则包(用户1的订阅请求)，由集中的调度器统筹分配解析，并按开放平台类型分拆解析包(分拆结果只含S的开放平台)，开放平台类型为S的解析器解析这个订阅包，并由统一调度器归并计算结果N，付带到对应用户1的订阅包中，再丢入待回推队列中；

图中P603表示：订阅推送流程-结果回推

推送机制引擎从待回推队列中提取用户1的订阅包的解析结果，并自动选取回推策略，调用客户端提供回调方法，返回给业务系统客户端；

所述图7，具体步骤包括：

优化计算策略：包括按照开放平台类型分类批量计算、定期间隔计算；

对订阅数据包按照开放平台类型划分能有效地支持优化计算；

图中P701表示：

方案1，未经过优化的实现方式，用户1和用户2的订阅请求被分别计算，发生2次解析计算；

图中P702表示：

方案2，已经过优化的实现方式，用户1和用户2的订阅请求被引擎合并，只发送1次解析计算；

图中P703表示：优化前后对比：方案2优于方案1，因为使用优化策略去除重复计算，重复的部分为③

(用户3绑定新浪微博(S)的重复计算)

所述图8，具体步骤包括：

图中P801表示：

方案1，未经过优化的实现方式，用户1、用户2、用户3、用户4的订阅请求被分别计算，发生4次解析计算；

图中P802表示：

方案2，已经过优化的实现方式，用户1、用户2、用户3、用户4的订阅请求被批量合并，只发送1次解析计算；虽然单次批量计算比单次计算耗资源多，但绝对比4次单词计算耗资源少。

图中P803表示：

优化前后对比：方案2优于方案1，因为批量计算，解析引擎调用次数减少3，并最终会减少开放平台api调用次数，节省成本

实施例三，参见图9，具体包括以下步骤：

本发明常用在于社交网关应用内部，作为一种订阅推送服务而存在，下面引用社交网关应用为实施例进行说明；

图中S701表示：客户端接入部分包括多个业务系统或者业务模块；

图中S702表示：开放平台部分包括适配多个不同类型的开放平台，目前包括两类型开放平台，一类是社交网平台，一类是微博平台

图中S703表示：社交网关应用，对外以客户端身份连接大部分的开放平台，适配其提供的开放服务以供我们内部业务系统业务模块调用，将内部业务系统业务模块应用采集的用户信息内容传播到开放平台上，促进用户社交互动，以达到我们内部平台、内部业务系统业务模块社交化而提升应用价值，增强用户体验的目的。

图中S704表示：社交网关应用内部的交互服务部分，包括订阅推送引擎服务部分，其中本发明所指的服务设计的实现具体依赖社交网关应用内部的内核服务；

图中S705表示：社交网关应用的内部内核服务，为实现业务系统社交化提供支撑；

也为本发明设计的订阅推送引擎服务提供基础服务支持：

提供授权绑定服务支持，为订阅推送引擎的解析部分可以直接在授权绑定服务中获取访问开放平台的访问权限，以及客户端接入用户绑定的定位服务；

提供社交组件服务支持，为引擎解析部分提供适配的开放平台api接口调用，屏蔽不同开放平台的服务差异，以便解析器透明地获取社交数据；

提供审计监控服务和社交访问控制服务支持，为引擎提供优化计算汇总统计服务；

由上可见，本发明提供的一种跨开放平台社交消息优化计算的订阅推送引擎，有以下优点。

(1)跨开放平台，方便横行扩展

目前的开放平台百花齐放，每个平台的均持有各自独立的社交关系图谱，并针对这些社交图谱数据并其代表用户所产生的社交信息内容用开放api的接口方式对外提供，方便其他系统连接各自开放平台。然而业务系统业务模块所牵涉的用户并不全属于个别或部分开放平台，因此本发明可以很好地解决业务系统业务模块与所有开放平台的互联互通，以实现大范围内的社交化信息需求。

(2)通用的订阅推送机制，满足个性化订阅定制需求，解耦业务系统业务模块和开放平台

目前的开放平台均未提供对外的订阅定制社交信息接口，或者有提供但是种类稀少并不够个性化，未能很好地满足业务需要。本发明设计通用的订阅推送机制，适配大部分的业务系统业务模块的订阅定制需求，并对其屏蔽多种开放平台的差异，提供统一社交接入。

(3)计算算法优化，减少开放平台api的调用次数，降低成本

所有开放平台的均对自己提供的api有一个访问频率计数，以此来统计接入调用的客户端对平台的访问量，开放平台服务提供商会按访问量收费收费。大部分开放平台均缺少个性化社交信息订阅接口，只提供轮询方式拉数据而没主动推送数据。本发明基于开放平台这一缺点，设计出消息优化计算的方法，采用按照开放平台类型分类批量计算策略和定期间隔计算策略，能减少无效冗余的api调用，节约成本。

(4)订阅推送信息的非阻塞自调节、并可靠交付。

自动机制会根据当前引擎调用业务系统客户端的耗时自动调整推送策略，以达到合理利用服务端引擎资源的效果。

通过以上的方法实施例的描述，所属领域的技术人员可以清楚地了解到本发明是一套软件解决方案，更多地可借助软件加必需的通用硬件平台的方式来实现。本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件服务的形式体现出来，并作为其中一部分软件服务集合到一个大的社交网关应用产品中。本发明的软件服务中部分服务基于社交网关应用产品的基础模块服务

对于系统实施例而言，由于其基本相应于方法实施例，所以相关之处参见方法实施例的部分说明即可。其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，在没有超过本申请的精神和范围内，可以通过其他的方式实现。上面列举的将本应用集成到社交网关应用中的实施例只是一种示范性的例子，不应该作为限制，所给出的具体内容不应该限制本申请的目的。

以上所述仅是本发明的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (6)

1.一种跨开放平台社交消息优化计算的订阅推送引擎，其特征在于联接于业务系统和社交开发平台两者之间，实现业务系统和开放平台之间的用户社交消息的互联互通，在这基础上实现用户关注消息的个性化定制的订阅推送服务；

业务系统业务模块的社交化需求，其需要关注的社交消息可能牵涉到多个社交平台，不同社交平台消息存储以及获取方式不同，并且还分别处于不同类型的开放系统中，本订阅引擎处在业务角度上考虑，引入一种内联所有开放平台的机制为业务系统业务模块屏蔽开放平台的差异，业务系统业务模块的信息与社交信息的互联互通，体现透明性特点；

包括社交信息订阅规则采集、订阅规则解析计算、结果异步推送三部分，其中这三部分涉及的对接交互的系统包括有内部业务服务系统、公网的社交开放平台；

其中

客户端接入部分包括多个业务系统或者业务模块；

开放平台部分包括适配多个不同类型的开放平台；

引擎部分通过公共IP网或者内部网与客户端接入部分连接；

引擎部分通过公共IP网与适配的开放平台部分连接；

所述第一部分社交信息订阅规则采集，用于：接收业务系统中各个服务模块的社交信息订阅需求，同时处理多个业务系统并多个模块中的请求，不需要阻塞引擎系统，引擎根据上下文环境将请求数据以自描述的XML结构封装元数据和请求数据成订阅规则数据包，使其不必依赖静态定于的服务接口和数据结构，订阅规则数据包以队列形式存储并排队等候处理；

所述第二部分订阅规则解析计算，用于：对第一步中收集的订阅请求进行跨开放平台的关联解析，订阅规则一般包括业务系统或者业务模块的社交信息需求，以XML格式封装起来，按照解析器所认知的约定规则格式。引擎内有一个集中式全局统筹的调度器，负责从第一步中采集的订阅规则数据队列中提取数据集，对规则数据按不同开放平台连接目标进行分拆和合并，再分发到开放平台类型相同的解析器解析执行，最后在集中式全局解析器中统筹合并结果，并存放到订阅结果队列中待推送；

所述第三部分结果异步推送，用于：订阅请求经过解析器解析计算后存放在结果存储结构中，由统一集中的推送器将结果回推给业务系统，其中回推使用回推策略包括有主动推送和储存待拉两种策略，灵活地化解业务系统接收超时致使消息堵塞。

2.一种跨开放平台社交消息分类计算方法，其特征在于社交消息计算是跨开放平台的，其计算牵涉的社交信息是跨业务系统和开放平台的，这里采用分类计算的方法；

本引擎联接于业务系统和社交开发平台两者之间，其中开放平台包括目前主流两类，社交网和微博平台，典型代表如人人社交网和新浪微博平台；

对于业务系统业务模块，其订阅关注的社交信息可以跨开放平台类型，即需要订阅请求的用户，某用户作为唯一个体在业务系统范围内存在，并存在一定用户关系图谱集，在多个开放平台上也分别存在一定范围的社交关系图谱集，而业务范围内的用户关系图谱集与开放平台上的社交关系图谱集存在一定的关联，如果将用户关系图谱集和社交关系图谱集看成是全局范围内的有唯一标识的用户关系集，那么上述的业务范围内与多个开放平台范围内的关系图谱集的关联就指他们的用户集存在交集，或者1对1相交、或者是1对N相交，其交集为唯一用户集，这里的用户可以是真实个人或虚拟用户；

跨开放平台社交信息订阅的计算就是基于这种用户交集的基础上展开计算的；

譬如，某用户在业务系统范围内存在并持有一定量好友关系集，该用户在社交网上存在唯一帐号身份并持有多个关注好友，该用户在微博平台上也存在对应的唯一帐号并持有多个关注好友。该用户的好友关系集合分别在业务系统范围与社交网范围和微博平台范围内存在交叉的地方，即用户交集，该用户在两种开放平台上均存在帐号并持有各自的好友关系列表，并且当中与该用户在业务系统范围内的好友群刚好有部分共同好友，存在好友关系交集；

交集数据按照开放平台类型划分类，主要分为两类，第一类为1对1相交，例如业务范围内关系集与社交网范围内关系集的交集、业务范围内关系集与微博平台范围内关系集的交集；第二类为1对N相交，业务范围内关系集与多个开放平台范围内关系集的交集；

所述第一类划分法为1对1相交，分别指业务范围内关系集和单个开放平台范围内关系集，即业务范围内关系集中存在的某个用户同时也在单个开放平台范围内关系集中，基于这种情况，采用单种开放平台类型解析器可以计算变更结果；

所述第二类划分法为1对N相交，1为业务范围内关系集，N为开放平台范围内关系集，N大于等于2，即业务范围内关系集中存在的某个用户同时也在多个开放平台范围内关系集中，基于这种情况，采用内联多种开放平台类型解析器可以计算变更结果；

现在该用户需要关注他的业务范围内好友的社交动态，该用户通过业务系统与引擎的接口向引擎发起一则订阅请求，请求的数据格式为一自描述的XML数据包，内里封装包括解析器能识别的元数据和订阅好友社交信息变更的数据，表示该用户关注其好友的在社交平台信息变更情况，需要引擎解析器去解析他的这个订阅包并需要得到返回结果，再回传反馈给该用户。

3.根据权利要求2所述的方法，其特征在于，还包括：采用集中式全局统筹的调度和全局解析的计算方法；引擎内的一个集中式全局统筹的调度器，负责从第一步中采集的订阅规则数据队列中提取数据集，对规则数据按不同开放平台连接目标进行分拆和合并，再分发到开放平台类型相同的解析器解析执行，最后在集中式全局解析器中统筹合并结果，并存放到订阅结果队列中待推送；

所述的集中式全局调度器，负责统一调度解析过程，包括从订阅规则数据队列中提取数据集、分类分拆数据、委托特定开放平台类型解析器解析执行；

所述分类分拆数据，采用前面特征所描述的分类法分拆；

各个解析器解析过程支持并发；

所述集中式全局解析器，负责收集结果并汇总统计、将结果丢放到待返回的推送队列中。其中汇总过程，涉及到获取并发线程执行结果，并内联全局的订阅规则进行综合汇总结果。

4.根据权利要求2所述的方法，其特征在于，还包括：跨开放平台社交信息的计算方法是采用优化策略；所述优化策略指减少引擎资源开销和减少对开放平台api调用，以提升解析引擎性能和解析速度为目的；

优化策略包括按照开放平台类型分类批量计算、定期间隔计算；

对订阅数据包按照开放平台类型划分能有效地支持优化计算；

所述按照开放平台类型分类批量计算策略，指同一种开放平台类型的社交信息计算，例如是社交网平台类型的社交信息计算，其社交平台类型相同并且计算规则类似，即存在类似的开放api，因此可以将这类社交信息计算合并为批量计算，这类批量集中计算比单条计算提高计算速度和效率；

所述定期间隔计算，指设定一定时间间隔进行计算，引擎采用定时调度机制，定期向开放平台查询计算订阅包含的社交信息是否存在变更。在固定间隔内，调度引擎会收集本时间段内的计算请求，再集中在一个时间点开始计算，这样可以减少不必要的冗余请求，因为大部分社交信息的变更间隔并不频繁；

定时间隔动态地可配置。

5.一种社交信息订阅结果的推送机制，其特征在于采用自动调节的推送策略，自动机制会根据当前引擎调用业务系统客户端的耗时自动调整推送策略，以达到合理利用服务端引擎资源的效果；

推送策略包括主动推送策略和存储待拉策略；

所述主动推送策略，指服务引擎主动将订阅计算产生的结果，通过调用业务系统客户端提供的回调api，将结果回推给业务系统；

所述存储待拉策略，指服务引擎将订阅计算产生的结果存储在服务引擎端提供的增强存储容器中，等待业务系统客户端的主动查询请求，查询是否积压大量的结果消息未推送，若是则主动拉取并清除这些结果消息；

存储待拉策略的选取是基于解决主动推送策略时引起的堵塞问题而引入的，当存在网络不稳定时，主动推会因大量的io传送而消耗服务端引擎的性能资源，致使主动推送频频超时，结果消息不能发出而出现堵塞；

当主动推遇到网络不畅或者业务系统客户端繁忙时，超时过一段阀值后，服务引擎会自动切换推送策略，而将结果消息存放在本地的缓存结构中，待业务系统客户端主动来拉取。

6.根据权利要求5所述的方法，其特征在于，还包括增强的存储容器，用来存放待回推的订阅结果信息，引入本存储容器，可实现下面几个优点：同步转异步，并发收集计算结果并不阻塞；计算结果消息可持久化，保证可靠交付；

计算结果采用自描述的XML结构，使得生成的介绍结果对其对于业务系统客户端不需求静态地确定调用接口，因此可解耦适配所有业务系统客户端接口；

增强的存储容器采用封装并发队列的方式，存储队列可持久化，以文件方式存储，以保证可靠交互。

Images