CN111738468A - 数据处理方法、数据处理装置、计算机系统和介质 - Google Patents

Abstract

本公开提供了一种数据处理方法、数据处理装置、计算机系统和介质，其中，所述数据处理方法包括：获取针对至少一个对象的请求信息，所述请求信息包括对于所述至少一个对象的请求数量；至少基于历史信息获取所述至少一个对象在指定时刻的预计可供数量；基于所述请求数量和所述至少一个对象在指定时刻的预计可供数量，确定所述至少一个对象的请求成功率；基于所述至少一个对象的请求成功率确定所述至少一个对象的请求顺序。

Description

数据处理方法、数据处理装置、计算机系统和介质

技术领域

本公开涉及计算机技术领域，更具体地，涉及一种数据处理方法、 数据处理装置、计算机系统和介质。

背景技术

随着人们对丰富的娱乐活动和旅游的需求越来越高，紧俏景点的 车票、门票，明星的演出票等资源变成稀缺资源，尤其在旅游旺季及 人气明星出演时，人们为了获取这些稀缺资源，通常需要通宵排队。 此外，也有用户通过刷票应用来购票。

在实现本公开构思的过程中，发明人发现现有技术中至少存在如 下问题：在余票紧张的情况下，用户经常买不到票，用户体验差。

发明内容

有鉴于此，本公开提供了一种用于提升对象请求成功率的数据处 理方法、数据处理装置、计算机系统和介质。

本公开的一个方面提供了一种数据处理方法，该方法包括，首先， 获取针对至少一个对象的请求信息，所述请求信息包括对于所述至少 一个对象的请求数量，然后，至少基于历史信息获取所述至少一个对 象在指定时刻的预计可供数量，接着，基于所述请求数量和所述至少 一个对象在指定时刻的预计可供数量，确定所述至少一个对象的请求 成功率，然后，基于所述至少一个对象的请求成功率确定所述至少一 个对象的请求顺序。

根据本公开的实施例，由于基于对象的请求成功率确定所述至少 一个对象的请求顺序，可以至少部分提升所述至少一个对象的请求成 功率，且可以使得计算资源的有效转化率更高，在降低能耗的同时提 升用户体验。

根据本公开的实施例，所述至少基于历史信息获取所述至少一个 对象在指定时刻的预计可供数量可以包括如下操作：首先，获取多个 历史年份中所述至少一个对象在指定时刻的提供数量，然后，至少基 于所述多个历史年份中所述至少一个对象在指定时刻的提供数量获 取所述至少一个对象在当前年份中指定时刻的预计可供数量。这样基 于历史年份中相同或相关时刻的对象提供数量来预测对象的当前可 供数量，能有效提升预测的准确率。

根据本公开的实施例，所述方法还可以包括如下操作，在获取多 个历史年份中所述至少一个对象在指定时刻的提供数量之后，获取影 响所述至少一个对象的请求成功率的影响因素的预计值，所述影响因 素包括天气因素。相应地，所述至少基于述多个历史年份中所述至少 一个对象在指定时刻的提供数量获取所述至少一个对象在当前年份 中指定时刻的预计可供数量包括：基于所述影响因素的预计值和所述 多个历史年份中所述至少一个对象在指定时刻的提供数量获取所述 至少一个对象在当前年份中指定时刻的预计可供数量。这样还进一步 考虑了如天气等影响因素等对请求成功率的影响，通过调用相关影响 因素的数据可以进一步提升对象的可供数量的预测准确度。

根据本公开的实施例，所述方法还可以包括如下操作，在获取至 少一个对象的请求信息之后，对所述至少一个对象的请求信息中相同 的请求信息进行合并，得到针对至少一个合并对象的请求信息，其中， 所述针对至少一个合并对象的请求信息包括针对所述至少一个合并 对象的请求数量。相应地，所述基于所述请求数量和所述至少一个对 象在指定时刻的预计可供数量确定所述至少一个对象的请求成功率 包括：基于所述至少一个合并对象的请求数量和所述至少一个合并对 象在指定时刻的预计可供数量确定所述至少一个合并对象的请求成 功率，以及，所述基于所述至少一个对象的请求成功率确定所述至少一个对象的请求顺序包括：基于所述至少一个合并对象的请求成功率 确定所述至少一个合并对象的请求顺序。由于对象的提供平台(如服 务器)提供的接口通常存在接口操作次数限制，通过将具有相同的请 求信息的对象进行合并，可以有效减少对接口的操作次数，充分利用 接口所提供的资源，同时，还可以有效提升计算资源的利用率。

根据本公开的实施例，所述基于所述至少一个对象的请求成功率 确定所述至少一个对象的请求顺序可以包括如下操作，首先，基于所 述至少一个对象的请求成功率确定所述至少一个对象的查询顺序，然 后，基于所述至少一个对象的查询顺序对所述至少一个对象进行查询， 得到所述至少一个对象的实际可供数量，接着，如果所述至少一个对 象中某个对象的实际可供数量不为零，则给所述某个对象的用户反馈 所述某个对象的实际可供数量信息。在确认请求成功率后，先进行查 询，如果查询结果不为空，则反馈查询信息，有助于使得请求对象的 用户清楚得知对象的当前状态，便于用户根据当前状态确定是否购买 或该对象。

根据本公开的实施例，所述如果所述至少一个对象中某个对象的 实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的 实际可供数量信息可以包括如下操作，首先，如果所述至少一个对象 中某个对象的实际可供数量与对应的请求数量满足预设条件，则发送 权属迁移请求以获取所述至少一个对象中某个对象的至少一个权属， 其中，所述预设条件表征所述至少一个对象的获取成功率小于等于预 设阈值，然后，获取所述至少一个对象中某个对象的用户的贡献属性， 所述用户的贡献属性表征所述用户对推广所述对象的请求系统的贡 献，接着，基于所述用户的贡献属性对所述至少一个对象中某个对象 的用户进行排序，得到用户排序，然后，基于所述用户排序给所述某 个对象的用户反馈所述某个对象的实际可供数量信息。这样当所述对 象的请求数量超过所述对象的可提供数量时，可以先获取对象的权属， 然后，根据用户对推广对象的请求平台的贡献值，给用户分配所述对 象，这样可以在帮助用户尽可能的获取对象的同时，推广所述对象的 请求平台。

