CN105930211B - 一种应用数据获取的方法以及服务器 - Google Patents

Abstract

本发明实施例公开了一种应用数据获取的方法，包括：在第一预置时间内获取主交互式应用的数据，主交互式应用的数据携带关联主题号，第一预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为主交互式应用的关闭时刻；若根据关联主题号确定开启辅交互式应用，则获取第二预置时间内辅交互式应用的数据，第二预置时间包含第一预置时间，第二预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为辅交互式应用的结束时刻；将辅交互式应用的数据发送至用于展示数据的用户设备。本发明实施例还提供一种服务器。本发明实施例使用户设备有效地利用电量和网络资源，提升用户设备的使用效率，有利于用户设备的良好运行。

Description

一种应用数据获取的方法以及服务器

技术领域

本发明涉及互联网技术领域，尤其涉及一种应用数据获取的方法以及服务器。

背景技术

随着应用程序(英文全称：Application，英文缩写：APP)的普及，近年来，越来越多的用户通过使用APP来打发时间，开发更具有娱乐性的APP逐渐成为了业内趋势。

目前，已推出相关交互式应用，其功能主要为，在一段时间内用户可以选择某项功能进行操作，例如用户在2分钟30秒内完成某个交互式应用中的甲项目，并于3分钟后可以知道自己对甲项目的操作结果是否正确。

然而，从用户完成项目的时刻到用户等待操作结果的时刻之间还存在一段“空白”时间，以现有技术为例，假设用户刚好在2分30秒的这一刻完成了某个交互式应用中的甲项目，那么这段“空白”时间就是30秒，这段时间内用户只能选择对其他的交互式应用进行操作，或者不对该用户设备上的任何交互式应用进行操作，而在这段时间内仍旧在消耗用户设备的电量，并占用着网络资源，从而造成用户设备的运行效率降低，不利于用户设备的良好运行。

发明内容

本发明实施例提供了一种应用数据获取的方法以及服务器，可以在“空白”时间内对用户设备中的辅交互式应用进行操作，从而使用户设备在这段时间里有效地利用了电量和网络资源，并根据相应的操作进行辅交互式应用的进程，提升了用户设备的使用效率，有利于用户设备的良好运行。

有鉴于此，本发明第一方面提供一种应用数据获取的方法，包括：

在第一预置时间内获取主交互式应用的数据，其中，所述主交互式应用的数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；

若根据所述关联主题号确定开启辅交互式应用，则获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；

将所述辅交互式应用的数据发送至用于展示数据的用户设备。

第二方面，本方面实施例还提供一种服务器，包括：

第一获取模块，用于在第一预置时间内获取主交互式应用的数据，其中，所述主交互式应用的数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；

第二获取模块，用于若根据所述第一获取模块获取的所述关联主题号确定开启辅交互式应用，则获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；

展示模块，用于将所述第二获取模块获取的所述辅交互式应用的数据发送至用于展示数据的用户设备。

第三方面，本方面实施例还提供一种服务器，包括：输入装置、输出装置、存储器和处理器；

所述处理器用于执行所述存储器中的程序，具体如下步骤：

控制所述输入装置在第一预置时间内获取主交互式应用的数据，其中，所述数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；

若根据所述关联主题号确定开启辅交互式应用，则控制所述输入装置获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；

将所述辅交互式应用的数据发送至用于展示数据的用户设备。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例中，提供了一种应用数据获取的方法，首先服务器在第一预置时间内获取主交互式应用的数据，其中，主交互式应用的数据中携带关联主题号，第一预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为所述主交互式应用的关闭时刻，接着服务器可以在确定开启辅交互式应用后，获取第二预置时间内辅交互式应用的数据，第二预置时间包含第一预置时间，第二预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为辅交互式应用的结束时刻，将辅交互式应用的数据发送至用于展示数据的用户设备。由此，可以在“空白”时间内对用户设备中的辅交互式应用进行操作，从而使用户设备在这段时间里有效地利用了电量和网络资源，并根据相应的操作进行辅交互式应用的进程，提升了用户设备的使用效率，有利于用户设备的良好运行。

附图说明

图1为本发明实施例中A应用的用户界面示意图；

图2为本发明实施例中用于实现应用数据获取的平台系统架构图；

图3为本发明实施例中应用数据获取的方法一个实施例示意图；

图4为本发明实施例中交互式应用期号生成的时序示意图；

图5为本发明实施例中交互式应用主题开盘的时序示意图；

图6为本发明实施例中辅交互式应用撤单的时序示意图；

图7为本发明实施例中交互式应用主题关盘的时序示意图；

图8为本发明实施例中辅交互式应用开奖的时序示意图；

图9为本发明实施例服务器一个实施例示意图；

图10为本发明实施例服务器另一个实施例示意图；

图11为本发明实施例服务器另一个实施例示意图；

图12为本发明实施例服务器另一个实施例示意图；

图13为本发明实施例服务器另一个实施例示意图；

图14为本发明实施例服务器另一个实施例示意图；

图15为本发明实施例服务器另一个实施例示意图；

图16为本发明实施例服务器另一个实施例示意图；

图17为本发明实施例服务器另一个实施例示意图；

图18为本发明实施例服务器一个结构示意图。

具体实施方式

本发明实施例提供了一种应用数据获取的方法以及服务器，可以在“空白”时间内对用户设备中的辅交互式应用进行操作，从而使用户设备在这段时间里有效地利用了电量和网络资源，并根据相应的操作进行辅交互式应用的进程，提升了用户设备的使用效率，有利于用户设备的良好运行。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应理解，本发明方案可以适用于微信或者手机QQ中的竞猜类业务，具体可以是应用于娱乐大厅里的A应用中，可以理解的是，本发明方案不仅限于应用在该应用中，但是为了便于描述，将以应用于A应用为例进行介绍。

A应用是一款根据动态实时指数来竞猜指数涨跌的竞猜类游戏，在A应用原有的页面中有动态实时的指数显示，虚拟出一分半钟一场，真实场三分钟一场，用户根据每回合游戏开始时给出的标准指数来猜一段时间以后截止时的指数，相对于标准指数是涨还是跌。假如标准指数是3000.20点，用户可以猜3分钟后指数是大于3000.20点，还是小于3000.20点，亦或是等于3000.20点，并下注。开奖后，若用户猜对则可以得到系统的派奖。但是考虑到用户在猜完指数涨跌后会有一段时间需要等待开奖结果，因此，采用本发明方案对A应用进行改进，使得用户在等待开奖结果的这段时间里可以进行辅游戏，这样即可解决开奖等待时间内用户无事可做的问题，也可以提升A应用的虚拟资产流水问题。

