CN101753566A - 多应用系统间数据应用方法及系统 - Google Patents

Abstract

本发明实施例公开了一种多应用系统间数据应用方法及系统，涉及计算机应用领域。所述方法包括第一应用系统从第二应用系统的中转服务器中进行日志数据同步获取；根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，第一应用系统从第二应用系统同步获取的数据中筛选出满足绑定关系的日志数据；第一应用系统按预设规则应用日志数据。所述系统包括抓取服务器、筛选服务器和应用服务器。本发明实施例为各应用系统的发展提供了一个新的平台，降低了对客户端的依赖，并且提高了用户体验，也在一定程度上缓解了存储压力的问题。

Description

多应用系统间数据应用方法及系统

技术领域

本发明涉及计算机应用领域，特别涉及一种多应用系统间数据应用方法及系统。

背景技术

随着计算机技术的发展，各种应用系统应运而生，比如清华水木、校友录、猫扑等社区系统，魔兽世界、天龙八部等游戏系统，QQ、MSN等即时通信系统，等等。当前，人们越来越多的应用上述各种应用系统，每个应用系统中都拥有相当数量的用户群，保存有大量的用户个性数据。

在实施本发明过程中，发明人发现现有技术中至少存在如下问题：

目前，各应用系统几乎都是独立运行，独立维护的，各应用系统之间的用户信息及相关数据不对外公开，也不能互通，而单一的应用系统所提供的功能已经不能满足人们越来越高的需求。可见，人们对应用系统越来越高的应用需求，与各应用系统间的独立性形成一种矛盾，大大限制了应用系统的发展。而且，同时登录多个应用系统，给用户在维护及应用上带来很多不便，用户体验较差，比如，游戏系统虽然提供了很好的游戏功能，但是其好友间互动等功能相对较弱，就需要同时登录游戏系统和社区系统，不但用户操作复杂，且用户体验也很差。

另一方面，由于各应用系统之间的这种独立性，导致对某一应用系统客户端的依赖性很大，比如，对于游戏系统而言，玩家需要下载并安装客户端才可以进行游戏操作，或对游戏历史操作进行查询，对游戏客户端依赖性较大，进而从另一个方面限制了应用系统的发展。

发明内容

本发明实施例提供一种多应用系统间数据应用方法及系统，以解决由于现有应用系统间的独立性导致限制其发展的问题。

本发明实施例提供了一种多应用系统间数据应用方法，包括：

第一应用系统从第二应用系统的中转服务器中进行日志数据同步获取；

根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，第一应用系统从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据；

第一应用系统按预设规则应用所述日志数据。

优选的，所述筛选后还包括：

第一应用系统对筛选出日志数据进行格式转换，将其转换为能被所述第一应用系统识别的数据格式。

优选的，所述第一应用系统将日志数据以GuID为标识进行存储。

优选的，当第二应用系统将其产生的日志数据全部备份到中转服务器时，所述第一应用系统从第二应用系统的中转服务器中进行日志数据同步获取具体为：

所述第一应用系统对第二应用系统的中转服务器中的日志数据进行关键词匹配，对满足匹配关系的日志数据进行数据同步。

优选的，当第二应用系统将其产生的日志数据进行关键词匹配，将满足匹配关系的日志数据备份到中转服务器时，所述第一应用系统从第二应用系统的中转服务器中进行数据同步获取具体为：

所述第一应用系统对第二应用系统的中转服务器中的全部日志数据进行数据同步。

优选的，第一应用系统在linux系统下采用rsync技术从第二应用系统的中转服务器中的日志数据进行数据同步获取。

优选的，所述根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，第一应用系统从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据具体为：

解析第一应用系统同步获取的日志数据，从所述日志数据预先约定的字段中提取出GuID，在所述绑定关系中查找所述GuID，筛选出查找到的GuID对应的日志数据。

优选的，所述第一应用系统按预设规则应用所述日志数据具体为：

第一应用系统以GuID为标识将其对应的日志数据在所述第一应用系统中进行展示；

第一应用系统对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断其用户是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示；

第一应用系统对日志数据进行荣誉关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示；和/或

第一应用系统比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在第一应用系统中形成社区动态信息进行展示。

优选的，所述第一应用系统为Web架构系统，所述第二应用系统为C/S架构系统。

优选的，第二应用系统的用户身份ID具体为用户的角色ID。

本发明实施例提供了一种多应用系统间数据应用系统，包括：