根据本公开的实施例，所述基于所述用户的贡献属性对所述至少 一个对象中某个对象的用户进行排序，得到用户排序可以包括如下操 作：基于所述用户的贡献属性和所述至少一个对象中某个对象的请求 信息的生成时间对所述至少一个对象中某个对象的用户进行排序，得 到用户排序。这样可以实现当针对相同对象的多个请求的用户的贡献 值相同时，按照用户的发起请求的时间顺序对所述对象进行分配，有 助于提升公平度，提升用户体验。

根据本公开的实施例，所述方法还可以包括如下操作，在给所述 某个对象的用户反馈所述某个对象的实际可供数量信息之后，获取所 述某个对象的用户针对所述某个对象的权属迁移操作，然后，响应于 所述权属迁移操作，执行权属迁移请求。这样可以根据用户针对对象 的请求操作对所述对象进行交易，保证用户的财产安全。

根据本公开的实施例，所述如果所述至少一个对象中某个对象的 实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的 实际可供数量信息可以包括如下操作，如果所述至少一个对象中某个 对象的实际可供数量与对应的请求数量不满足预设条件，则给所述某 个对象的用户反馈所述某个对象的实际可供数量信息，然后，获取所 述某个对象的用户针对所述某个对象的权属迁移操作，以及，响应于 所述权属迁移操作，发送权属迁移请求。这样可以在用户请求的对象 的数量有限时，及时给所述用户反馈对象的实际可供数量，帮助用户 确定是否立即获取所述对象的权属，避免错失获取对象的机会。

本公开的另一个方面提供了一种数据处理装置，包括请求获取模 块、预计数量获取模块、成功率确定模块和请求顺序获取模块。其中， 所述请求获取模块用于获取针对至少一个对象的请求信息，所述请求 信息包括对于所述至少一个对象的请求数量，所述预计数量获取模块 用于至少基于历史信息获取所述至少一个对象在指定时刻的预计可 供数量，所述成功率确定模块用于基于所述请求数量和所述至少一个 对象在指定时刻的预计可供数量，确定所述至少一个对象的请求成功 率，所述请求顺序获取模块用于基于所述至少一个对象的请求成功率 确定所述至少一个对象的请求顺序。

根据本公开的实施例，所述预计数量获取模块可以包括历史数据 获取子模块和预计数量获取子模块。其中，所述历史数据获取子模块 用于获取多个历史年份中所述至少一个对象在指定时刻的提供数量， 所述预计数量获取子模块用于至少基于所述多个历史年份中所述至 少一个对象在指定时刻的提供数量获取所述至少一个对象在当前年 份中指定时刻的预计可供数量。

根据本公开的实施例，所述装置还可以包括影响因素获取模块， 所述影响因素获取模块用于在获取多个历史年份中所述至少一个对 象在指定时刻的提供数量之后，获取影响所述至少一个对象的请求成 功率的影响因素的预计值，所述影响因素包括天气因素。相应地，所 述预计数量获取模块具体用于基于所述影响因素的预计值和所述多 个历史年份中所述至少一个对象在指定时刻的提供数量获取所述至 少一个对象在当前年份中指定时刻的预计可供数量。

根据本公开的实施例，所述装置还可以包括合并模块，所述合并 模块用于在获取至少一个对象的请求信息之后，对所述至少一个对象 的请求信息中相同的请求信息进行合并，得到针对至少一个合并对象 的请求信息，其中，所述针对至少一个合并对象的请求信息包括所述 至少一个合并对象的请求数量。相应地，所述成功率确定模块具体用 于基于所述至少一个合并对象的请求数量和所述至少一个合并对象 在指定时刻的预计可供数量确定所述至少一个合并对象的请求成功 率，所述请求顺序获取模块具体用于基于所述至少一个合并对象的请 求成功率确定所述至少一个合并对象的请求顺序。

根据本公开的实施例，所述请求顺序获取模块可以包括查询顺序 获取子模块、对象数量获取子模块和数量反馈子模块，其中，所述查 询顺序获取子模块用于基于所述至少一个对象的请求成功率确定所 述至少一个对象的查询顺序，所述对象数量获取子模块用于基于所述 至少一个对象的查询顺序对所述至少一个对象进行查询，得到所述至 少一个对象的实际可供数量，所述数量反馈子模块用于如果所述至少 一个对象中某个对象的实际可供数量不为零，则给所述某个对象的用 户反馈所述某个对象的实际可供数量信息。

根据本公开的实施例，所述数量反馈子模块可以包括权属获取单 元、贡献获取单元、用户排序单元和数量反馈单元，其中，所述权属 获取单元用于如果所述至少一个对象中某个对象的实际可供数量与 对应的请求数量满足预设条件，则发送权属迁移请求以获取所述至少 一个对象中某个对象的至少一个权属，其中，所述预设条件表征所述 至少一个对象的获取成功率小于等于预设阈值，所述贡献获取单元用 于获取所述至少一个对象中某个对象的用户的贡献属性，所述用户的 贡献属性表征所述用户对推广所述对象的请求系统的贡献，所述用户 排序单元用于基于所述用户的贡献属性对所述至少一个对象中某个 对象的用户进行排序，得到用户排序，所述数量反馈单元用于基于所 述用户排序给所述某个对象的用户反馈所述某个对象的实际可供数 量信息。

根据本公开的实施例，所述用户排序单元具体用于基于所述用户 的贡献属性和所述至少一个对象中某个对象的请求信息、的生成时间 对所述至少一个对象中某个对象的用户进行排序，得到用户排序。

根据本公开的实施例，所述装置还可以包括权属迁移操作获取模 块和响应模块，其中，所述权属迁移操作获取模块用于在给所述某个 对象的用户反馈所述某个对象的实际可供数量信息之后，获取所述某 个对象的用户针对所述某个对象的权属迁移操作，所述响应模块用于 响应于所述权属迁移操作，执行权属迁移请求。