具体地，请参阅图1，图1为本发明实施例中A应用的用户界面示意图，如图所示，系统将猜指数涨跌作为主游戏，将猜指数尾数的单双数作为辅游戏，用户首先通过用户设备提供的用户界面(英文全称：User Interface，英文缩写：UI)对猜指数涨跌进行下注操作，其UI的显示如图1中左图所示，在当前赔率为1.86的情况下，选择虚拟场在14点40分时的指数是否超过3321.12。用户在一局游戏中，第一次对猜指数涨跌下注之后将弹出辅游戏的对话框，用户可以选择关闭辅游戏，也可以选择作出相应的投注。若用户选择进行辅游戏，则UI的显示如图1中右图所示，在赔率为1.86的情况下，选择指数的尾数是单数还是双数，其中，这里辅游戏中猜测的指数与主游戏中猜测的指数保持一致。

需要说明的是，辅游戏除了有猜指数尾数的单双数以外，也可以是猜指数尾数的范围，或者是猜指数尾数的数字，还可以是猜个别位数的数字等其他玩法，此处不做限定。

然而A应用的辅游戏是在原有的A应用中新增的内容，因此需要兼容原有的A应用内容，A应用为整个竞猜平台的产品之一，下面将对该竞猜平台进行介绍，以了解A应用所在的系统架构是如何运作的。

请参阅图2，图2为本发明实施例中用于实现应用数据获取的平台系统架构图，如图所示，A应用所在的竞猜平台中具有多个其他的应用程序，例如“全民猜猜猜”、“猜篮球”、“猜大小”、“赏金答题”以及“实物兑换”，这些应用程序之间是相互独立的，但是在每个应用程序工作时，则需要采用竞猜平台系统中的其他组成部分，为了便于理解，下面将分别介绍与A应用相关的重要部分：

(1)图2中的下单应用程序开发平台(英文全称：ArcObjects，英文缩写：AO)主要用于完成用户参与竞猜的核心交易过程，包括参数校验、风控校验、业务订单生成、支付、订单状态更新、风控上报、都柏林核心元(英文全称：Dublin Core，英文缩写：DC)数据上报、交易成功消息队列(英文全称：Message Queue，英文缩写：MQ)发送等过程。为了尽量缩短核心路径，采用异步的方式进行风控上报和DC数据上报，其他同步处理过程的异常，均有对应的异常处理程序予以处理；

(2)图2中的主题AO服务主要用于提供主题相关的创建、更新、查询和赔率交互等服务接口，其中，赔率交互通过异步通知来处理；

(3)图2中的算派服务主要用于提供订单算奖服务，对于快频类应用，如A应用引入了本地实时算奖加快了算派效率，算派服务计时器(英文全称：timer)实现了多机部署，通过接入网页应用程序开发框架ZK支持动态切换，避免单点问题；

(4)图2中的异常处理服务主要用于负责处理核心交易过程中的异常，保证系统的可靠性，由于订单状态可回溯，且全流程可重入，因此，对于竞猜交易过程每一步异常均可通过异常处理服务异步重试不就，保证核心流程每一个异常有合理的出口；

(5)图2中的主题timer服务主要用于负责期号生成、主题开关盘、开奖、撤单以及与风控数据的交互，其中，期号生成用于周期性竞猜的应用，主题timer服务接入网页应用程序开发框架ZK，实现多机部署，能够动态切换，避免单点问题；

(6)图2中的支撑系统主要用于为竞猜系统提供代币支付、风控赔率控制、数据服务以及触达服务；

(7)图2中的运营后台管理系统主要用于为运营和产品提供统一的竞猜后台管理工具，如“全民猜猜猜”的题库管理、主题上下架、开奖结果录入和撤单等功能，提供运营效率。

请参阅图3，本发明实施例中应用数据获取的方法一个实施例包括：

101、在第一预置时间内获取主交互式应用的数据，其中，主交互式应用的数据中携带关联主题号，第一预置时间的起始时刻为主交互式应用的开启时刻，第一预置时间的结束时刻为主交互式应用的关闭时刻；

本实施例中，服务器在第一预置时间内获取主交互式应用的数据，用户在第一预置时间内通过用户设备向服务器发送主交互式应用的数据。第一预置时间的起始时刻就是主交互式应用的开启时刻，假设起始时刻为10点整，而第一预置时间的结束时刻为主交互式应用的关闭时刻，结束时刻假设为10点2分30秒，那么第一预置时间可以理解为是2分30秒。服务器在这2分30秒以内获取主交互式应用的数据。

然而，为了便于区分不同时刻获取到的数据是否为同一轮数据，可以对数据进行关联主题号的添加。具体地，以A应用为例，关联主题号即为期号，是一轮竞猜游戏的完整编号，其生成规则如下：

关联主题号＝T+日期[6位]+guessType[2位]+分库[2位]+分表[2位]+uid[3位]+玩法类型(2位)+股指类型(2位)+股票代号+期序号(4位)