抓取服务器，用于从第二应用系统的中转服务器中进行日志数据同步获取；

筛选服务器，用于根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据；

应用服务器，用于按预设规则应用所述日志数据。

优选的，所述筛选服务器还包括：

格式转换模块，用于对筛选出日志数据进行格式转换，将其转换为能被所述第一应用系统识别的数据格式。

优选的，日志数据以GuID为标识存储在所述应用服务器中。

优选的，当第二应用系统将其产生的日志数据全部备份到中转服务器时，所述抓取服务器具体用于：

对第二应用系统的中转服务器中的日志数据进行关键词匹配，对满足匹配关系的日志数据进行数据同步。

优选的，当第二应用系统将其产生的日志数据进行关键词匹配，将满足匹配关系的日志数据备份到中转服务器时，所述抓取服务器具体用于：

对第二应用系统的中转服务器中的全部日志数据进行数据同步。

优选的，所述筛选服务器包括：

GuID提取模块，用于解析第一应用系统同步获取的日志数据，从所述日志数据预先约定的字段中提取出GuID；

筛选模块，用于在所述绑定关系中查找所述GuID，筛选出查找到的GuID对应的日志数据。

优选的，所述应用服务器包括：

展示模块，用于以GuID为标识将其对应的日志数据在所述第一应用系统中进行展示；

成就获取模块，用于对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断其用户是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示；

荣誉获取模块，用于对日志数据进行荣誉关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示；和/或

称号获取模块，用于比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在第一应用系统中形成社区动态信息进行展示。

优选的，所述第一应用系统为Web架构系统，所述第二应用系统为C/S架构系统。

本发明实施例提供的多应用系统间数据应用方法及系统，有益效果是：

通过一个应用系统可以从另一个(或多个)应用系统的中转服务器中的日志数据进行数据同步获取，根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，从第二应用系统同步获取的数据中筛选出满足绑定关系的日志数据，并按预设规则应用所述日志数据。从而实现了多应用系统间的信息互通，解决了人们需求与各应用系统间独立性之间的矛盾，为各应用系统的发展提供了一个新的平台。

另外，本发明实施例提供的方案，降低了对客户端的依赖，比如，在未安装游戏客户端的终端上，用户可以通过社区系统获取游戏系统中的数据，并在社区系统中进行应用，而无需一定要下载游戏客户端并安装才能实现，也进一步提高了用户体验。

还有，由于存储空间的限制，每个应用系统都会根据自己的功能需求，有选择性的存储用户数据，而对于未存储的数据，对于用户而言，在其它的应用系统中可能会比较有用，利用本发明实施例提供的方案，可以将这部分数据在其它应用系统中实现存储，并充分应用，不但提高了用户体验，而且，也在一定程度上缓解了存储压力的问题。

进一步的，由于本发明实施例中，多应用系统可以分别为不同架构的系统，比如第一应用系统可以是Web架构系统，第二应用系统可以是C/S架构系统，使得能够进一步实现多架构系统间的数据传输及应用，进一步提高用户体验。

附图说明

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

图1为本发明实施例一提供的方法流程图；

图2为本发明实施例二提供的方法流程图；

图3为本发明实施例三提供的方法流程图；

图4为本发明实施例四提供的系统结构框图；

图5为本发明实施例四中筛选服务器结构框图；

图6为本发明实施例五提供的系统结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

目前，各应用系统之间是独立运行、独立维护的，无法满足人们对应用日益增高的需求，如果在一个应用系统中嵌入另一个或另几个应用系统功能的话，存在很大的困难，其开发成本很高，周期也很长，因此，在一个应用系统中嵌入另一个或另几个应用系统的功能，来解决各应用系统独立性于人们需求之间的矛盾是不现实的。

本发明实施例提供一种多应用系统间数据应用方法及系统，以解决由于现有应用系统间的独立性导致限制其发展的问题。

实施例一

参见图1，本发明实施例提供了一种多应用系统间数据应用方法，包括如下步骤：

S101：第一应用系统从第二应用系统的中转服务器中的日志数据进行数据同步获取。

这里，第一应用系统、第二应用系统分别为多应用系统中的一个或多个。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

S102：根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，第一应用系统从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据。

S103：第一应用系统按预设规则应用所述日志数据。

本发明实施例中，通过一个应用系统可以从另一个(或多个)应用系统的中转服务器中的日志数据进行数据同步获取，根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，从第二应用系统同步获取的数据中筛选出满足绑定关系的日志数据，并按预设规则应用所述日志数据。从而实现了多应用系统间的信息互通，解决了人们需求与各应用系统间独立性之间的矛盾，为各应用系统的发展提供了一个新的平台。