根据本公开的实施例，所述数量反馈单元可以包括反馈子单元、 操作获取子单元和响应子单元，其中，所述反馈子单元用于如果所述 至少一个对象中某个对象的实际可供数量与对应的请求数量不满足 预设条件，则给所述某个对象的用户反馈所述某个对象的实际可供数 量信息，所述操作获取子单元用于获取所述某个对象的用户针对所述 某个对象的权属迁移操作，所述响应子单元用于响应于所述权属迁移 操作，发送权属迁移请求。

本公开的另一方面提供了一种计算机系统，包括一个或多个处理 器以及存储装置，其中，所述存储装置用于存储可执行指令，所述可 执行指令在被所述处理器执行时，实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算 机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括 计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其 他目的、特征和优点将更为清楚，在附图中：

图1A示意性示出了根据本公开实施例的数据处理方法、数据处 理装置、计算机系统和介质的应用场景；

图1B示意性示出了根据本公开实施例的适用于数据处理方法的 系统架构；

图2示意性示出了根据本公开实施例的数据处理方法的流程图；

图3A示意性示出了根据本公开实施例的预计可供数量的获取方 法的流程图；

图3B示意性示出了根据本公开实施例的对象的实际可供数量信 息的示意图；

图4A示意性示出了根据本公开实施例的数据处理装置的框图；

图4B示意性示出了根据本公开实施例的数据处理系统的逻辑图； 以及

图5示意性示出了根据本公开实施例的计算机系统的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些 描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述 中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全 面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情 况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术 的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本 公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、 操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特 征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人 员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解 释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于 刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下， 一般来说应该按照本领域技术人员通常理解该表述的含义来予以解 释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单 独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具 有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B 或C等中至少一个”这样的表述的情况下，一般来说应该按照本领 域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、 单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、 B、C的系统等)。

因节假日的人口大规模流动，印尼的火车票、汽车票等经常出现 供不应求的情况，导致用户购票难。此外，印尼为旅游国家，在旅游 旺季的时候，也会出现售票紧张的情况。除印尼旅行业务外，娱乐相 关业务的演出票，在面临火爆演出时，也是会出现一票难求的情况。

此外，印尼的票务系统在多个用户同时下单时，如果余票量不足， 则会出现部分用户占票失败，从而下单失败，此时，用户需要再次重 新手动刷票，待刷票成功后重新提交订单，这就导致在余票紧张的情 况，用户下单体验较差。

本公开的实施例提供了一种数据处理方法、数据处理装置、计算 机系统和介质。该数据处理方法包括成功率确认过程和请求排序过程。 在成功率确认过程中，至少基于历史信息获取至少一个对象在指定时 刻的预计可供数量，然后基于所述至少一个对象的请求数量以及预计 可供数量确定所述至少一个对象的请求成功率。在完成成功率确认过 程之后，进入请求排序过程，基于所述至少一个对象的请求成功率确 定所述至少一个对象的请求顺序。

图1A示意性示出了根据本公开实施例的数据处理方法、数据处 理装置、计算机系统和介质的应用场景。需要注意的是，图1A所示 仅为可以应用本公开实施例的应用场景的示例，以帮助本领域技术人 员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其 他设备、系统、环境或场景。

以用户利用XX购票应用请求从GMR到BD在2019/2/15日的 火车票为例进行说明。如图1A所示，用户在登录了XX购票应用之 后，输入出发地信息：GRM，目的地：BD和出发日期：2019/2/15， 然后，点击购票按钮，将请求信息发送给XX购票应用的服务器，由 服务器帮助用户进行购票。需要说明的是，用户发送的请求信息中还 可以包括购票的截止时间信息等。此外，用户可以通过服务器分配的 账号、用户标识、密码等登录XX购票应用，也就是说，每个用户具 有至少一个账户，该账户中可以存储有用户的相关信息，例如，历史 购票信息、平台推广的贡献相关信息等。

图1B示意性示出了根据本公开实施例的适用于数据处理方法的 系统架构。需要注意的是，图1B所示仅为可以应用本公开实施例的 应用场景的示例，不能理解为对本公开的限定。

如图1B所示，根据该实施例的系统架构100可以包括终端设备 101、102、103，网络104和服务器集群105和服务器集群106。网 络104用以在终端设备101、102、103、服务器集群105和服务器集 群106之间提供通信链路的介质。网络104可以包括各种连接类型， 例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器集 群105交互，服务器集群105通过网络104与服务器集群106交互， 以接收或发送消息等。其中，服务器集群106作为对象的提供平台， 并提供所述对象的查询接口和购买接口等，服务器集群105为用户提 供代理服务，例如，基于所述查询接口和购买接口为用户提供对象的 查询服务、购买服务等。终端设备101、102、103上可以安装有各种 通讯客户端应用，例如代理类应用、购物类应用、网页浏览器应用、 搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的 各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算 机、台式计算机、智能电视、增强现实设备和虚拟现实设备等等。

服务器集群105和服务器集群106可以包括提供各种服务的服务 器，例如对用户利用终端设备101、102、103所浏览的网站提供支持 的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用 户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获 取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的数据处理方法一般可以由 服务器集群105执行。相应地，本公开实施例所提供的数据处理装置 一般可以设置于服务器集群105中。本公开实施例所提供的数据处理 方法也可以由不同于服务器集群105且能够与终端设备101、102、 103和/或服务器集群105通信的服务器集群执行。

应该理解，终端设备、网络和服务器的数目仅仅是示意性的。根 据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2示意性示出了根据本公开实施例的数据处理方法的流程图。

如图2所示，该方法包括操作S201～操作S207。

在操作S201，获取针对至少一个对象的请求信息，所述请求信 息包括对于所述至少一个对象的请求数量。

在本实施例中，所述对象可以为各种权属证明类资源，例如，车 票、门票、购物券、入场券、代金券等存在购买困难的资源。该请求 信息包括查询请求、购买请求、交换请求等。

