具体实施方式
现有技术中,虚拟资源的服务系统在确定预约单的成交时间时,通常默认不同的预约单需要等待相同的天数成交,并依此计算不同预约单的成交时间。具体可以参见表1和表2。
表1
日期 |
库存量 |
5月2日 |
100万 |
5月3日 |
200万 |
5月4日 |
300万 |
表2
日期 |
预约总量 |
4月28日 |
100万 |
4月29日 |
50万 |
上述表1为虚拟资源的库存量数据表,其中,每日的库存量可以不同,当日的库存量售卖完之后,当日将不再继续售卖。表2为用户对虚拟资源的预约数据表,其中,可以预先规定用户每天可以预约的最大量,当当日的预约总量超过该天可预约的最大量时,将不允许用户当天继续预约。
当用户在4月30日对虚拟资源进行预约时,针对4月30日的预约单,虚拟资源的服务系统在确定其成交时间时,基于表2可以得到4月30日之前的总预约量为150万,基于表1可以得到5月2日可售卖的库存量为100万,5月2日和5月3日可售卖的库存总量为300万。由此可确定,4月30日的预约单的成交时间为5月3日,即预计4月30日的预约单在3天后成交。
在得到4月30日的预约单的成交时间后,针对预约时间在4月28日以及4月29日的未成交预约单,可以按照与4月30日的预约单相同的等待天数(即3天)重新确定成交时间,即预计4月28日的预约单的成交时间为5月1日,4月29日的预约单的成交时间为5月2日。
然而,基于上述表1和表2可知,5月1日并没有库存量,因此,4月28日的预约单的实际成交时间为5月2日;再者,4月30日的预约单的预计成交时间为5月3日,但是,若用户在4月30日的预约量比较多,则4月30日的部分预约单需等到5月4日才可以成交。
由此可见,采用现有方法确定得到的预约单的成交时间与实际成交时间相差较大,准确度较低。
为了解决上述技术问题,本申请实施例提供一种成交时间的确定、展示方法和装置,该成交时间的确定方法包括:获取虚拟资源每日的库存量;根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
本申请实施例提供的技术方案,在确定虚拟资源某个预约单的成交时间时,由于可以根据该预约单的预约时间,确定在该预约时间之前所有未成交的预约单的预约总量,即统计得到在该预约单之前还未成交的虚拟资源总量,因此,在此基础上,可以根据虚拟资源每日的库存量,得到较为准确的成交时间。针对未成交的其他预约单而言,都可以通过本申请实施例提供的技术方案确定得到较为准确的成交时间,这样,在向用户展示预约单的成交时间时,由于成交时间的准确度较高,因此,可以提升用户体验。
为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
本申请实施例记载的虚拟资源可以是理财产品,也可以是其他虚拟资源,这里不做具体限定。
本申请实施例记载的虚拟资源每日的库存量可以理解为虚拟资源每日可售卖的总量,其中,每日的库存量可以不同,且每日可售卖的总量不能超过当日的库存量,当售卖的总量达到当日的库存量时,将不再继续售卖。
本申请实施例记载的预约单是由虚拟资源的服务体系在用户预约购买虚拟资源并成功后,根据用户的预约时间以及预约量等信息生成。
本申请实施例的应用场景可以至少包括两种,一种是在用户预约成功并生成预约单时,基于本申请实施例提供的技术方案确定预约单的成交时间,另一种是用户在后续查看预约单的成交时间时,基于本申请实施例提供的技术方案重新确定并更新预约单的成交时间。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1是本申请的一个实施例成交时间的确定方法的流程示意图。所述方法包括以下步骤。
S102:获取虚拟资源每日的库存量。
在S102中,虚拟资源的服务系统在确定某个预约单(为了便于区分,以下称为目标预约单)的成交时间时,可以获取虚拟资源每日的库存量。其中,虚拟资源每日的库存量可以预先设定,且,每日的库存量可以相同,也可以不同。
本申请实施例在获取虚拟资源每日的库存量时,可以根据目标预约单的预约时间(为了便于区分,以下称为目标预约时间),获取目标预约时间之后的若干日每日的库存量,其中,具体获取几日的库存量可以根据实际情况确定,优选地,可以获取目标预约时间之后3至10日每日的库存量。
例如,目标预约单的目标预约时间为2018年4月30日,在获取虚拟资源每日的库存量时,可以获取2018年5月1日至5月3日每日的库存量,也可以获取2018年5月1日至5月5日每日的库存量。
需要说明的是,由于预约单的成交时间通常以日为维度,因此,本申请实施例在确定成交时间时,获取的是每日的库存量,在其他实现方式中,如果预约单的成交时间以其他时长为维度,那么,相应地,可以按照其他时长获取虚拟资源的库存量。例如,如果预约单的成交时间以半日为维度,则可以获取没半日的库存量。为了便于理解和说明整个技术方案,本申请的各实施例均以日作为成交时间的维度进行说明。
S104:根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量。
在S104中,可以根据目标预约单的目标预约时间,确定在该目标预约单之前有多少未成交的虚拟资源,即确定预约时间在目标预约时间之前的未成交预约单对应的虚拟资源预约总量。
本申请实施例在确定虚拟资源预约总量时,为了提高计算效率,节省计算成本,同时不丢失预约量与时间相关的分布特征,保证后续确定的成交时间的准确性,可以以小时为统计周期,确定未成交的预约单在每小时内的预约总量,并根据所述每小时内的预约总量以及所述目标预约时间,确定得到所述虚拟资源预约总量。
其中,若当前时间即为所述目标预约时间,则所述未成交的预约单即为所述目标预约时间之前未成交的所有预约单;若当前时间在所述目标预约时间之后,则所述未成交的预约单包括所述目标预约时间之前未成交的所有预约单以及所述目标预约时间至当前时间之间未成交的部分或全部预约单。
例如,目标预约时间为2018年4月30日20点20分,若当前时间为2018年4月30日21点20分,则,所述未成交的预约单可以包括2018年4月30日20点20分之前未成交的所有预约单,以及2018年4月30日20点20分至21点之间的未成交预约单;若当前时间为目标预约时间2018年4月30日20点20分,则,所述未成交的预约单为2018年4月30日20点20分之前未成交的所有预约单。
由于本申请实施例可以将每个小时内预约单的预约总量看作一个整体,不再针对单个预约单的预约量进行管理和统计,因此,可以提高效率,节省计算成本;此外,由于获取的是每小时内预约总量,因此,可以得到预约量在每小时内的分布特征,减少了特征损失,在一定程度上能够保证后续确定得到的成交时间的准确性。
应理解,本申请实施例除了以小时作为统计周期,在其他实现方式中,在节省计算成本和保证成交时间准确性的前提下,也可以以其他时长为统计周期,例如,以半小时为统计周期,或以两小时为统计周期等,这里不做具体限定。为了便于理解和说明整个技术方案,本申请的各实施例均以小时作为统计周期进行说明。
本申请实施例在确定未成交预约单在每小时内的预约总量时,可以按照整点统计每小时内的预约总量。
此外,在统计每小时内的预约总量时,可以采用在线统计的方式确定得到,也可以采用离线统计的方式确定得到,具体可以根据实际需求确定采用哪种方式,这里不做具体限定。
在根据每小时内的预约总量以及所述目标预约时间,确定所述虚拟资源预约总量时,可以包括以下步骤:
根据所述每小时内的预约总量,确定目标小时之前的至少一个小时对应的第一预约总量,所述目标小时为所述目标预约时间所在的小时;
根据所述目标小时内的预约总量以及所述目标预约时间,确定第二预约总量,所述第二预约总量为所述目标小时的起始时间至所述目标预约时间之间的预约总量;
将所述第一预约总量与所述第二预约总量的和确定为所述虚拟资源预约总量。
上述步骤的主要思路是,在已知每小时内的预约总量以及目标预约时间的基础上,将需要确定的所述虚拟资源预约总量划分成两部分,一部分是目标预约时间所在的目标小时之前至少一个小时对应的预约量的和,由第一预约总量表示,另一部分是目标预约时间所在的目标小时内,预约时间在所述目标小时的起始时间至所述目标预约时间之间的预约单对应的预约总量,由第二预约总量表示。
在确定所述第一预约总量时,首先,可以根据目标预约单的目标预约时间,确定该目标预约时间在哪一个统计小时内,这里为了便于区分,可以将目标预约时间所在的小时称为目标小时。
其次,在确定目标小时后,可以确定在该目标小时之前未成交的预约单对应的至少一个小时。
再次,可以根据所述每个小时内的预约总量,确定所述至少一个小时对应的至少一个预约总量;
最后,将所述至少一个小时对应的至少一个预约总量求和,可以得到所述第一预约总量。
在确定所述第二预约总量时,可以根据所述目标小时内的预约总量以及所述目标预约时间确定得到。具体可以包括以下步骤:
获取预先训练得到预测模型,所述预测模型用于根据一小时内的任一时间预测所述一小时内部分预约总量占所述一小时内预约总量的比值,所述部分预约总量为所述一小时的起始时间至所述任一时间内的预约总量;
根据所述目标预约时间以及所述预测模型,确定第一比值,所述第一比值为所述第二预约总量与所述目标小时内的预约总量的比值;
将所述目标小时内的预约总量和所述第一比值的乘积确定为所述第二预约总量。
本申请实施例中,可以预先对每天24小时内每小时的预约量分布情况进行学习训练,得到所述预测模型。所述预约量分布情况可以理解为在一小时内的任一时间被预约的虚拟资源量与该小时内被预约的虚拟资源总量的比值。根据以及一小时内的任一时间,可以预测得到所述一小时内部分预约总量占所述一小时内预约总量的比值,所述部分预约总量可以理解为预约时间在所述一小时的起始时间至所述任一时间内的预约总量。
所述预测模型可以通过以下步骤训练得到:
首先,获取样本数据。
所述样本数据可以是目标预约时间之前若干日(可以是15日,也可以是20日或30日等,具体根据实际情况确定)的样本数据,所述样本数据具体可以包括历史每日每小时内的预约总量,以及所述历史每日每小时内每个预约单的预约时间、预约量。
例如,可以将目标预约时间之前15日内,每日每小时内的预约总量以及每日每小时内每个预约单的预约时间和预约量作为样本数据。
其次,根据所述样本数据,确定样本特征。
在获取到样本数据后,可以对样本数据进行特征工程处理,得到样本特征。本申请实施例中,样本特征可以包括两种,一种是每日每小时内的不同时间,另一种是与所述不同时间分别对应的比值。
所述不同时间可以优选一小时内的不同分钟数。
与所述不同时间分别对应的比值,以样本小时内的一个目标时间(即所述样本小时内的其中一个时间)对应的一个比值为例,该比值可以表征样本小时的起始时间至所述目标时间之间的预约总量与所述样本小时内的预约总量的比值,所述样本小时为每日的其中一个小时。
例如,针对每日晚上20点至21点,所述不同时间可以是20点1分、20点2分、……、20点59分,21点,与不同时间分别对应的比值为20点至20点1分之间的预约总量与20点至21点之间预约总量的比值、20点至20点2分之间的预约总量与20点至21点之间预约总量的比值、……、20点至20点59分之间的预约总量与20点至21点之间预约总量的比值。
最后,采用预设的机器学习算法对所述样本特征进行训练,得到所述预测模型。
所述机器学习算法可以是线性回归算法,也可以是神经网络算法,还可以是其他机器学习算法,这里不做具体限定,只要可以学习到每天24小时内每小时的预约量分布情况即可。
在基于上述记载的方法训练得到所述预测模型后,在确定所述第二预约总量时,可以获取预先训练的所述预测模型,将所述目标预约时间作为所述预测模型的输入,输出结果即为所述第二预约总量与所述目标小时内的预约总量的第一比值。
在得到第一比值后,已知所述目标小时内的预约总量,可以将所述第一笔之与所述目标小时内的预约总量相乘,得到的乘积即为所述第二预约总量。
需要说明的是,为了保证所述第二预约总量的准确性,所述预测模型可以通过上述记载的方法定时或不定时更新,优选地,可以将近期数据作样本数据重新训练得到所述预测模型,以学习到最新的预约量分布情况,提高所述第二预测总量的准确性。
在得到所述第一预约总量以及所述第二预约总量后,可以将两者求和,求和的结果即为所述虚拟资源预约总量。
S106:根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
在S106中,基于S102获取的虚拟资源每日的库存量以及S104确定的虚拟资源预约总量,可以确定目标预约单的成交时间。其中,本申请实施例确定的成交时间可以精确到日。
例如,目标预约单的预约时间为2018年4月30日20点20分,已知2018年5月1日的库存量为100万,5月2日的库存量为200万,5月3日的库存量为100万,2018年4月30日20点20分前未成交预约单的虚拟资源预约总量为330万,那么,可以确定目标预约单的成交时间为5月3日。
需要说明的是,本申请实施例的成交时间可以动态更新,每次更新都可以参照上述S102至S106记载的方法确定得到新的成交时间。这样,无论用户中间是否取消预约单,都可以将取消的预约单考虑在内,进而得到较为准确的成交时间。
在本申请的一个实施例中,在确定得到目标预约单的成交时间后,还可以将成交时间展示给用户,在展示给用户时,可以是主动展示,也可以是在接收到用户对成交时间的查询请求时展示,不做具体限定。
由于本申请实施例确定得到的成交时间较为准确,因此,在将成交时间展示给用户后,用户可以得知目标预约单可以成交的准确时间,提高用户体验。
本申请实施例提供的技术方案,在确定虚拟资源某个预约单的成交时间时,由于可以根据该预约单的预约时间,确定在该预约时间之前所有未成交的预约单的预约总量,即统计得到在该预约单之前还未成交的虚拟资源总量,因此,在此基础上,可以根据虚拟资源每日的库存量,得到较为准确的成交时间。针对未成交的其他预约单而言,都可以通过本申请实施例提供的技术方案确定得到较为准确的成交时间,这样,在向用户展示预约单的成交时间时,由于成交时间的准确度较高,因此,可以提升用户体验。
为了便于理解整个技术方案,可以参见图2。图2为本申请的一个实施例成交时间的确定方法的流程示意图,图2所示的实施例与图1属于相同的发明构思。为了便于理解,图2以目标预约单的目标预约时间为2018年4月30日20点20分为例进行说明,其中,可以假设当前时间为2018年4月30日21点20分,且2018年4月28日12点之后的预约单均未成交。所述方法包括以下步骤。
S201:获取虚拟资源每日的库存量。
可以获取2018年5月1日至5月3日每日的库存量(假设4月30日的库存量已售卖完)。
S202:确定未成交的预约单在每小时内的预约总量。
可以按照整点,确定2018年4月28日12点至2018年4月30日21点之间每小时内的预约总量。
S203:确定目标预约单所在的目标小时之前至少一个小时对应的第一预约总量。
目标预约单所在的目标小时为2018年4月30日20点至2018年4月30日21点,目标小时之前至少一个小时为2018年4月28日12点至2018年4月30日20点之间的32个小时,所述第一预约总量等于这32个小时对应的32个预约总量的和。
S204:获取预先训练的预测模型。
所述预测模型可以通过图1所示实施例中记载的方法训练得到,这里不再重复描述。需要注意的是,所述预测模型可以基于2018年4月1日至4月29日每日每小时的预约总量以及每日每小时的预约单的预约量和预约时间训练得到。
S205:根据所述目标预约单的目标预约时间以及所述预测模型,确定第一比值。
所述第一比值为2018年4月30日20点至20点20分之间的预约总量与目标小时(即2018年4月30日20点至21点)内的预约总量的比值。
S206:根据所述第一比值以及所述目标小时内的预约总量,确定第二预约总量。
所述第二预约总量即为2018年4月30日20点至20点20分之间的预约总量。
S207:将所述第一预约总量与所述第二预约总量的和确定为虚拟资源预约总量。
所述虚拟资源预约总量为预约时间在所述目标预约时间之前的未成交预约单对应的预约总量,即2018年4月28日12点至2018年4月30日20点20分之间的预约总量。
S208:根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
假设2018年5月1日至5月3日每日的库存量依次为:100万、200万、100万,2018年4月28日12点至2018年4月30日20点20分之间的预约总量为350万,则可以确定成交时间为5月3日。
S209:将所述成交时间展示给用户。
基于本申请实施例提供的技术方案,可以确定每一个未成交的预约单的成交时间,且,在确定成交时间时,由于可以根据该预约单的预约时间,确定在该预约时间之前所有未成交的预约单的预约总量,因此,在此基础上,可以根据虚拟资源每日的库存量,得到较为准确的成交时间。在向用户展示成交时间时,由于成交时间的准确度较高,因此,用户可以得知预约单可以成交的准确时间,提升用户体验。
图3为本申请的一个实施例成交时间的展示方法的流程示意图,所述方法包括以下步骤。
S302:获取虚拟资源每日的库存量。
S304:根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量。
S306:根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
上述S302至S306的具体实现可参考图1所示实施例中对应步骤的具体实现,本说明书一个或多个实施例在此不再赘述。
S308:将所述成交时间展示给用户。
由于成交时间较为准确,因此,用户可以得知目标预约单可以成交的准确时间,提升用户体验。
在本申请的一个实施例中,在获取虚拟资源每日的库存量之前,可以接收用户对虚拟资源的预约请求。
本实施例对应的应用场景是,用户通过互联网预约购买虚拟资源时,向虚拟资源的服务系统发起对虚拟资源的预约请求,虚拟资源的服务系统在接收到用户的预约请求,可以响应该预约请求,之后,在用户预约成功时,可以生成预约单后,并基于上述步骤S302至S308确定成交时间,并将确定的成交时间展示给用户。
在确定成交时间后,可以向用户展示详情页面,在该详情页面中可以展示预约单的成交时间。
在本申请的一个实施例中,在获取虚拟资源每日的库存量之前,可以接收所述用户对所述目标预约单的成交时间查询请求。
本实施例对应的应用场景是,在用户预约成功并向用户展示成交时间后,在预约单成交之前,当用户想再次查看成交时间时,用户可以向虚拟资源的服务系统发起预约单的成交时间查询请求,例如,用户可以通过进入详情页面的方式发起成交时间查询请求,该详情页面中包含成交时间的信息。
虚拟资源的服务系统在接收到用户的成交时间查询请求后,可以基于上述步骤S302至S308确定成交时间,并将重新确定的成交时间展示给用户。
本申请实施例提供的技术方案,在向用户展示预约单的成交时间之前,由于可以根据该预约单的预约时间,确定在该预约时间之前所有未成交的预约单的预约总量,即统计得到在该预约单之前还未成交的虚拟资源总量,因此,在此基础上,可以根据虚拟资源每日的库存量,得到较为准确的成交时间。这样,在向用户展示预约单的成交时间时,由于成交时间的准确度较高,因此,可以提升用户体验。
上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
图4是本申请的一个实施例电子设备的结构示意图。请参考图4,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图4中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成成交时间的确定装置。处理器,执行存储器所存放的程序,并具体用于执行以下操作:
获取虚拟资源每日的库存量;
根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;
根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
上述如本申请图4所示实施例揭示的成交时间的确定装置执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图1和图2的方法,并实现成交时间的确定装置在图1和图2所示实施例中的功能,本申请实施例在此不再赘述。
当然,除了软件实现方式之外,本申请的电子设备并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的便携式电子设备执行时,能够使该便携式电子设备执行图1和图2所示实施例的方法,并具体用于执行以下操作:
获取虚拟资源每日的库存量;
根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;
根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
图5是本申请的一个实施例成交时间的确定装置50的结构示意图。请参考图5,在一种软件实施方式中,所述成交时间的确定装置50可包括:获取单元51、资源总量确定单元42和成交时间确定单元43,其中:
获取单元51,获取虚拟资源每日的库存量;
资源总量确定单元52,根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;
成交时间确定单元53,根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间。
可选地,所述资源总量确定单元52,根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量,包括:
确定未成交的预约单在每小时内的预约总量;
根据所述每小时内的预约总量以及所述目标预约时间,确定所述虚拟资源预约总量。
可选地,所述资源总量确定单元52,根据所述每小时内的预约总量以及所述目标预约时间,确定所述虚拟资源预约总量,包括:
根据所述每小时内的预约总量,确定目标小时之前的至少一个小时对应的第一预约总量,所述目标小时为所述目标预约时间所在的小时;
根据所述目标小时内的预约总量以及所述目标预约时间,确定第二预约总量,所述第二预约总量为所述目标小时的起始时间至所述目标预约时间之间的预约总量;
将所述第一预约总量与所述第二预约总量的和确定为所述虚拟资源预约总量。
可选地,所述资源总量确定单元52,根据所述每小时内的预约总量,确定目标小时之前的至少一个小时对应的第一预约总量,包括:
根据所述每小时内的预约总量,确定所述至少一个小时对应的至少一个预约总量;
将所述至少一个预约总量的和确定为所述第一预约总量。
可选地,所述资源总量确定单元52,根据所述目标小时内的预约总量以及所述目标预约时间,确定第二预约总量,包括:
获取预先训练得到预测模型,所述预测模型基于样本数据的样本特征训练得到;
根据所述目标预约时间以及所述预测模型,确定第一比值,所述第一比值为所述第二预约总量与所述目标小时内的预约总量的比值;
将所述目标小时内的预约总量和所述第一比值的乘积确定为所述第二预约总量。
可选地,所述资源总量确定单元52,通过以下方式训练得到所述预测模型:
获取样本数据,所述样本数据包括历史每日每小时内的预约总量,以及所述历史每日每小时内每个预约单的预约时间、预约量;
根据所述样本数据,确定样本特征,所述样本特征包括所述历史每日每小时内的不同时间,以及与所述不同时间分别对应的比值,所述比值用于表征样本小时的起始时间至所述样本小时的目标时间之间的预约总量与所述样本小时内的预约总量的比值,所述样本小时为每日的其中一个小时,所述目标时间为所述样本小时内的其中一个时间;
采用预设的机器学习算法对所述样本特征进行训练,得到所述预测模型。
可选地,所述成交时间的确定装置50还包括:展示单元54,其中:
所述展示单元54,在所述成交时间确定单元53确定所述目标预约单的成交时间后,将所述成交时间展示给用户。
本申请实施例提供的成交时间的确定装置50还可执行图1和图2的方法,并实现成交时间的确定装置在图1和图2所示实施例的功能,本申请实施例在此不再赘述。
图6是本申请的一个实施例电子设备的结构示意图。请参考图6,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图6中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成成交时间的展示装置。处理器,执行存储器所存放的程序,并具体用于执行以下操作:
获取虚拟资源每日的库存量;
根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;
根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间;
将所述成交时间展示给用户。
上述如本申请图6所示实施例揭示的成交时间的展示装置执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图3的方法,并实现成交时间的展示装置在图3所示实施例中的功能,本申请实施例在此不再赘述。
当然,除了软件实现方式之外,本申请的电子设备并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的便携式电子设备执行时,能够使该便携式电子设备执行图3所示实施例的方法,并具体用于执行以下操作:
获取虚拟资源每日的库存量;
根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;
根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间;
将所述成交时间展示给用户。
图7是本申请的一个实施例成交时间的展示装置70的结构示意图。请参考图7,在一种软件实施方式中,所述成交时间的展示装置70可包括:获取单元71、资源总量确定单元72、成交时间确定单元73和展示单元74,其中:
获取单元71,获取虚拟资源每日的库存量;
资源总量确定单元72,根据目标预约单的目标预约时间,确定预约时间在所述目标预约时间之前的未成交预约单对应的虚拟资源预约总量;
成交时间确定单元73,根据所述虚拟资源每日的库存量以及所述虚拟资源预约总量,确定所述目标预约单的成交时间;
展示单元74,将所述成交时间展示给用户。
本申请实施例提供的成交时间的展示装置70还可执行图3的方法,并实现成交时间的展示装置在图3所示实施例的功能,本申请实施例在此不再赘述。
总之,以上所述仅为本申请的较佳实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitorymedia),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本申请中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。