另外，本发明实施例提供的方案，降低了对客户端的依赖，比如，在未安装游戏客户端的终端上，用户可以通过社区系统获取游戏系统中的数据，并在社区系统中进行应用，而无需一定要下载游戏客户端并安装才能实现，也进一步提高了用户体验。

还有，由于存储空间的限制，每个应用系统都会根据自己的功能需求，有选择性的存储用户数据，而对于未存储的数据，对于用户而言，在其它的应用系统中可能会比较有用，利用本发明实施例提供的方案，可以将这部分数据在其它应用系统中实现存储，并充分应用，不但提高了用户体验，而且，也在一定程度上缓解了存储压力的问题。

实施例二

参见图2，本发明实施例提供了一种多应用系统间数据应用方法，包括如下步骤：

S201：第一应用系统从第二应用系统的中转服务器中的日志数据进行数据同步获取。

需要说明的是，第一应用系统、第二应用系统分别为多应用系统中的一个或多个。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

这里，数据同步获取比如可以在linux系统下采用rsync技术进行数据的同步获取。

可以按预设时间间隔从第二应用系统的中转服务器进行同步获取，比如定时同步等方式，预设时间间隔可以是每日一次。

第一应用系统从第二应用系统的中转服务器同步获取日志数据的方式可以有多种，比如其中一种情况是，当第二应用系统将其产生的日志数据全部备份到中转服务器时，第一应用系统从第二应用系统的中转服务器中进行数据同步获取具体为：第一应用系统对第二应用系统的中转服务器中的日志数据进行关键词匹配，对满足匹配关系的日志数据进行数据同步。比如若想只获取与刷棋相关的日志数据，则设置关键词为“刷棋”，通过对第二应用系统的中转服务器中的日志数据进行“刷棋”关键词的匹配，对满足该匹配关系的日志数据进行数据同步。

另一种情况是，当第二应用系统将其产生的日志数据进行关键词匹配，将满足匹配关系的日志数据备份到中转服务器时，所述第一应用系统从第二应用系统的中转服务器中进行数据同步获取具体为：所述第一应用系统对第二应用系统的中转服务器中的全部日志数据进行数据同步。比如，若想只获取与刷棋相关的日志数据，则设置关键词为“刷棋”，第二应用服务器会对产生的日志数据先进行“刷棋”关键词的匹配，将满足该匹配关系的日志数据存储到中转服务器中，则第一应用系统便可以直接对第二应用系统的中转服务器中的全部日志数据进行数据同步获取，相对第一种情况而言，该方式进一步提高了数据同步获取的效率。

优选的，第一应用系统还可以利用安全机制从第二应用系统的中转服务器进行数据同步获取，以进一步提高安全性。

S202：根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，第一应用系统从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据。

预先将第一应用系统中的某些GuID与第二应用系统中的某些用户身份ID(比如游戏角色ID等)进行绑定，例如，将第一应用系统中的GuID A与第二应用系统中的用户身份ID a进行绑定，或将第一应用系统中的GuIDB与第二应用系统中的用户身份ID a、用户身份ID b进行绑定，实际应用中，可以是第一应用系统的GuID与第二应用系统中的用户身份ID进行一一绑定，也可以是一对多绑定，还可以是多对多绑定，本发明实施例并不限制。

这里，根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，第一应用系统从第二应用系统同步获取的日志数据中筛选出与第一应用系统GuID具有绑定关系的第二应用系统用户身份ID所对应的日志数据，也就是说，从第二应用系统的中转服务器中同步获取的日志数据中，经过本步骤的筛选操作，将未与第一应用系统GuID绑定的第二应用系统用身份ID所对应的日志数据筛掉。

优选的，筛选的方法可以是：

第一应用系统解析同步获取的日志数据，从所述日志数据预先约定的字段中提取出GuID，在所述绑定关系中查找所述GuID，筛选出查找到的GuID对应的日志数据。

S203：第一应用系统对筛选出日志数据进行格式转换，将其转换为能被所述第一应用系统识别的数据格式。

S204：第一应用系统将日志数据以GuID为标识进行存储。

S205：第一应用系统按预设规则应用上述日志数据。

这里，第一应用系统按预设规则应用上述日志数据的方法可以是：