此外，所述请求信息还可以包括该请求的用户信息，例如，用户 标识、联系人信息、用户偏好、历史请求相关信息和平台贡献相关信 息等。

在一个具体实施例中，以所述对象为火车票为例进行说明，所述 请求信息可以如表1所示。

表1火车票请求信息

如图表1所示，用户xiaoming使用用户ID为jdxiaoming的账户 为自己购买的对象为：2018/8/19日从GMR到BD，车次为Argo 20 的Business类型A等级的火车票，其中，设定的购票截止时间为 2018/8/1816：00，为了便于平台代理买票和发送通知消息，用户xiaoming预留了自己的联系方式：姓名xiaoming、电话1880000000、 邮箱123@qq.com，以及乘客信息：性别男士、姓名xiaoming和证件 号码E123456。基于这些请求信息，使得服务器可以基于这些请求信 息代理xiaoming的查票和/或购票业务。

需要说明的是，服务器可以同时给多个用户提供服务，因此，可 能在一个时间段内收到多个对象的请求信息。

在操作S203，至少基于历史信息获取所述至少一个对象在指定 时刻的预计可供数量。

在本实施例中，由于对象的提供通常具有一定的规律，例如，某 个国家的某个地区的火车票通常在固定的时间段或多个满足一定条 件的时间段进行放票，因此，可以基于上述一定的规律来预测所述至 少一个对象在指定时刻的预计可供数量。

在操作S205，基于所述请求数量和所述至少一个对象在指定时 刻的预计可供数量，确定所述至少一个对象的请求成功率。

在本实施例中，可以将所述请求数量和所述预计可供数量输入成 功率获取模型得到请求成功率，该成功率获取模型可以基于所述请求 数量和所述预计可供数量的比值得到所述至少一个对象的请求成功 率。

在操作S207，基于所述至少一个对象的请求成功率确定所述至 少一个对象的请求顺序。

具体地，可以将请求成功率越高的对象的请求顺序设置的越靠前。

本公开提供的数据处理方法由于基于对象的请求成功率确定所 述至少一个对象的请求顺序，可以至少部分提升所述至少一个对象的 请求成功率，且可以使得计算资源的有效转化率更高，提升计算资源 的有效率。

以下结合图3A～图3B对所述数据处理方法作进一步的说明。

图3A示意性示出了根据本公开实施例的预计可供数量的获取方 法的流程图。

如图3A所示，所述至少基于历史信息获取所述至少一个对象在 指定时刻的预计可供数量可以操作S301～操作S303。

在操作S301，获取多个历史年份中所述至少一个对象在指定时 刻的提供数量。

以表1所示的火车票请求信息为例，用户所需要购买的对象为： 2018/8/19日从GMR到BD，车次为Argo 20的Business类型A等级 的火车票，则所述多个历史年份中所述至少一个对象在指定时刻的提 供数量可以为：2010/8/19日、2011/8/19日、2012/8/19日......2018/8/19 日从GMR到BD，车次为Argo 20的Business类型A等级的火车票 的实际发放数量。需要说明的是，在为用户查询余票时，也可以将查 询范围扩大一些，例如查询2010/8/19日、2011/8/19日、2012/8/19 日......2018/8/19日从GMR到BD的火车票的历史信息，或者， 010/8/19日、2011/8/19日、2012/8/19日......2018/8/19日从GMR到 BD，车次为Argo 20的火车票的信息，又或者，2010/8/19日、2011/8/19 日、2012/8/19日......2018/8/19日从GMR到BD，车次为Argo 20的 Business类型的火车票的信息，并可以将这些信息反馈给用户以供用 户参考，帮助用户尽量能买到所需的火车票。

在操作S302，至少基于所述多个历史年份中所述至少一个对象 在指定时刻的提供数量获取所述至少一个对象在当前年份中指定时 刻的预计可供数量。

例如，如果对象的提供平台未宣布对象提供规则改变，则可以将 所述多个历史年份中所述至少一个对象在指定时刻的提供数量作为 所述预计可供数量。此外，也可以根据多年的对象的提供规律来确定 所述预计可供数量，例如，最近几年的对象的提供数量呈现逐步增多 的趋势，且近几年的增幅相差不大，则可以基于此预测所述预计可供 数量。

在一个具体实施例中，所述预计可供数量N可以通过公式(1) 获取。

在式(1)中，y1是起始年份，n是终止年份，N_y是第_y年实际 提供的对象的数量，通过式(1)获取了指定个数的历史年份中所述 对象的实际提供数量的平均值。需要说明的是，还可以为不同年份中 所述对象的实际提供数量设置权重，例如，越近的年份中所述对象的实际提供数量的权重越大。通过以上方法可以较为准确的预测所述对 象的预计可供数量。

图3B示意性示出了根据本公开实施例的对象的预计可供数量信 息的示意图。

如图3B所示，根据用户设置的对象的请求信息，服务器在查询 历时数据后，查找到与请求信息相匹配的对象在历时年份中实际提供 数量之后，得到对象的预计可供数量，然后，反馈给客户端以便于用 户查看，图3B中为购买火车票的场景，历时年份中共有4个车次： GR1、GR2、GR5和GR8与请求信息相匹配，其中，GR1的可提供 数量最多，用户选取了该车次并开始购票。当然，用户可以同时选取 多个车次进行购票以提升购票的成功率。

在另一个实施例中，为了进一步提升所述预计可供数量的准确度， 所述方法还可以包括如下操作。

在获取多个历史年份中所述至少一个对象在指定时刻的提供数 量之后，获取影响所述至少一个对象的请求成功率的影响因素的预计 值，所述影响因素包括天气因素。

例如，梅雨季节的下午(或阴雨天的下午)，人们更容易小憩一 会，此时对所述对象进行请求可以明显提升请求的成功率。其中，天 气因素的预测值可以通过网络获取，例如，从气象台获取相关的预测 结果。