其中，T为具体时间，例如上午的10点整，可以用100000表示，日期为当前日期，例如2016年4月13日，可以用160413表示，guessType为竞猜类型，分库和分表是指数据库的划分和表的划分，uid为用户身份证明(英文全称：(User Identification，英文缩写：UID)，玩法类型是由系统预先定义的，不同的数据标识不同的玩法类型，股指类型是指不同类型的股票，例如深股、沪股或者港股等，股票代号就是用户选择股票的股票代码，期序号则是本轮竞猜的期数。

102、若根据关联主题号确定开启辅交互式应用，则获取第二预置时间内辅交互式应用的数据，其中，第二预置时间包含第一预置时间，第二预置时间的起始时刻为主交互式应用的开启时刻，第二预置时间的结束时刻为辅交互式应用的结束时刻；

本实施例中，主交互式应用的数据中携带关联主题号应该与辅交互式应用携带的关联主题号一致，以使得两者可以保持状态的一致性。

服务器根据关联主题号查找与该关联主题号一致的辅交互式应用，如果找到关联主题号一致的辅交互式应用，则确定辅交互式应用已经被开启。这时候，服务器可以尝试获取第二预置时间内的辅交互式应用的数据。第二预置时间的起始时刻也为主交互式应用的开启时刻，假设主交互式应用的开启时刻为10点整，第二预置时间的结束时刻为辅交互式应用的结束时刻，辅交互式应用的结束时刻假设为10点3分，而主交互式应用的结束时刻假设为10点2分30秒，那么第二预置时间为3分钟，第一预置时间为2分30秒，第二预置时间包含了第一预置时间，服务器获取第二预置时间内辅交互式应用的数据。

可以理解的是，以A应用为例进行介绍，假设主交互式应用是竞猜指数涨跌，辅交互式应用是竞猜指数尾数，每轮主交互式应用与辅交互式应用的竞猜开始时间和开奖时间都是一样的，但是用户投注截至的时间不一样，主交互式应用提前截至投注，辅交互式应用在主交互式应用投注截至后一段时间截至。

103、将辅交互式应用的数据发送至用于展示数据的用户设备。

本实施例中，由于主交互式应用的数据会在第一预置时间内实时地通过用户设备展示给用户，而辅交互式应用的数据则需要在第二预置时间内获取到后，再通过用户设备展示给用户，使得用户也能够实时地在第二预置时间内对辅交互式应用进行操作，例如，投注或者等待开奖等。

本发明实施例中，提供了一种应用数据获取的方法，首先服务器在第一预置时间内获取主交互式应用的数据，其中，主交互式应用的数据中携带关联主题号，第一预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为所述主交互式应用的关闭时刻，接着服务器可以在确定开启辅交互式应用后，获取第二预置时间内辅交互式应用的数据，第二预置时间包含第一预置时间，第二预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为辅交互式应用的结束时刻，将辅交互式应用的数据发送至用于展示数据的用户设备。由此，可以在“空白”时间内对用户设备中的辅交互式应用进行操作，从而使用户设备在这段时间里有效地利用了电量和网络资源，并根据相应的操作进行辅交互式应用的进程，提升了用户设备的使用效率，有利于用户设备的良好运行。

可选地，在上述图3对应的实施例的基础上，本发明实施例提供应用数据获取的方法第一个可选实施例中，主交互式应用的数据包括实时数据和/或虚拟数据；

在第一预置时间内获取主交互式应用的数据，可以包括：

检测第一预置时间是否为预设处理时间；

若是，则确定主交互式应用的数据为实时数据或虚拟数据；

若否，则确定主交互式应用的数据为虚拟数据。

本实施例中，主交互式应用的数据可以包括实时数据和/虚拟数据，当然，辅交互式应用的数据也可以包括实时数据和/或虚拟数据。

假设以A应用为例进行介绍，服务器需要检测当前获取主交互式应用数据的第一预置时间是否在预设处理时间内，预设处理时间与股票开市时间一致，通常是工作日的上午9点半至11点半，下午是从13点至15点，这段时间内获取的数据既可以是股市当前的实时数据，也可以是随机生成的虚拟数据。但是，如果第一预置时间不在预设处理时间以内，则只能采用虚拟数据来进行处理。

采用实时数据具有可预测性，更贴近现实，比如针对预测股票指数，可以考虑比较多的方面，因为影响股票涨跌的因素有很多，可以是政策的利空利多、大盘环境的好坏、主力资金的进出、个股基本面的重大变化、个股的历史走势的涨跌情况或者个股所属板块整体的涨跌情况等。

然而采用虚拟数据也可以在非开市的时间段内进行娱乐，随机的数据虽然难以预测，但是从另一方面来看，也可以增强用户体验的趣味性。

其次，本发明实施例中，主交互式应用以及辅交互式应用都可以针对不同的数据进行处理，服务器既可以获取当前变化的实时数据，也可以获取随机性强的虚拟数据。然而实时数据通常会显示在一条动态变化的曲线上，用户能够根据曲线的变化趋势来判断后续可能会出现的数据，使得方案更具有实时性和趣味性，提升用户的使用体验。虚拟数据是在当前无法使用实时数据或者不想使用实时数据时，提供给用户进行处理的数据，由此，为方案提供了多种实现方式，从而加强方案的灵活性。

可选地，在上述图3对应的实施例的基础上，本发明实施例提供应用数据获取的方法第二个可选实施例中，获取第二预置时间内辅交互式应用的数据之前，还可以包括：

根据主交互式应用的关联主题号，查询与主交互式应用的关联主题号一致的辅交互式应用；

若辅交互式应用的关联主题号与主交互式应用的关联主题号一致，则确定辅交互式应用已开启。

本实施例中，在服务器获取第二预置时间内辅交互式应用的数据之前，可以根据主交互式应用的关联主题号对辅交互式应用进行检测，如果查询到辅交互式应用的关联主题号与主交互式应用的关联主题号一致，则可以确定与主交互式应用同步的辅交互式应用已经开启。

具体地，以A应用为例进行介绍，请参阅图4，图4为本发明实施例中交互式应用期号生成的时序示意图，如图所示，ao_gs_topic为核心服务中的下单AO服务和主题AO服务，可以统称为AO服务，dao_gs_topic为核心服务中的订单数据访问对象(英文全称：DataAccessObject，英文缩写：DAO)服务和主题DAO服务，可以统称DAO服务，系统则为上述实施例中提到的平台系统，下面将对各个步骤进行介绍：

步骤201：在系统侧首先校验是否处于停售日期，比如停售日期可以是周六或者周日，也可以是其他法定节假日，这些日子里不进行实时数据的获取，该步骤是循环进行的，即每次开启主交互式应用都会进行检测，并且一次遍历其他配置项；

步骤202：如果经过步骤201得到当前日期不在停售日期范围内，也不在休市的范围内时，则生成盘口竞猜内容等信息，盘口竞猜内容可以是在股票交易过程中显示的交易动向信息，例如当前指数、个数指数或者收盘价格等，此处不作限定；

步骤203：系统向AO服务发送创建主题的请求，该请求用于创建与主交互式应用相关的主题内容，例如，该主题可以是竞猜指数涨跌；

步骤204：AO服务在收到该请求之后，将生成与该请求相关主题的关联主题号，具体生成方式已在上述实施例中说明，此处不作赘述，当然，在生成关联主题号(或者期号)后，还可以进行脚本定义校验，校验失败则会重新生成新的关联主题号(或者期号)；

步骤205：关联主题号创建完成后，AO服务将校验主交互式应用的主题是否生成，如果成功生成，则继续后续辅交互式应用的主题创建以及数据获取，如果生成失败，则继续步骤206；

步骤206：在主交互式应用没有成功生成的时候，AO服务插入主题信息至数据库(英文全称：database，英文缩写：DB)，因为主交互式应用与辅交互式应用使用同一个DB，因此辅交互式应用也得知主交互式应用的主题生成失败，DAO服务会返回一个结果给AO服务；

步骤207：AO服务再与风控系统进行同步处理，使得风控系统也得知当前主交互式应用的主题生成失败，此时，风控系统也将反馈一个结果给AO服务；

步骤208：AO服务得到返回结果之后，更新主题状态为未开盘状态，并通知DAO服务，DAO服务收到通知后，反馈结果给AO服务，其中AO服务在上述实施例中已经进行介绍，故此处不再赘述，而DAO服务则是用于反馈AO服务的操作是否得到响应。

可以理解的是，为保证整个平台系统关联主题号的协调统一，将主交互式应用和辅交互式应用的主题分开生成，不将辅交互式应用的竞猜信息存入主交互式应用主题中，但是主题结构一致。为保证主辅交互式应用的关联关系，在生成主题时，将对应关系主题号存入数据库字段。生成主题时，采用主、辅交互式应用主题分开生成，不交叉生成的方式。

其次，本发明实施例中，提供了一种可以通过关联主题号确定与主交互式应用一致的辅交互式应用，并且检测出辅交互式应用是否已经开启了，如果开启，则获取辅交互式应用的数据。采用关联主题号关联主交互式应用与辅交互式应用，保证两者的开奖结果一致，从而保证方案的一致性，从而使得采用该方案的产品有更好的信誉以及口碑。

可选地，在上述图3对应的第二个实施例的基础上，本发明实施例提供应用数据获取的方法第三个可选实施例中，获取第二预置时间内辅交互式应用的数据之前，还可以包括：

根据主交互式应用的关联主题号，获取主交互式应用的状态信息，其中，主交互式应用的状态信息用于指示主交互式应用是否处于开启状态；

当根据主交互式应用的状态信息确定主交互式应用处于开启状态时，则更新辅交互式应用的状态信息。

本实施例中，服务器在获取第二预置时间内辅交互式应用的数据之前，可以根据主交互式应用的关联主题号，查找与该关联主题号相关的主交互式应用的状态信息，通常，状态信息包括了开启状态，关闭状态等。在服务器获取到该主交互式应用的状态信息后，判断是否处于开启状态，如果判断得到主交互式应用已开启，则通知辅交互式应用可以更新状态信息，否则，辅交互式应用不能随意的变更状态。

具体地，以A应用为例进行介绍，请参阅图5，图5为本发明实施例中交互式应用主题开盘的时序示意图，如图所示，ao_gs_topic为核心服务中的下单AO服务和主题AO服务，可以统称为AO服务，dao_gs_topic为核心服务中的订单DAO服务和主题DAO服务，可以统称DAO服务，系统则为上述实施例中提到的平台系统，下面将对各个步骤进行介绍：

步骤301：系统在一段时间内扫描已经开启的辅交互式应用的主题，扫描成功后，由DAO服务向系统反馈一个结果，使系统知道已扫描成功；

步骤302：系统开始依次循环遍历主交互式应用的主题和辅交互式应用的主题，以实时地得到主交互式应用和辅交互式应用的状态信息。当检测到主交互式应用的开盘时间已到，说明已经开启数据的获取，于是通过函数Fofficial_id获取主交互式应用的主题信息，并得到DAO服务的反馈结果；

步骤303：系统再根据主交互式应用的主题状态信息，通过AO服务更新辅交互式应用的状态信息，并收到DAO服务的返回结果。

换言之，主交互式应用未开启时，辅交互式应用也不会开启，而在主交互式应用开启，但辅交互式应用未开启时，系统将继续扫描辅交互式应用。因此，本方案仍以主交互式应用是否开启状态作为方案后续执行的主要依据。

其次，本发明实施例中，服务器根据主交互式应用的关联主题号，获取主交互式应用的状态信息，其中，主交互式应用的状态信息用于指示主交互式应用是否处于开启状态，当根据主交互式应用的状态信息确定主交互式应用处于开启状态时，则更新辅交互式应用的状态信息。在主交互式应用未开启时，辅交互式应用也不会开启，但是在主交互式应用开启时，辅交互式应用开启失败时，主交互式应用仍可以进行，由此，不但可以保证主交互式应用和辅交互式应用的一致性，还可以使辅交互式应用称为主交互式应用的辅助功能，并不会出现本末倒置的情况，仍以主交互式应用为主进行操作，从而增强方案的实用性和可行性。

可选地，在上述图3对应的第三个实施例的基础上，本发明实施例提供应用数据获取的方法第四个可选实施例中，还可以包括：

当主交互式应用的数据出现数据异常时，则更新主交互式应用的状态信息；

根据更新后的主交互式应用的状态信息，将主交互式应用的数据进行撤回处理；

对辅交互式应用的数据进行撤回处理。

本实施例中，主题撤单主要是由于数据持续异常，造成收益数据不可控情况下的一种解决方式，当主交互式应用的数据出现数据异常时，则服务器先更新主交互式应用的状态信息，将开启状态更新为关闭状态，或者异常状态，服务器再根据更新后的主交互式应用的状态信息，将主交互式应用的数据进行撤回处理，再对辅交互式应用的数据进行撤回处理。

需要说明的是，如果撤单失败，系统将出现警告，并且服务器会继续扫描主交互式应用的主题和辅交互式应用的主题，以进行撤单处理。

具体地，以A应用为例进行介绍，请参阅图6，图6为本发明实施例中辅交互式应用撤单的时序示意图，如图所示，ao_gs_topic为核心服务中的下单AO服务和主题AO服务，可以统称为AO服务，dao_gs_topic为核心服务中的订单DAO服务和主题DAO服务，可以统称DAO服务，系统则为上述实施例中提到的平台系统，下面将对各个步骤进行介绍：

步骤401：系统在一段时间内扫描主交互式应用和/或辅交互式应用的主题，扫描成功后，由DAO服务向系统反馈一个结果，使系统知道已扫描成功；

步骤402：系统通过函数Fofficial_id获取主交互式应用的主题信息，并得到DAO服务的返回结果，每次系统扫描到主交互式应用和/或辅交互式应用的主题后，都会依次遍历缓存中的主题，以实时得到各主题的状态信息；

步骤403：系统进而判断主交互式应用的状态信息是否为开启状态，如果不是开启状态，则可能出现了数据异常的情况，于是可以将主交互式应用的状态信息更改为竞猜取消状态；

步骤404：如果主交互式应用的状态信息为竞猜取消，则也将辅交互式应用的状态信息更新为竞猜取消，更新成功后，DAO服务将反馈一个结果。

再次，本发明实施例中，还进一步提供了一种针对主题撤单的方案当主交互式应用的数据出现数据异常时，则服务器先更新主交互式应用的状态信息，再根据更新后的主交互式应用的状态信息，将主交互式应用的数据进行撤回处理，然后对辅交互式应用的数据进行撤回处理。采用上述方式完成主题撤单，可以防止由于数据持续异常，造成收益数据不可控的现象。通过主题撤单的方式不仅能保证平台不亏损，而且也不会损害用户的利益，数据异常时，辅交互式应用会根据主交互式应用的撤单同步进行撤单处理，达到两者的一致性，从而提升方案的实用性。

可选地，在上述图3对应的实施例的基础上，本发明实施例提供应用数据获取的方法第五个可选实施例中，还可以包括：

若在第一预置时间内未获取主交互式应用的数据，则停止开启辅交互式应用。

本实施例中，当在第一预置时间内一直没有获取到主交互应用的数据时，则不开启辅交互应用，也不获取辅交互式应用的数据。

导致在第一预置时间内没有获取主交互式应用的数据的情况有多种，例如，用户迟迟不对主交互式应用进行任何操作，或者，用户对主交互式应用发起了误操作，或者，用户设备出现状况，无法识别用户的操作等，此处不作限定。

进一步地，本发明实施例中，如果在第一预置时间内一直没有获取到主交互式应用的数据，则也将停止对辅交互应用数据的获取。采用上述机制，不但可以到达主交互式应用与辅交互式应用的同步，还可以节省网络资源，不会在主交互式应用数据获取失败的情况下，还持续获取辅交互式应用的数据，导致得到的辅交互式应用数据不能作为有效数据的情况。由此提升方案的可行性和可操作性。

可选地，在上述图3对应的实施例的基础上，本发明实施例提供应用数据获取的方法第六个可选实施例中，在第一预置时间内获取主交互式应用的数据，可以包括：

在第一数据获取时刻接收主交互式应用的数据，其中，第一数据获取时刻在第一预置时间内；

在第一预置时间内获取主交互式应用的数据之后，还可以包括：

根据第一数据获取时刻确定第二数据获取时刻；

若第二数据获取时刻在第一预置时间内，则获取第二数据获取时刻对应的主交互式应用的数据。

本实施例中，服务器在第一数据获取时刻接收主交互式应用的数据，其中，第一数据获取时刻在第一预置时间内，根据第一数据获取时刻确定第二数据获取时刻，这是因为第一数据获取时刻与第二数据获取时刻之间的时间是大于一个固定值的，通常情况下，可以将主交互式应用的数据获取时间设置为15秒以上，也就是说若第一数据获取时刻为11点32分10秒，则第二数据获取时刻需在11点32分25秒以后的某个时刻。进而，由服务器判断第二数据获取时刻是否在第一预置时间内，如果是，则继续获取第二数据获取时刻对应的主交互式应用的数据。

需要说明的是，这里描述的“第一”和“第二”仅仅为一个时序上的示意，在实际应用中，还可能出现更多的时刻，服务器需要判断每个获取数据的时刻是否在第一预置时间内，以防止关闭主交互式应用不及时导致用户持续进行无意义的操作的情况。

具体地，以A应用为例进行介绍，请参阅图7，图7为本发明实施例中交互式应用主题关盘的时序示意图，如图所示，ao_gs_topic为核心服务中的下单AO服务和主题AO服务，可以统称为AO服务，dao_gs_topic为核心服务中的订单DAO服务和主题DAO服务，可以统称DAO服务，系统则为上述实施例中提到的平台系统，下面将对各个步骤进行介绍：

步骤501：系统在一段时间内扫描主交互式应用和/或辅交互式应用的主题，扫描成功后，由DAO服务向系统反馈一个结果，使系统知道已扫描成功；

步骤502：系统扫描到主交互式应用和/或辅交互式应用的主题后，都会依次遍历缓存中的主题，以实时得到各主题的状态信息，如果得到当前主交互式应用的状态信息为关闭状态时，则请求将主交互式应用的状态信息更改为竞猜截至状态，辅交互式应用的状态信息也更改为竞猜截至状态；

步骤503：进而由AO服务进行参数校验，以确定获取的数据是否是有效的数据，也就是判断该数据是否在截至时间之前获取的；

步骤504：AO服务向DAO服务请求获取主交互式应用的主题以及辅交互式应用的主题，通过返回结果的方式可以得知两者的竞猜内容；

步骤505：由AO服务校验主交互式应用的主题以及辅交互式应用的主题对应的状态信息是为竞猜状态，还是为竞猜截至状态；

步骤506：如果处于竞猜状态，则AO服务需要将该竞猜状态更改为竞猜截至状态，并由DAO服务返回相应的结果，以得知以状态已更改成功。

其次，本发明实施例中，服务器先在第一数据获取时刻接收主交互式应用的数据，其中，第一数据获取时刻在第一预置时间内，进而服务器根据第一数据获取时刻确定第二数据获取时刻，若第二数据获取时刻在第一预置时间内，则获取第二数据获取时刻对应的主交互式应用的数据。采用上述方式可以有效地防止用户在超过第一预置时间时仍对主交互式应用进行操作的情况，在接收用户发送的数据时会根据截至时间进行校验，节省了发送数据所占用的资源以及减少用户设备的功耗，从而提升方案的实用性。

可选地，在上述图3对应的第五个实施例的基础上，本发明实施例提供应用数据获取的方法第七个可选实施例中，获取第二预置时间内辅交互式应用的数据，可以包括：

在第三数据获取时刻接收主交互式应用的数据，其中，第三数据获取时刻在第二预置时间内；

获取第二预置时间内所述辅交互式应用的数据之后，还可以包括：

根据第三数据获取时刻确定第四数据获取时刻；

若第四数据获取时刻在第二预置时间内，则获取第四数据获取时刻对应的主交互式应用的数据。

本实施例中，服务器在第三数据获取时刻接收主交互式应用的数据，其中，第三数据获取时刻在第二预置时间内，根据第三数据获取时刻确定第四数据获取时刻，这是由于第三数据获取时刻与第四数据获取之间的时间也是大于某个固定值的，通信情况下，可以将辅交互式应用的数据获取时间设置为2秒以上，也就是说若第三数据获取时刻为11点33分18秒，则第四数据获取时刻需要在11点33分20秒以后的某个时刻，进而，由服务器判断第四数据获取时刻是否在第二预置时间内，如果是，则继续获取第四数据获取时刻对应的辅交互式应用的数据。

需要说明的是，这里描述的“第三”和“第四”仅仅为一个时序上的示意，在实际应用中，还可能出现更多的时刻，服务器需要判断每个获取数据的时刻是否在第二预置时间内，以防止关闭辅交互式应用不及时导致用户持续进行无意义的操作的情况。

具体实现过程与上述图7描述的实施例类似，故此处不作赘述。

再次，本发明实施例中，服务器在第三数据获取时刻接收辅交互式应用的数据，其中，第三数据获取时刻在第二预置时间内，进而服务器根据第三数据获取时刻确定第四数据获取时刻，若第四数据获取时刻在第二预置时间内，则获取第四数据获取时刻对应的辅交互式应用的数据。采用上述方式可以有效地防止用户在超过第二预置时间时仍对辅交互式应用进行操作的情况，在接收用户发送的数据时会根据截至时间进行校验，节省了发送数据所占用的资源以及减少用户设备的功耗，从而提升方案的实用性。

可选地，在上述图3对应的实施例的基础上，本发明实施例提供应用数据获取的方法第八个可选实施例中，将辅交互式应用的数据发送至用于展示数据的用户设备之后，还可以包括：

获取目标数据；

将主交互式应用的数据与目标数据进行比对，并得到第一比对结果；

将辅交互式应用的数据与目标数据进行比对，并得到第二比对结果。

本实施例中，在服务器将辅交互式应用的数据发送至用于展示数据的用户设备之后，可以进行开奖的操作。先获取目标数据，即当前的指数，再将该目标数据与主交互式应用的数据进行对比，得到第一比对结果，第一比对结果可以是“正确”，或者“错误”，然后服务器将目标数据与辅交互式应用的数据进行比对，并得到第二比对结果，当然，第二比对结果也可以是“正确”或者“错误”。

需要说明的是，通常为先对主交互式应用的数据进行比对处理，再对辅交互式应用的数据进行比对处理，但是在实际应用中，也可以是同时对主交互式应用的数据以及辅交互式应用的数据进行比对处理，还可以是根据预设间隔时间对两者进行比对处理，此处不作限定。

具体地，以A应用为例进行介绍，请参阅图8，图8为本发明实施例中辅交互式应用开奖的时序示意图，如图所示，ao_gs_topic为核心服务中的下单AO服务和主题AO服务，可以统称为AO服务，dao_gs_topic为核心服务中的订单DAO服务和主题DAO服务，可以统称DAO服务，系统则为上述实施例中提到的平台系统，下面将对各个步骤进行介绍：

步骤601：系统在一段时间内扫描主交互式应用和/或辅交互式应用的主题，扫描成功后，由DAO服务向系统反馈一个结果，使系统知道已扫描成功；

步骤602：系统进而校验是否到开奖时间，其中，校验开奖时间的步骤是循环进行的，即每次扫描到主交互式应用和/或辅交互式应用的主题后，都会依次遍历缓存中的主题，并检测是否一轮操作已结束，可进行结果揭晓；

步骤603：如果开奖时间已到，则系统通过DAO服务获取主交互式应用和/或辅交互式应用的主题信息，并由DAO服务反馈结果给系统，该主题信息具体可以是，例如竞猜指数尾数的单双，或者是竞猜指数尾数的范围等主题，辅交互式应用会反馈自身的主题信息给系统，以使系统得知相应内容；

步骤604：系统先判断主交互式应用的主题对应的开奖结果，相似地，主交互式应用的主题具体可以是竞猜指数涨跌，判断的方式可以是对主交互式应用的数据与目标数据做比对，比对一致，则得到奖励；

步骤605：当系统已经完成对主交互式应用的开奖后，根据主交互式应用开奖的目标数据与辅交互式应用的数据进行比对，由DAO服务向系统反馈比对结果，从而使得系统得到主交互式应用和/或辅交互式应用的开奖结果。

其次，本发明实施例中，服务器将辅交互式应用的数据发送至用于展示数据的用户设备之后，还可以进一步进行开奖处理，先获取目标数据，再将主交互式应用的数据与目标数据进行比对，并得到第一比对结果，最后将辅交互式应用的数据与目标数据进行比对，并得到第二比对结果。为了保证开奖的一致性，可以采用辅交互式应用的数的比对在主交互式应用的数据比对结束后进行，不再另行调用数据服务器获取数据，防止数据服务器异常造成主交互式应用与主交互式应用的开奖结果不一致，导致方案的信誉度降低。因此，本方案有利于提升用户的信任度和可靠性。

为便于理解，下面以一个具体应用场景对本发明中一种应用数据获取的方法进行详细描述，具体为：

用户甲在上班的路上使用微信“钱包”中的竞猜类业务打发时间，当他在竞猜类业务的娱乐大厅中发现一款B应用时非常有兴趣，于是开启了B应用。

首先，用户甲在点击进入B应用后选择了实时竞猜，且竞猜时间为3分钟。在B应用的主页中显示了当前时间为9点30分，此时此刻的指数为3082.42，这时，一轮竞猜游戏已经正式开始。

接着，用户甲需要进行投注，投注内容为在9点33分的时候，相对于3082.42是涨还是跌，投注金额是虚拟金币，用户甲在9点31分15秒的时候选择了指数为涨，在赔率为2的时候投注1000虚拟金币。此后，每隔15秒都可以进行一次投注，投注内容均为竞猜指数涨跌，相应地，赔率也将随着时间推移而增加，因为越接近开奖时间越容易进行预测。竞猜指数涨跌在9点32分30秒时截至，即不能再进行竞猜。

然而，在竞猜指数涨跌这个项目开始时，也触发了一个辅游戏的启动，该辅游戏为竞猜指数尾数的单双数，当用户甲第一次竞猜完指数涨跌时，在B应用的页面上就会弹出一个竞猜指数尾数单双数的页面，用户甲如果有兴趣玩这项游戏，即可直接在该页面上投注在9点33分时的指数尾数为单数还是双数，赔率也为2，且赔率也随着时间推移而增加。每间隔2秒皆可以竞猜一次指数尾数的单双数，竞猜指数尾数单双数在9点33分时截至，即不能再竞猜。用户甲在9点32分48秒的时候选择了指数尾数为双数，在赔率为4的时候投注1000虚拟金币。

最后，在9点33分之前完成了投注，并得到了开奖结果为3086.51，此时服务器核对用户甲的投注结果，在竞猜指数涨跌时，答案正确，得到虚拟金币2000，而不幸运的是，在竞猜指数尾数单双数时，则出现了失误，又损失了虚拟金币4000，最后用户甲的虚拟金币总数减少2000。至此，完成了一轮B类应用的竞猜。

下面对本发明中的服务器进行详细描述，请参阅图9，本发明实施例中的服务器70包括：

第一获取模块701，用于在第一预置时间内获取主交互式应用的数据，其中，所述主交互式应用的数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；

第二获取模块702，用于若根据所述第一获取模块701获取的所述关联主题号确定开启辅交互式应用，则获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；

展示模块703，用于将所述第二获取模块702获取的所述辅交互式应用的数据发送至用于展示数据的用户设备。

本实施例中，第一获取模块701在第一预置时间内获取主交互式应用的数据，其中，所述主交互式应用的数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻，若根据所述第一获取模块701获取的所述关联主题号确定开启辅交互式应用，则第二获取模块702获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻，展示模块703将所述第二获取模块702获取的所述辅交互式应用的数据发送至用于展示数据的用户设备。

本发明实施例中，提供了一种应用数据获取的方法，首先服务器在第一预置时间内获取主交互式应用的数据，其中，主交互式应用的数据中携带关联主题号，第一预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为所述主交互式应用的关闭时刻，接着服务器可以在确定开启辅交互式应用后，获取第二预置时间内辅交互式应用的数据，第二预置时间包含第一预置时间，第二预置时间的起始时刻为主交互式应用的开启时刻，结束时刻为辅交互式应用的结束时刻，将辅交互式应用的数据发送至用于展示数据的用户设备。由此，可以在“空白”时间内对用户设备中的辅交互式应用进行操作，从而使用户设备在这段时间里有效地利用了电量和网络资源，并根据相应的操作进行辅交互式应用的进程，提升了用户设备的使用效率，有利于用户设备的良好运行。

可选地，在上述图9所对应的实施例的基础上，请参阅图10，本发明实施例提供的服务器的另一实施例中，所述主交互式应用的数据包括实时数据和/或虚拟数据；

所述第一获取模块701包括：

检测单元7011，用于检测所述第一预置时间是否为预设处理时间；

第一确定单元7012，用于若所述检测单元7011检测所述第一预置时间为预设处理时间，则确定所述主交互式应用的数据为实时数据或虚拟数据；

第二确定单元7013，用于若所述检测单元7011检测所述第一预置时间不为预设处理时间，则确定所述主交互式应用的数据为虚拟数据。

其次，本发明实施例中，主交互式应用以及辅交互式应用都可以针对不同的数据进行处理，服务器既可以获取当前变化的实时数据，也可以获取随机性强的虚拟数据。然而实时数据通常会显示在一条动态变化的曲线上，用户能够根据曲线的变化趋势来判断后续可能会出现的数据，使得方案更具有实时性和趣味性，提升用户的使用体验。虚拟数据是在当前无法使用实时数据或者不想使用实时数据时，提供给用户进行处理的数据，由此，为方案提供了多种实现方式，从而加强方案的灵活性。

可选地，在上述图9所对应的实施例的基础上，请参阅图11，本发明实施例提供的服务器的另一实施例中，所述服务器70还包括：

查询模块704A，用于所述第二获取模块702获取第二预置时间内所述辅交互式应用的数据之前，根据所述主交互式应用的关联主题号，查询与所述主交互式应用的关联主题号一致的所述辅交互式应用；

第一确定模块704B，用于若所述查询模块704A查询得到所述辅交互式应用的关联主题号与所述主交互式应用的关联主题号一致，则确定所述辅交互式应用已开启。

其次，本发明实施例中，提供了一种可以通过关联主题号确定与主交互式应用一致的辅交互式应用，并且检测出辅交互式应用是否已经开启了，如果开启，则获取辅交互式应用的数据。采用关联主题号关联主交互式应用与辅交互式应用，保证两者的开奖结果一致，从而保证方案的一致性，从而使得采用该方案的产品有更好的信誉以及口碑。

可选地，在上述图11所对应的实施例的基础上，请参阅图12，本发明实施例提供的服务器的另一实施例中，所述服务器70还包括：

第三获取模块705A，用于所述第二获取模块702获取第二预置时间内所述辅交互式应用的数据之前，根据所述主交互式应用的关联主题号，获取所述主交互式应用的状态信息，其中，所述主交互式应用的状态信息用于指示所述主交互式应用是否处于开启状态；

第一更新模块705B，用于当根据所述第三获取模块706获取的所述主交互式应用的状态信息确定所述主交互式应用处于开启状态时，则更新所述辅交互式应用的状态信息。

其次，本发明实施例中，服务器根据主交互式应用的关联主题号，获取主交互式应用的状态信息，其中，主交互式应用的状态信息用于指示主交互式应用是否处于开启状态，当根据主交互式应用的状态信息确定主交互式应用处于开启状态时，则更新辅交互式应用的状态信息。在主交互式应用未开启时，辅交互式应用也开启，但是在主交互式应用开启时，辅交互式应用开启失败时，主交互式应用仍可以进行，由此，不但可以保证主交互式应用和辅交互式应用的一致性，还可以使辅交互式应用称为主交互式应用的辅助功能，并不会出现本末倒置的情况，仍以主交互式应用为主进行操作，从而增强方案的实用性和可行性。

可选地，在上述图12所对应的实施例的基础上，请参阅图13，本发明实施例提供的服务器的另一实施例中，所述服务器70还包括：

第二更新模块706A，用于当所述主交互式应用的数据出现数据异常时，则更新所述主交互式应用的状态信息；

第一撤回模块706B，用于根据所述第二更新模块706A更新后的所述主交互式应用的状态信息，将所述主交互式应用的数据进行撤回处理；

第二撤回模块706C，用于在所述第一撤回模块706B将所述主交互式应用的数据进行撤回处理之后，对所述辅交互式应用的数据进行撤回处理。

再次，本发明实施例中，还进一步提供了一种针对主题撤单的方案当主交互式应用的数据出现数据异常时，则服务器先更新主交互式应用的状态信息，再根据更新后的主交互式应用的状态信息，将主交互式应用的数据进行撤回处理，然后对辅交互式应用的数据进行撤回处理。采用上述方式完成主题撤单，可以防止由于数据持续异常，造成收益数据不可控的现象。通过主题撤单的方式不仅能保证平台不亏损，而且也不会损害用户的利益，数据异常时，辅交互式应用会根据主交互式应用的撤单同步进行撤单处理，达到两者的一致性，从而提升方案的实用性。

可选地，在上述图9所对应的实施例的基础上，请参阅图14，本发明实施例提供的服务器的另一实施例中，所述服务器70还包括：

停止模块707，用于若在所述第一预置时间内未获取所述主交互式应用的数据，则停止开启所述辅交互式应用。

进一步地，本发明实施例中，如果在第一预置时间内一直没有获取到主交互式应用的数据，则也将停止对辅交互应用数据的获取。采用上述机制，不但可以到达主交互式应用与辅交互式应用的同步，还可以节省网络资源，不会在主交互式应用数据获取失败的情况下，还持续获取辅交互式应用的数据，导致得到的辅交互式应用数据不能作为有效数据的情况。由此提升方案的可行性和可操作性。

可选地，在上述图9所对应的实施例的基础上，请参阅图15，本发明实施例提供的服务器的另一实施例中，

所述第一获取模块701包括：

第一接收单元7014，用于在第一数据获取时刻接收所述主交互式应用的数据，其中，所述第一数据获取时刻在所述第一预置时间内；

所述服务器70还包括：

第二确定模块708A，用于所述第一获取模块701在第一预置时间内获取主交互式应用的数据之后，根据所述第一数据获取时刻确定第二数据获取时刻；

第四获取模块708B，用于若所述第二确定模块708A确定的所述第二数据获取时刻在所述第一预置时间内，则获取所述第二数据获取时刻对应的所述主交互式应用的数据。

其次，本发明实施例中，服务器先在第一数据获取时刻接收主交互式应用的数据，其中，第一数据获取时刻在第一预置时间内，进而服务器根据第一数据获取时刻确定第二数据获取时刻，若第二数据获取时刻在第一预置时间内，则获取第二数据获取时刻对应的主交互式应用的数据。采用上述方式可以有效地防止用户在超过第一预置时间时仍对主交互式应用进行操作的情况，在接收用户发送的数据时会根据截至时间进行校验，节省了发送数据所占用的资源以及减少用户设备的功耗，从而提升方案的实用性。

可选地，在上述图9所对应的实施例的基础上，请参阅图16，本发明实施例提供的服务器的另一实施例中，

所述第二获取模块702包括：

第二接收单元7021，用于在第三数据获取时刻接收所述辅交互式应用的数据，其中，所述第三数据获取时刻在所述第二预置时间内；

所述服务器70还包括：

第三确定模块709A，用于所述第二获取模块702获取第二预置时间内所述辅交互式应用的数据之后，根据所述第三数据获取时刻确定第四数据获取时刻；

第五获取模块709B，用于若所述第三确定模块709A确定所述第四数据获取时刻在所述第二预置时间内，则获取所述第四数据获取时刻对应的所述主交互式应用的数据。

再次，本发明实施例中，服务器在第三数据获取时刻接收主交互式应用的数据，其中，第三数据获取时刻在第二预置时间内，进而服务器根据第三数据获取时刻确定第四数据获取时刻，若第四数据获取时刻在第二预置时间内，则获取第四数据获取时刻对应的主交互式应用的数据。采用上述方式可以有效地防止用户在超过第二预置时间时仍对辅交互式应用进行操作的情况，在接收用户发送的数据时会根据截至时间进行校验，节省了发送数据所占用的资源以及减少用户设备的功耗，从而提升方案的实用性。

可选地，在上述图9所对应的实施例的基础上，请参阅图17，本发明实施例提供的服务器的另一实施例中，所述服务器70还包括：

第六获取模块709C，用于所述展示模块703将所述辅交互式应用的数据发送至用于展示数据的用户设备之后，获取目标数据；

第一比对模块709D，用于将所述主交互式应用的数据与所述第六获取模块709C获取的所述目标数据进行比对，并得到第一比对结果；

第二比对模块709E，用于将所述辅交互式应用的数据与所述第六获取模块709C获取的所述目标数据进行比对，并得到第二比对结果。

其次，本发明实施例中，服务器将辅交互式应用的数据发送至用于展示数据的用户设备之后，还可以进一步进行开奖处理，先获取目标数据，再将主交互式应用的数据与目标数据进行比对，并得到第一比对结果，最后将主交互式应用的数据与目标数据进行比对，并得到第二比对结果。为了保证开奖的一致性，可以采用辅交互式应用的数的比对在主交互式应用的数据比对结束后进行，不再另行调用数据服务器获取数据，防止数据服务器异常造成主交互式应用与主交互式应用的开奖结果不一致，导致方案的信誉度降低。因此，本方案有利于提升用户的信任度和可靠性。

图18是本发明实施例提供的一种服务器结构示意图，该服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(英文全称：centralprocessing units，英文缩写：CPU)822(例如，一个或一个以上处理器)和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在服务器800上执行存储介质830中的一系列指令操作。

服务器800还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作系统841，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由服务器所执行的步骤可以基于该图18所示的服务器结构。

所述中央处理器822用于，

控制所述输入装置858在第一预置时间内获取主交互式应用的数据，其中，所述数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；

若根据所述关联主题号确定开启辅交互式应用，则控制所述输入装置获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；

将所述辅交互式应用的数据发送至用于展示数据的用户设备。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种应用数据获取的方法，其特征在于，包括：

在第一预置时间内获取主交互式应用的数据，其中，所述主交互式应用的数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；用户能够在所述第一预置时间内对所述主交互式应用进行操作；

根据所述主交互式应用的关联主题号，查询与所述主交互式应用的关联主题号一致的辅交互式应用；所述辅交互式应用的关联主题号在所述主交互式应用的关联主题号生成之后生成；

若查询到与所述主交互式应用的关联主题号一致的辅交互式应用，确定所述辅交互式应用已开启，则获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；用户能够在所述第二预置时间内对所述辅交互式应用进行操作；

将所述辅交互式应用的数据发送至用于展示数据的用户设备；

所述主交互式应用响应于用户操作而输出结果的时刻与所述辅交互式应用响应于用户操作而输出结果的时刻相同。

2.根据权利要求1所述的方法，其特征在于，所述获取第二预置时间内所述辅交互式应用的数据之前，所述方法还包括：

根据所述主交互式应用的关联主题号，获取所述主交互式应用的状态信息，其中，所述主交互式应用的状态信息用于指示所述主交互式应用是否处于开启状态；

当根据所述主交互式应用的状态信息确定所述主交互式应用处于开启状态时，则更新所述辅交互式应用的状态信息。

3.根据权利要求1所述的方法，其特征在于，所述在第一预置时间内获取主交互式应用的数据，包括：

在第一数据获取时刻接收所述主交互式应用的数据，其中，所述第一数据获取时刻在所述第一预置时间内；

所述在第一预置时间内获取主交互式应用的数据之后，所述方法还包括：

根据所述第一数据获取时刻确定第二数据获取时刻；

若所述第二数据获取时刻在所述第一预置时间内，则获取所述第二数据获取时刻对应的所述主交互式应用的数据。

4.根据权利要求3所述的方法，其特征在于，所述获取第二预置时间内所述辅交互式应用的数据，包括：

在第三数据获取时刻接收所述辅交互式应用的数据，其中，所述第三数据获取时刻在所述第二预置时间内；

所述获取第二预置时间内所述辅交互式应用的数据之后，所述方法还包括：

根据所述第三数据获取时刻确定第四数据获取时刻；

若所述第四数据获取时刻在所述第二预置时间内，则获取所述第四数据获取时刻对应的所述主交互式应用的数据。

5.一种服务器，其特征在于，包括：

第一获取模块，用于在第一预置时间内获取主交互式应用的数据，其中，所述主交互式应用的数据中携带关联主题号，所述第一预置时间的起始时刻为所述主交互式应用的开启时刻，所述第一预置时间的结束时刻为所述主交互式应用的关闭时刻；用户能够在所述第一预置时间内对所述主交互式应用进行操作；

查询模块，用于根据所述主交互式应用的关联主题号，查询与所述主交互式应用的关联主题号一致的辅交互式应用；所述辅交互式应用的关联主题号在所述主交互式应用的关联主题号生成之后生成；

第一确定模块，用于若所述查询模块查询得到与所述主交互式应用的关联主题号一致的辅交互式应用，则确定所述辅交互式应用已开启；

第二获取模块，用于若所述辅交互式应用已开启，则获取第二预置时间内所述辅交互式应用的数据，其中，所述第二预置时间包含所述第一预置时间，所述第二预置时间的起始时刻为所述主交互式应用的开启时刻，所述第二预置时间的结束时刻为所述辅交互式应用的结束时刻；用户能够在所述第二预置时间内对所述辅交互式应用进行操作；

展示模块，用于将所述第二获取模块获取的所述辅交互式应用的数据发送至用于展示数据的用户设备；

所述主交互式应用响应于用户操作而输出结果的时刻与所述辅交互式应用响应于用户操作而输出结果的时刻相同。

6.根据权利要求5所述的服务器，其特征在于，所述服务器还包括：

第三获取模块，用于所述第二获取模块获取第二预置时间内所述辅交互式应用的数据之前，根据所述主交互式应用的关联主题号，获取所述主交互式应用的状态信息，其中，所述主交互式应用的状态信息用于指示所述主交互式应用是否处于开启状态；

第一更新模块，用于当根据所述第三获取模块获取的所述主交互式应用的状态信息确定所述主交互式应用处于开启状态时，则更新所述辅交互式应用的状态信息。

7.根据权利要求5所述的服务器，其特征在于，所述第一获取模块包括：

第一接收单元，用于在第一数据获取时刻接收所述主交互式应用的数据，其中，所述第一数据获取时刻在所述第一预置时间内；

所述服务器还包括：

第二确定模块，用于所述第一获取模块在第一预置时间内获取主交互式应用的数据之后，根据所述第一数据获取时刻确定第二数据获取时刻；

第四获取模块，用于若所述第二确定模块确定的所述第二数据获取时刻在所述第一预置时间内，则获取所述第二数据获取时刻对应的所述主交互式应用的数据。

8.根据权利要求7所述的服务器，其特征在于，所述第二获取模块包括：

第二接收单元，用于在第三数据获取时刻接收所述辅交互式应用的数据，其中，所述第三数据获取时刻在所述第二预置时间内；

所述服务器还包括：

第三确定模块，用于所述第二获取模块获取第二预置时间内所述辅交互式应用的数据之后，根据所述第三数据获取时刻确定第四数据获取时刻；

第五获取模块，用于若所述第三确定模块确定所述第四数据获取时刻在所述第二预置时间内，则获取所述第四数据获取时刻对应的所述主交互式应用的数据。

9.一种服务器，其特征在于，包括处理器和存储器；

所述存储器用于存储程序；

所述处理器用于执行所述存储器存储的程序，实现如权利要求1-4中任一项所述的应用数据获取的方法的各个步骤。

10.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如权利要求1-4中任一项所述的应用数据获取的方法的各个步骤。

Images