第一应用系统以GuID为标识将其对应的日志数据在所述第一应用系统中进行展示。

第一应用系统对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断其用户是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示。

第一应用系统对日志数据进行荣誉关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示。

和/或，第一应用系统比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在第一应用系统中形成社区动态信息进行展示。等等。

本发明实施例中，第一应用系统和第二应用系统可以是相同架构的系统，也可以是不同架构的系统，此处并不限制，比如第一应用系统可以是Web架构系统，第二应用系统可以是C/S架构系统；或者，第一应用系统和第二应用系统可以都是Web架构系统，或者都是C/S架构系统。

可见，本发明实施例通过一个应用系统可以从另一个(或多个)应用系统的中转服务器中的日志数据进行数据同步获取，根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，从第二应用系统同步获取的数据中筛选出满足绑定关系的日志数据，并按预设规则应用所述日志数据。从而实现了多应用系统间的信息互通，解决了人们需求与各应用系统间独立性之间的矛盾，为各应用系统的发展提供了一个新的平台。

另外，本发明实施例提供的方案，降低了对客户端的依赖，比如，在未安装游戏客户端的终端上，用户可以通过社区系统获取游戏系统中的数据，并在社区系统中进行应用，而无需一定要下载游戏客户端并安装才能实现，也进一步提高了用户体验。

还有，由于存储空间的限制，每个应用系统都会根据自己的功能需求，有选择性的存储用户数据，而对于未存储的数据，对于用户而言，在其它的应用系统中可能会比较有用，利用本发明实施例提供的方案，可以将这部分数据在其它应用系统中实现存储，并充分应用，不但提高了用户体验，而且，也在一定程度上缓解了存储压力的问题。

进一步的，由于本发明实施例中，多应用系统可以分别为不同架构的系统，比如第一应用系统可以是Web架构系统，第二应用系统可以是C/S架构系统，使得能够进一步实现多架构系统间的数据传输及应用，进一步提高用户体验。

实施例三

参见图3，本发明实施例以SNS(Social Networking Service，社区网络服务)社区系统作为第一应用系统，游戏系统作为第二应用系统为例，介绍一种SNS社区系统与游戏系统间获取日志数据的方法。

其中，SNS社区系统提供了多种用户互动功能，比如博客、圈子、活动论坛、分类信息、商城、威客、悬赏等。其具有的功能主要包括：

注册和登录功能，用户可以注册多个社区帐号。注册是新用户进入并使用网站的途径，流程比如可以是，用户在网站点击注册，填写用户名及密码，进行邮箱验证，点击邮件链接返回激活帐户，进入网站。可以邀请注册，也可以自由注册，本发明实施例并不限制。用户可以选择“记住我”功能，以后可以直接登录网站而不用每次输入用户名和密码。

帐号绑定功能，将社区帐号与游戏系统中的游戏角色进行绑定，用户可以删除社区帐号，不影响游戏正常使用。

导航功能：为用户提供基本功能操作入口，比如可以固定显示在页面顶部。去访问他人页面时，顶部导航依然存在。可以有首页、我的首页、个人主页等标签页。其中个人主页为用户主页入口，为浏览他人时看到的页面。自己浏览时可以进行一些编辑、设置操作(如更换个人主页模板、个人资料编辑入口、图片上传入口)等。

好友功能，包括可以对社区中的好友进行集中管理，对最近来访的访客进行管理，也可以根据一定推荐规则和匹配规则给用户推荐的其它社区用户作为可能认识的人，用户可以申请加入或者退出红人馆，以便获得更多系统推荐机会，被推荐给陌生人，等等。

应用功能，比如日记、相册、礼物、选择好友发出动作、自定义动作、设置个人主页显示快捷动作入口等等。

拓展应用功能，比如发起投票、参与投票、发表评论；查看自己发起和参与的投票，查看好友发起的投票。再比如查看自己的星座分析，发起与好友的速配并查看速配历史结果，查看好友发起的速配等功能。还比如类似于百度知道的功能，提出问题、回答问题、问题/答案搜索，管理自己的问题和回答，查看好友的问题，全站回答问题总数排行榜。等等。

消息功能，比如站方公告、互动通知、好友申请、短消息、留言、评论等。

实际应用中，不同社区系统，所拥有的功能也不尽相同，这里不再一一赘述。

本发明实施例中，SNS社区系统中包括有抓取服务器，游戏系统中包括有中转服务器，中转服务器用于汇总所连接机房的游戏日志数据。实际应用中，SNS社区系统可以包括一个或多个抓取服务器，游戏系统中也可以包括一个或多个中转服务器，可以根据实际场景进行配置，本发明实施例并不限制。