相应地，所述至少基于述多个历史年份中所述至少一个对象在指 定时刻的提供数量获取所述至少一个对象在当前年份中指定时刻的 预计可供数量包括：基于所述影响因素的预计值和所述多个历史年份 中所述至少一个对象在指定时刻的提供数量获取所述至少一个对象 在当前年份中指定时刻的预计可供数量。

本公开的实施例还进一步考虑了如天气等影响因素对请求成功 率的影响，通过调用相关数据可以进一步提升对象的可供数量的预测 准确度。

在另一个实施例中，由于对象的提供平台同样受资源限制，例如， 受服务器的处理能力的限制，对外提供的服务能力有限，如查询频率、 交易请求频率等有限。对此，所述方法为了尽可能的利用所述对象的 提供平台能提供的资源，以提高资源利用率和转换率，所述方法还可 以包括如下操作。

在获取至少一个对象的请求信息之后，对所述至少一个对象的请 求信息中相同的请求信息进行合并，得到针对至少一个合并对象的请 求信息，其中，所述针对至少一个合并对象的请求信息包括针对所述 至少一个合并对象的请求数量。

表2购票订单

如表2所示，共存在5个对象，其中，前两个对象相同。在进行 查询时，可以将前两个对象进行合并后一起查询。需要说明的是，表 2中的信息仅为示例，不能理解为对本公开的限定，例如，对象的请 求信息可以多于5个或少于5个。

表3合并后购票订单

如表3所示，对象的请求平台每天可能收到很多对象的请求信息， 将这些请求信息进行合并，可以极大的减少对象的请求平台调用对象 的提供平台所提供的接口的次数，降低资源消耗。

相应地，所述基于所述请求数量和所述至少一个对象在指定时刻 的预计可供数量确定所述至少一个对象的请求成功率包括：基于所述 至少一个合并对象的请求数量和所述至少一个合并对象在指定时刻 的预计可供数量确定所述至少一个合并对象的请求成功率。

所述基于所述至少一个对象的请求成功率确定所述至少一个对 象的请求顺序包括：基于所述至少一个合并对象的请求成功率确定所 述至少一个合并对象的请求顺序。

本公开提供的数据处理方法对多个对象的订单先进行合并，然后 再进行请求。当接口调用次数有限时，可以减少请求次数，降低服务 器压力。

在另一个实施例中，所述基于所述至少一个对象的请求成功率确 定所述至少一个对象的请求顺序可以包括如操作。

首先，基于所述至少一个对象的请求成功率确定所述至少一个对 象的查询顺序。

然后，基于所述至少一个对象的查询顺序对所述至少一个对象进 行查询，得到所述至少一个对象的实际可供数量。

如果所述至少一个对象中某个对象的实际可供数量不为零，则给 所述某个对象的用户反馈所述某个对象的实际可供数量信息。

其中，所述至少一个对象中某个对象的实际可供数量不为零可以 包括以下两种情形：第一种，所述至少一个对象中某个对象的实际可 供数量大于所述至少一个对象中某个对象的请求数量，此时，可以提 示用户相关信息避免用户过于焦虑。第二种，所述至少一个对象中某 个对象的实际可供数量小于所述至少一个对象中某个对象的请求数 量(或者实际可供数量与请求数量的比值小于预设比例)，此时，可 以由对象的请求平台代理用户进行对象的权属迁移操作，如代为购票 等，以避免用户错失购票时机。

在一个实施例中，所述至少一个对象中某个对象的实际可供数量 小于所述至少一个对象中某个对象的请求数量，相应地，所述如果所 述至少一个对象中某个对象的实际可供数量不为零，则给所述某个对 象的用户反馈所述某个对象的实际可供数量信息可以包括如下操作。

首先，如果所述至少一个对象中某个对象的实际可供数量与对应 的请求数量满足预设条件，则发送权属迁移请求以获取所述至少一个 对象中某个对象的至少一个权属，其中，所述预设条件表征所述至少 一个对象的获取成功率小于等于预设阈值，其中，所述预设条件可以 为对象的实际可供数量小于对象的请求数量，或对象的实际可供数量 与对象的请求数量的比值小于预设比例等。

然后，获取所述至少一个对象中某个对象的用户的贡献属性，所 述用户的贡献属性表征所述用户对推广所述对象的请求系统的贡献。 其中，该贡献可以是指知名度贡献、资源贡献和财产贡献等至少一种， 在此不做限定。

接着，基于所述用户的贡献属性对所述至少一个对象中某个对象 的用户进行排序，得到用户排序。

然后，基于所述用户排序给所述某个对象的用户反馈所述某个对 象的实际可供数量信息。

需要说明的是，如果多个用户针对同一个对象的贡献值相同，但 是获取的该对象的实际数量小于该对象的请求数量时，为了提供资源 分配的公平度，所述基于所述用户的贡献属性对所述至少一个对象中 某个对象的用户进行排序，得到用户排序包括：基于所述用户的贡献 属性和所述至少一个对象中某个对象的请求信息的生成时间对所述 至少一个对象中某个对象的用户进行排序，得到用户排序。

此外，还可以代理用户的对象的权属获取过程，例如，所述方法 还可以包括如下操作。首先，在给所述某个对象的用户反馈所述某个 对象的实际可供数量信息之后，获取所述某个对象的用户针对所述某 个对象的权属迁移操作。然后，响应于所述权属迁移操作，执行权属 迁移请求。

在另一个实施例中，所述至少一个对象中某个对象的实际可供数 量大于所述至少一个对象中某个对象的请求数量，相应地，所述如果 所述至少一个对象中某个对象的实际可供数量不为零，则给所述某个 对象的用户反馈所述某个对象的实际可供数量信息可以包括如下操 作。

如果所述至少一个对象中某个对象的实际可供数量与对应的请 求数量不满足预设条件，则给所述某个对象的用户反馈所述某个对象 的实际可供数量信息。

然后，获取所述某个对象的用户针对所述某个对象的权属迁移操 作。

接着，响应于所述权属迁移操作，发送权属迁移请求。通过该操 作即可获取所述对象。

在一个具体实施例中，用户提交的请求信息主要包含对象信息和 订单信息，对象信息用于对象的请求平台进行对象查询和获取对象权 属，订单信息用于为用户获取对象权属。提交的请求信息的订单可以 通过社交应用，如脸谱(Facebook)、微信、照片墙(Instagram)、连 我(Line)、瓦次爱普(Whatsapp)等进行传播，邀请好友、同事和 家人进行点赞互动，点赞的次数计为贡献值，供对象的分配时使用。 根据对象的请求信息对应的接口入参，整合对象的请求信息，形成对 象订单，从而最大化合理利用对象的提供平台所提供的接口资源。

因对象的提供平台对接口请求次数限制，基于对象的请求成功率 确定对象的请求顺序。例如，印尼火车票的余票查询接口的次数限制 为500次/分钟。

如果刷票订单小于等于余票可查询次数，则根据购票成功率排序， 依次分给每个刷票订单1次请求，多余的余票可查询次数可以依据购 票成功率排序循环分配。

如果刷票订单大于余票可查询次数，则根据购票成功率，选取排 序靠前的指定个数刷票订单，如前400个刷票订单，将400次余票可 查询次数分配给前400个刷票订单，而剩余次数，如100次余票可查 询次数分配给排在400名以后的长尾刷票订单。其中，每分钟都会给 出指定个数次余票查询分配给长尾刷票订单进行依次余票轮回查询。 基于购票成功率分配余票可查询次数以提升资源转换率，此外，购票 成功率低的订单也会分配少量次数进行依次循环，确保每个购票订单 系统都在为用户运行刷票任务。

当刷到票后，可以基于余票分配策略给用户分配票，例如，社交 传播效果越好的用户，将优先获得票。如出现社交传播效果相同的情 况，将根据用户提交购票订单的时间决定优先权，订单的提交时间越 早的可以优先获得余票。下单成功后，通过短息、邮件或自动电话语 音通知用户进行支付。

图4A示意性示出了根据本公开实施例的数据处理装置的框图。

如图4A所示，所示数据处理装置400，包括请求获取模块410、 预计数量获取模块430、成功率确定模块450和请求顺序获取模块470。

其中，所述请求获取模块410用于获取针对至少一个对象的请求 信息，所述请求信息包括对于所述至少一个对象的请求数量。

所述预计数量获取模块430用于至少基于历史信息获取所述至 少一个对象在指定时刻的预计可供数量。

所述成功率确定模块450用于基于所述请求数量和所述至少一 个对象在指定时刻的预计可供数量，确定所述至少一个对象的请求成 功率。

所述请求顺序获取模块470用于基于所述至少一个对象的请求 成功率确定所述至少一个对象的请求顺序。

具体地，所述预计数量获取模块430可以包括历史数据获取子模 块和预计数量获取子模块。

其中，所述历史数据获取子模块用于获取多个历史年份中所述至 少一个对象在指定时刻的提供数量。

所述预计数量获取子模块用于至少基于所述多个历史年份中所 述至少一个对象在指定时刻的提供数量获取所述至少一个对象在当 前年份中指定时刻的预计可供数量。

在一个实施例中，所述装置400还可以包括影响因素获取模块。

所述影响因素获取模块用于在获取多个历史年份中所述至少一 个对象在指定时刻的提供数量之后，获取影响所述至少一个对象的请 求成功率的影响因素的预计值，所述影响因素包括天气因素。

相应地，所述预计数量获取模块430具体用于基于所述影响因素 的预计值和所述多个历史年份中所述至少一个对象在指定时刻的提 供数量获取所述至少一个对象在当前年份中指定时刻的预计可供数 量。

在另一个实施例中，所述装置400还可以包括合并模块。

所述合并模块用于在获取至少一个对象的请求信息之后，对所述 至少一个对象的请求信息中相同的请求信息进行合并，得到针对至少 一个合并对象的请求信息。

其中，所述针对至少一个合并对象的请求信息包括所述至少一个 合并对象的请求数量。

相应地，所述成功率确定模块450具体用于基于所述至少一个合 并对象的请求数量和所述至少一个合并对象在指定时刻的预计可供 数量确定所述至少一个合并对象的请求成功率。

所述请求顺序获取模块470具体用于基于所述至少一个合并对 象的请求成功率确定所述至少一个合并对象的请求顺序。

例如，所述请求顺序获取模块470可以包括查询顺序获取子模块、 对象数量获取子模块和数量反馈子模块。

其中，所述查询顺序获取子模块用于基于所述至少一个对象的请 求成功率确定所述至少一个对象的查询顺序。

所述对象数量获取子模块用于基于所述至少一个对象的查询顺 序对所述至少一个对象进行查询，得到所述至少一个对象的实际可供 数量。

所述数量反馈子模块用于如果所述至少一个对象中某个对象的 实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的 实际可供数量信息。

例如，所述数量反馈子模块可以包括权属获取单元、贡献获取单 元、用户排序单元和数量反馈单元。

具体地，所述权属获取单元用于如果所述至少一个对象中某个对 象的实际可供数量与对应的请求数量满足预设条件，则发送权属迁移 请求以获取所述至少一个对象中某个对象的至少一个权属，其中，所 述预设条件表征所述至少一个对象的获取成功率小于等于预设阈值。

所述贡献获取单元用于获取所述至少一个对象中某个对象的用 户的贡献属性。

所述用户的贡献属性表征所述用户对推广所述对象的请求系统 的贡献。

所述用户排序单元用于基于所述用户的贡献属性对所述至少一 个对象中某个对象的用户进行排序，得到用户排序。

所述数量反馈单元用于基于所述用户排序给所述某个对象的用 户反馈所述某个对象的实际可供数量信息。

例如，所述用户排序单元具体用于基于所述用户的贡献属性和所 述至少一个对象中某个对象的请求信息的生成时间对所述至少一个 对象中某个对象的用户进行排序，得到用户排序。

在另一个实施例中，所述装置400还可以包括权属迁移操作获取 模块和响应模块。

其中，所述权属迁移操作获取模块用于在给所述某个对象的用户 反馈所述某个对象的实际可供数量信息之后，获取所述某个对象的用 户针对所述某个对象的权属迁移操作。