本发明实施例提供的SNS社区系统从游戏系统间获取日志数据并进行应用的方法包括如下步骤：

步骤S301：SNS社区系统的抓取服务器按预设时间间隔，从游戏系统的中转服务器进行日志数据的同步获取。

优选的，可以采用linux系统中的rsync技术，进行数据同步。

预设时间间隔比如可以是每日一次，进行定时同步获取，可以在保证更新效率的同时，降低社区服务器的压力。

其中，游戏系统中产生的日志数据比如可以是聊天记录、取得的任务、成就、装备等。

步骤S302：筛选服务器根据社区系统中GuID与游戏系统中角色ID的绑定关系，从抓取服务器同步获取的日志数据中筛选出与社区系统中GuID具有绑定关系的游戏系统中角色ID所对应的日志数据。

举例说明，参见表1，比如SNS社区系统中注册的GuID：

表1

SNS社区系统中GuID
	A
B
	C
D

参见表2，游戏系统中注册的角色ID：

表2

游戏系统中角色ID
	a
b
	c
u

游戏系统中角色ID
	w

其中，A与a相绑定，C与c、w相绑定。

则，步骤S301中从游戏系统的各中转服务器同步获取的日志数据为，角色a、b、c、u所对应的全部日志数据。经本步骤筛选后，得到角色a、c、w所对应的日志数据。

步骤S303：筛选服务器对抓取服务器筛选后日志数据进行格式转换，将其转换为能被SNS社区系统识别的数据格式，以便在SNS社区界面中进行展示，供用户浏览查看。

步骤S304：将经格式转化后的日志数据以SNS社区系统中GuID为标识，存储于SNS社区系统的应用服务器中。

沿用上述例子，参见表3，将日志数据以SNS社区系统GuID为标识，在SNS社区系统应用服务器中的存储形式可以具体为：

表3

步骤S305：SNS社区应用服务器对以GuID为标识存储的日志数据按预设规则进行应用。

SNS社区应用服务器可以对以GuID为标识存储的日志数据进行多种应用，以下用几个实例具体说明，但并不作为本发明实施例的限制，可以根据具体应用设置不同的应用。

实例一：以GuID为标识将存储的日志数据在SNS社区系统中进行展示具体为，在GuID A的帐号下，展示(通常为在相关浏览器页面中显示)角色a在游戏系统中所对应的日志数据，在GuID C帐号下，展示(通常为在相关浏览器页面中显示)角色c、w在游戏系统中所对应的日志数据。当然，实际应用中，社区中的其它GuID可以依据预设的权限通过前台功能展示，间接查看或操作别人的日志数据。

实例二：可以是社区系统对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断该GuID是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示。

这里约定数据可以是约定的次数，或约定的时间等等。

举例说明，在本次同步获取的日志数据种，以杀死怪兽的次数为预设类型，筛选出GuID a杀死怪兽的次数相关的日志数据，将这些日志数据中的次数累加，得到GuID a对应的用户杀死怪兽的总次数，当达到预设的次数时，赋予GuID a对应的用户取得升2级的成就。

或者，以在某个山洞打坐的时间为预设类型，筛选出GuID a对应的用户在该山洞中打坐时间相关的日志数据，将这些日志数据中的时间累加，得到GuID a对应的用户在该山洞中打坐的总是建，当达到预设时间时，赋予GuIDa对应的用户取得升1级的成就，等等。

实例三：社区系统对日志数据进行关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示。比如以“状元”为关键词，对日志数据进行关键词匹配，若GuID a所对应的日志数据匹配上“状元”关键词(即在本次同步获取之前，GuID a在游戏系统中已经升级为“状元”)时，在社区系统中形成一条社区动态信息，在社区系统中进行展示。

这里，通常会将有价值的内容作为关键词，比如完成游戏系统中有一定难度的操作(活动、任务等)，或能够给玩家带来满足感和炫耀感的操作等。

实例四：社区系统比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在社区系统中形成社区动态信息进行展示。

比如，社区系统比较GuID A标识的有关打兽的日志数据，与社区中其它GuID标识的有关打兽的日志数据，当GuID A能够超过100个其它用户，则赋予GuID A对应的用户全能王的称号，并在SNS社区系统中形成社区动态信息进行展示。

需要说明的是，上述应用均是在SNS社区系统中进行的，而无需登录游戏系统，由于SNS社区系统的拓展性更强，可以对日志数据进行除了统计之外的应用，使得基于这些日志数据的应用功能和互动成为可能。

本发明实施例中，具体来说，解决了在游戏之外，运用玩家在游戏内的产生的操作日志数据，网络社区将玩家的操作日志进行加工处理，应用并呈现的问题。

由于游戏服务器是不会对类似于玩家的聊天记录等数据进行储存的。一方面是由于此类数据量过大，会导致游戏数据库压力过大；另一方面，这类数据的目前利用率不高，存储后对游戏没有很高的用途，因此对于传统游戏端服务器存在存储受限的问题。广义来说，解决了传统游戏端服务器存储限制的问题，使得通过网络社区对游戏历史操作的查询成为可能。游戏系统中的日志数据也属于海量数据，游戏一般不会对玩家的所有游戏行为进行记录，而是取其中一些有价值的进行储存以备统计分析用途。因此，一定程度上缓解了游戏服务器的处理压力，将一部分用户压力分散到社区服务器上。降低了游戏内开发成本高，周期长等风险。

拓展来说，社区系统可以基于对游戏日志数据的加工，在社区生成新的应用功能和玩法，对游戏的现有玩法进行拓展和补充。目前在游戏内对玩家的日志数据几乎没有什么应用，主要的应用也仅仅局限于游戏内的成就系统对其进行历史统计的功能。本发明实施例中，是由社区系统来实现对日志数据的应用，由于网络社区的拓展性更强，可以对日志数据进行除了统计之外的应用，使得基于这些日志数据的应用功能和互动成为可能。

实施例四

参见图4，本发明实施例提供一种多应用系统间数据应用系统，包括：

抓取服务器401，用于从第二应用系统的中转服务器中进行日志数据同步获取。

筛选服务器402，用于根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，从第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据；

应用服务器403，用于按预设规则应用所述日志数据。

这里，第一应用系统、第二应用系统分别为多应用系统中的一个或多个。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

优选的，筛选服务器402还包括：

格式转换模块，用于对筛选出日志数据进行格式转换，将其转换为能被所述第一应用系统识别的数据格式。

优选的，日志数据以GuID为标识存储在所述应用服务器中。

优选的，参见图5，筛选服务器402包括：

GuID提取模块4021，用于解析第一应用系统同步获取的日志数据，从所述日志数据预先约定的字段中提取出GuID；

筛选模块4022，用于在所述绑定关系中查找所述GuID，筛选出查找到的GuID对应的日志数据。

在本发明的一个实施例中，当第二应用系统将其产生的日志数据全部备份到中转服务器时，所述抓取服务器401具体用于：

对第二应用系统的中转服务器中的日志数据进行关键词匹配，对满足匹配关系的日志数据进行数据同步。

在本发明的另一个实施例中，当第二应用系统将其产生的日志数据进行关键词匹配，将满足匹配关系的日志数据备份到中转服务器时，所述抓取服务器具体用于：

对第二应用系统的中转服务器中的全部日志数据进行数据同步。

其中，应用服务器403包括：

展示模块，用于以GuID为标识将其对应的日志数据在所述第一应用系统中进行展示。

成就获取模块，用于对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断其用户是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示。

荣誉获取模块，用于对日志数据进行荣誉关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示。

和/或，称号获取模块，用于比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在第一应用系统中形成社区动态信息进行展示。等等。

本发明实施例中，第一应用系统和第二应用系统可以是相同架构的系统，也可以是不同架构的系统，此处并不限制，比如第一应用系统可以是Web架构系统，第二应用系统可以是C/S架构系统；或者，第一应用系统和第二应用系统可以都是Web架构系统，或者都是C/S架构系统。

需要说明的是，本发明实施例提供的多应用系统间数据获取系统，可以执行上述实施例一或实施例二中所述的方法，此处不再赘述。

可见，本发明实施例中，通过一个应用系统可以从另一个(或多个)应用系统的中转服务器中的日志数据进行数据同步获取，根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，从第二应用系统同步获取的数据中筛选出满足绑定关系的日志数据，并按预设规则应用所述日志数据。从而实现了多应用系统间的信息互通，解决了人们需求与各应用系统间独立性之间的矛盾，为各应用系统的发展提供了一个新的平台。