所述响应模块用于响应于所述权属迁移操作，执行权属迁移请求。

具体地，所述数量反馈单元可以包括反馈子单元、操作获取子单 元和响应子单元。

其中，所述反馈子单元用于如果所述至少一个对象中某个对象的 实际可供数量与对应的请求数量不满足预设条件，则给所述某个对象 的用户反馈所述某个对象的实际可供数量信息。

所述操作获取子单元用于获取所述某个对象的用户针对所述某 个对象的权属迁移操作。

所述响应子单元用于响应于所述权属迁移操作，发送权属迁移请 求。

本公开的另一方面提供了一种数据处理系统，该数据处理系统可 以包括请求响应模块、对象分配模块和权属迁移模块。

其中，所述请求响应模块用于在接收到对象的请求信息后，查询 所述对象的信息。

所述对象分配模块用于基于所述对象的信息确定所述对象的分 配顺序。

所述权属迁移模块用于基于所述对象的分配顺序通知对应的用 户获取所述对象的权属。

图4B示意性示出了根据本公开实施例的数据处理系统的逻辑图。

以下以购票为例进行说明。如图4B所示，用户在向服务器提交 了购票订单之后，该购票订单的信息进入请求响应模块中，该请求响 应模块将购票订单的信息录入购票订单数据库(为动态的)中，该购 票订单数据库中可以包括多个购票订单，请求响应模块将多个购票订 单进行整合得到整合余票查询请求(从而最大化利用票务平台提供的 接口的请求次数)，然后，把整合余票查询请求的信息录入余票查询 请求数据库(动态)中，然后根据整合余票查询请求中各票的请求成 功率对各票的查询顺序进行排序，得到排序后整合余票查询请求的信 息，并录入排序请求数据库(动态)中，然后基于所述排序后整合余 票查询请求进行余票查询，直至排序后整合余票查询请求到期或购买 到票。如果当前查询的票没有余票，则依序查询另外一个票。

如果当前查询的票有余票，则进入对象分配模块，并将余票信息 存储在余票信息数据库(动态)中。所述对象分配模块从所述购票订 单数据库中获取每个用户的购票订单子任务，并将每个用户的购票订 单子任务存储在子任务数据库(动态)中。对象分配模块从上述子任 务数据库中获取上述余票对应的多个用户的购票订单子任务，然后基 于余票分配策略，如优先分配贡献值大的用户，将余票分配给各用户。

如果符合分配策略的购票订单子任务和余票匹配成功，则进入权 属迁移模块，权属迁移模块基于下单流程给用户发送短信和/或邮件 通知，在用户完成支付后出票。如果支付(下单)失败，则再次对该 购票订进行购票。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多 个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本 公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以 被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、 子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如 现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、 基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过 对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现， 或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种 的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、 子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当 该计算机程序模块被运行时，可以执行相应的功能。

例如，请求获取模块410、预计数量获取模块430、成功率确定 模块450和请求顺序获取模块470中的任意多个可以合并在一个模块 中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这 些模块中的一个或多个模块的至少部分功能可以与其他模块的至少 部分功能相结合，并在一个模块中实现。根据本公开的实施例，请求 获取模块410、预计数量获取模块430、成功率确定模块450和请求 顺序获取模块470中的至少一个可以至少被部分地实现为硬件电路， 例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以 通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来 实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任 意几种的适当组合来实现。或者，请求获取模块410、预计数量获取模块430、成功率确定模块450和请求顺序获取模块470中的至少一 个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被 运行时，可以执行相应的功能。

图5示意性示出了根据本公开实施例的计算机系统的方框图。图5示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和 使用范围带来任何限制。