另外，本发明实施例提供的方案，降低了对客户端的依赖，比如，在未安装游戏客户端的终端上，用户可以通过社区系统获取游戏系统中的数据，并在社区系统中进行应用，而无需一定要下载游戏客户端并安装才能实现，也进一步提高了用户体验。

还有，由于存储空间的限制，每个应用系统都会根据自己的功能需求，有选择性的存储用户数据，而对于未存储的数据，对于用户而言，在其它的应用系统中可能会比较有用，利用本发明实施例提供的方案，可以将这部分数据在其它应用系统中实现存储，并充分应用，不但提高了用户体验，而且，也在一定程度上缓解了存储压力的问题。

进一步的，由于本发明实施例中，多应用系统可以分别为不同架构的系统，比如第一应用系统可以是Web架构系统，第二应用系统可以是C/S架构系统，使得能够进一步实现多架构系统间的数据传输及应用，进一步提高用户体验。

实施例五

参见图6，本发明实施例以SNS社区系统作为第一应用系统，游戏系统作为第二应用系统为例，介绍一种SNS社区系统从游戏系统间获取日志数据并应用的系统。

本发明实施例提供的系统中包括，包括SNS社区系统和游戏系统，下面结合一个具体应用场景进行描述如下：

架构说明：

中转服务器可连接多个游戏服务器。

抓取服务器，可连接多个中转服务器。

社区服务器可连接多个网络社区页面。

模块功能介绍：

一、社区系统中：

1.网络社区页面

即玩家在本地通过浏览器打开的社区页面。可以在其中触发相应的应用操作，对游戏历史操作日志进行应用。

2.抓取服务器

用来对各个日志中转服务器中的玩家游戏日志数据进行定期获取。

3、筛选服务器

用来对获取的游戏日志数据进行筛选，以及格式转换。

4.应用服务器

用来存储玩家的游戏日志数据。

二、游戏系统中：

1.中转服务器

用来存储所连接的各个游戏服务器的玩家游戏日志。

2.游戏服务器

游戏服务器是管理所有游戏客户端的模块。游戏服务器可以根据玩家在游戏中的操作，生成相应的日志数据。

本发明实施例中，具体来说，解决了在游戏之外，运用玩家在游戏内的产生的操作日志数据，网络社区将玩家的操作日志进行加工处理，应用并呈现的问题。

由于游戏服务器是不会对类似于玩家的聊天记录等数据进行储存的。一方面是由于此类数据量过大，会导致游戏数据库压力过大；另一方面，这类数据的目前利用率不高，存储后对游戏没有很高的用途，因此对于传统游戏端服务器存在存储受限的问题。广义来说，解决了传统游戏端服务器存储限制的问题，使得通过网络社区对游戏历史操作的查询成为可能。游戏系统中的日志数据也属于海量数据，游戏一般不会对玩家的所有游戏行为进行记录，而是取其中一些有价值的进行储存以备统计分析用途。因此，一定程度上缓解了游戏服务器的处理压力，将一部分用户压力分散到社区服务器上。降低了游戏内开发成本高，周期长等风险。

拓展来说，社区系统可以基于对游戏日志数据的加工，在社区生成新的应用功能和玩法，对游戏的现有玩法进行拓展和补充。目前在游戏内对玩家的日志数据几乎没有什么应用，主要的应用也仅仅局限于游戏内的成就系统对其进行历史统计的功能。本发明实施例中，是由社区系统来实现对日志数据的应用，由于网络社区的拓展性更强，可以对日志数据进行除了统计之外的应用，使得基于这些日志数据的应用功能和互动成为可能。

可以理解的是，本发明实施例可用于众多通用或专用的网络应用系统环境或配置中。其中，各服务器例如可以是：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本发明实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本领域普通技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，包括若干指令用以执行本发明各个实施例所述的方法。这里所述的存储介质，如：ROM/RAM、磁碟、光盘等。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (18)

1.一种多应用系统间数据应用方法，其特征在于，包括：

第一应用系统从第二应用系统的中转服务器中进行日志数据同步获取；

根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，第一应用系统从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据；

第一应用系统按预设规则应用所述日志数据。

2.根据权利要求1所述的方法，其特征在于，所述筛选后还包括：

第一应用系统对筛选出日志数据进行格式转换，将其转换为能被所述第一应用系统识别的数据格式。

3.根据权利要求1所述的方法，其特征在于，所述第一应用系统将日志数据以GuID为标识进行存储。