如图5所示，根据本公开实施例的计算机系统500包括处理器 501，其可以根据存储在只读存储器(ROM)502中的程序或者从存 储部分508加载到随机访问存储器(RAM)503中的程序而执行各种 适当的动作和处理。处理器501例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专 用集成电路(ASIC))，等等。处理器501还可以包括用于缓存用途 的板载存储器。处理器501可以包括用于执行根据本公开实施例的方 法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 503中，存储有系统500操作所需的各种程序和数据。 处理器501、ROM 502以及RAM 503通过总线504彼此相连。处理 器501通过执行ROM 502和/或RAM 503中的程序来执行根据本公 开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在 除ROM 502和RAM 503以外的一个或多个存储器中。处理器501 也可以通过执行存储在所述一个或多个存储器中的程序来执行根据 本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统500还可以包括输入/输出(I/O)接 口505，输入/输出(I/O)接口505也连接至总线504。系统500还可 以包括连接至I/O接口505的以下部件中的一项或多项：包括键盘、 鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508； 以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。 通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根 据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁 光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从 其上读出的计算机程序根据需要被安装入存储部分508。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现 为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品， 其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包 含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计 算机程序可以通过通信部分509从网络上被下载和安装，和/或从可 拆卸介质511被安装。在该计算机程序被处理器501执行时，执行本 公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描 述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实 现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介 质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是 单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介 质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实 现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计 算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬 盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程 只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器 (CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组 合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的 有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其 结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包 括上文描述的ROM 502和/或RAM 503和/或ROM 502和RAM 503 以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、 方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点 上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码 的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于 实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的 实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发 生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们 有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的 是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合， 可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者 可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求 中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合 没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情 况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多 种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为 了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述 了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合 使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开 的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改 都应落在本公开的范围之内。

Claims (15)

1.一种数据处理方法，包括：

获取针对至少一个对象的请求信息，所述请求信息包括对于所述至少一个对象的请求数量；

至少基于历史信息获取所述至少一个对象在指定时刻的预计可供数量；

基于所述请求数量和所述至少一个对象在指定时刻的预计可供数量，确定所述至少一个对象的请求成功率；以及

基于所述至少一个对象的请求成功率确定所述至少一个对象的请求顺序。

2.根据权利要求1所述的方法，其中，所述至少基于历史信息获取所述至少一个对象在指定时刻的预计可供数量包括：

获取多个历史年份中所述至少一个对象在指定时刻的提供数量；以及

至少基于所述多个历史年份中所述至少一个对象在指定时刻的提供数量获取所述至少一个对象在当前年份中指定时刻的预计可供数量。

3.根据权利要求2所述的方法，还包括：

在获取多个历史年份中所述至少一个对象在指定时刻的提供数量之后，获取影响所述至少一个对象的请求成功率的影响因素的预计值，所述影响因素包括天气因素；以及

所述至少基于述多个历史年份中所述至少一个对象在指定时刻的提供数量获取所述至少一个对象在当前年份中指定时刻的预计可供数量包括：基于所述影响因素的预计值和所述多个历史年份中所述至少一个对象在指定时刻的提供数量获取所述至少一个对象在当前年份中指定时刻的预计可供数量。

4.根据权利要求1所述的方法，还包括：

在获取至少一个对象的请求信息之后，对所述至少一个对象的请求信息中相同的请求信息进行合并，得到针对至少一个合并对象的请求信息，其中，所述针对至少一个合并对象的请求信息包括针对所述至少一个合并对象的请求数量；

所述基于所述请求数量和所述至少一个对象在指定时刻的预计可供数量，确定所述至少一个对象的请求成功率包括：基于所述至少一个合并对象的请求数量和所述至少一个合并对象在指定时刻的预计可供数量确定所述至少一个合并对象的请求成功率；以及

所述基于所述至少一个对象的请求成功率确定所述至少一个对象的请求顺序包括：基于所述至少一个合并对象的请求成功率确定所述至少一个合并对象的请求顺序。

5.根据权利要求1所述的方法，其中：

所述基于所述至少一个对象的请求成功率确定所述至少一个对象的请求顺序包括：

基于所述至少一个对象的请求成功率确定所述至少一个对象的查询顺序；

基于所述至少一个对象的查询顺序对所述至少一个对象进行查询，得到所述至少一个对象的实际可供数量；以及

如果所述至少一个对象中某个对象的实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的实际可供数量信息。

6.根据权利要求5所述的方法，其中：

所述如果所述至少一个对象中某个对象的实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的实际可供数量信息包括：

如果所述至少一个对象中某个对象的实际可供数量与对应的请求数量满足预设条件，则发送权属迁移请求以获取所述至少一个对象中某个对象的至少一个权属，其中，所述预设条件表征所述至少一个对象的获取成功率小于等于预设阈值；

获取所述至少一个对象中某个对象的用户的贡献属性，所述用户的贡献属性表征所述用户对推广所述对象的请求系统的贡献；

基于所述用户的贡献属性对所述至少一个对象中某个对象的用户进行排序，得到用户排序；以及

基于所述用户排序给所述某个对象的用户反馈所述某个对象的实际可供数量信息。

7.根据权利要求6所述的方法，其中：

所述基于所述用户的贡献属性对所述至少一个对象中某个对象的用户进行排序，得到用户排序包括：基于所述用户的贡献属性和所述至少一个对象中某个对象的请求信息的生成时间对所述至少一个对象中某个对象的用户进行排序，得到用户排序。

8.根据权利要求6所述的方法，还包括：

在给所述某个对象的用户反馈所述某个对象的实际可供数量信息之后，获取所述某个对象的用户针对所述某个对象的权属迁移操作；以及

响应于所述权属迁移操作，执行权属迁移请求。

9.根据权利要求5所述的方法，其中：

所述如果所述至少一个对象中某个对象的实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的实际可供数量信息包括：

如果所述至少一个对象中某个对象的实际可供数量与对应的请求数量不满足预设条件，则给所述某个对象的用户反馈所述某个对象的实际可供数量信息；

获取所述某个对象的用户针对所述某个对象的权属迁移操作；以及

响应于所述权属迁移操作，发送权属迁移请求。

10.一种数据处理装置，包括：

请求获取模块，用于获取针对至少一个对象的请求信息，所述请求信息包括对于所述至少一个对象的请求数量；

预计数量获取模块，用于至少基于历史信息获取所述至少一个对象在指定时刻的预计可供数量；

成功率确定模块，用于基于所述请求数量和所述至少一个对象在指定时刻的预计可供数量，确定所述至少一个对象的请求成功率；以及

请求顺序获取模块，用于基于所述至少一个对象的请求成功率确定所述至少一个对象的请求顺序。

11.根据权利要求10所述的装置，其中，所述预计数量获取模块包括：

历史数据获取子模块，用于获取多个历史年份中所述至少一个对象在指定时刻的提供数量；以及

预计数量获取子模块，用于至少基于所述多个历史年份中所述至少一个对象在指定时刻的提供数量获取所述至少一个对象在当前年份中指定时刻的预计可供数量。

12.根据权利要求10所述的装置，还包括：

合并模块，用于在获取至少一个对象的请求信息之后，对所述至少一个对象的请求信息中相同的请求信息进行合并，得到针对至少一个合并对象的请求信息，其中，所述针对至少一个合并对象的请求信息包括所述至少一个合并对象的请求数量；

所述成功率确定模块具体用于基于所述至少一个合并对象的请求数量和所述至少一个合并对象在指定时刻的预计可供数量确定所述至少一个合并对象的请求成功率；以及

所述请求顺序获取模块具体用于基于所述至少一个合并对象的请求成功率确定所述至少一个合并对象的请求顺序。

13.根据权利要求10所述的装置，其中，所述请求顺序获取模块包括：

查询顺序获取子模块，用于基于所述至少一个对象的请求成功率确定所述至少一个对象的查询顺序；

对象数量获取子模块，用于基于所述至少一个对象的查询顺序对所述至少一个对象进行查询，得到所述至少一个对象的实际可供数量；以及

数量反馈子模块，用于如果所述至少一个对象中某个对象的实际可供数量不为零，则给所述某个对象的用户反馈所述某个对象的实际可供数量信息。

14.一种计算机系统，包括：

一个或多个处理器；

存储装置，用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现根据权利要求1～9中任一项所述的方法。

15.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时实现根据权利要求1～9中任一项所述的方法。

Images