4.根据权利要求1所述的方法，其特征在于，当第二应用系统将其产生的日志数据全部备份到中转服务器时，所述第一应用系统从第二应用系统的中转服务器中进行日志数据同步获取具体为：

所述第一应用系统对第二应用系统的中转服务器中的日志数据进行关键词匹配，对满足匹配关系的日志数据进行数据同步。

5.根据权利要求1所述的方法，其特征在于，当第二应用系统将其产生的日志数据进行关键词匹配，将满足匹配关系的日志数据备份到中转服务器时，所述第一应用系统从第二应用系统的中转服务器中进行数据同步获取具体为：

所述第一应用系统对第二应用系统的中转服务器中的全部日志数据进行数据同步。

6.根据权利要求1所述的方法，其特征在于，第一应用系统在linux系统下采用rsync技术从第二应用系统的中转服务器中的日志数据进行数据同步获取。

7.根据权利要求1所述的方法，其特征在于，所述根据第一应用系统GuID与第二应用系统用户身份ID的绑定关系，第一应用系统从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据具体为：

解析第一应用系统同步获取的日志数据，从所述日志数据预先约定的字段中提取出GuID，在所述绑定关系中查找所述GuID，筛选出查找到的GuID对应的日志数据。

8.根据权利要求1所述方法，其特征在于，所述第一应用系统按预设规则应用所述日志数据具体为：

第一应用系统以GuID为标识将其对应的日志数据在所述第一应用系统中进行展示；

第一应用系统对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断其用户是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示；

第一应用系统对日志数据进行荣誉关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示；和/或

第一应用系统比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在第一应用系统中形成社区动态信息进行展示。

9.根据权利要求1所述的方法，其特征在于，所述第一应用系统为Web架构系统，所述第二应用系统为C/S架构系统。

10.根据权利要求1所述的方法，其特征在于，所述第二应用系统的用户身份ID具体为用户的角色ID。

11.一种多应用系统间数据应用系统，其特征在于，包括：

抓取服务器，用于从第二应用系统的中转服务器中进行日志数据同步获取；

筛选服务器，用于根据第一应用系统用户识别码GuID与第二应用系统用户身份识别码ID的绑定关系，从所述第二应用系统同步获取的数据中筛选出满足所述绑定关系的日志数据；

应用服务器，用于按预设规则应用所述日志数据。

12.根据权利要求11所述的系统，其特征在于，所述筛选服务器还包括：

格式转换模块，用于对筛选出日志数据进行格式转换，将其转换为能被所述第一应用系统识别的数据格式。

13.根据权利要求11所述的系统，其特征在于，日志数据以GuID为标识存储在所述应用服务器中。

14.根据权利要求11所述的系统，其特征在于，当第二应用系统将其产生的日志数据全部备份到中转服务器时，所述抓取服务器具体用于：

对第二应用系统的中转服务器中的日志数据进行关键词匹配，对满足匹配关系的日志数据进行数据同步。

15.根据权利要求11所述的系统，其特征在于，当第二应用系统将其产生的日志数据进行关键词匹配，将满足匹配关系的日志数据备份到中转服务器时，所述抓取服务器具体用于：

对第二应用系统的中转服务器中的全部日志数据进行数据同步。

16.根据权利要求11所述的系统，其特征在于，所述筛选服务器包括：

GuID提取模块，用于解析第一应用系统同步获取的日志数据，从所述日志数据预先约定的字段中提取出GuID；

筛选模块，用于在所述绑定关系中查找所述GuID，筛选出查找到的GuID对应的日志数据。

17.根据权利要求11所述的系统，其特征在于，所述应用服务器包括：

展示模块，用于以GuID为标识将其对应的日志数据在所述第一应用系统中进行展示；

成就获取模块，用于对满足预设类型的日志数据进行过滤，并对过滤结果中每个GuID所标识的日志数据进行累加，根据累加结果判断其用户是否取得预定成就，赋予累加结果达到该成就约定数值的用户取得该成就，并在社区系统中形成社区动态信息进行展示；

荣誉获取模块，用于对日志数据进行荣誉关键词匹配，将匹配上的日志数据形成社区动态信息，在社区系统中进行展示；和/或

称号获取模块，用于比较不同GuID标识的日志数据，根据比较结果判断其用户是否取得预设称号，赋予比较结果满足预设条件的用户取得该称号，并在第一应用系统中形成社区动态信息进行展示。

18.根据权利要求11所述的系统，其特征在于，所述第一应用系统为Web架构系统，所述第二应用系统为C/S架构系统。

Images