一种资金资源的调度方法及装置
技术领域
本申请涉及信息处理技术领域,尤其涉及一种资金资源的调度方法及装置。
背景技术
资源调度是计算机应用技术领域的一种常见概念,其既可以指一台设备内部的资源调度(例如为不同的应用程序分配处理线程、内存资源等),也可以指也可以多台设备之间的任务调度(例如为不同的设备分配带宽资源)。在这些应用场景中,“资源”往往都是有限的,而资源使用方对资源的需求远大于资源的总数量,因此,如何对有限的资源进行合理的调度、使得资源利用率能够尽量提高,一直是研究人员所关注的重要方向。
周期性调度是资源调度中的一种常见策略,这种方式适用于资源使用方对资源具有规律性需求的应用场景。例如,在一个定时任务系统中,应用程序A需要在每个整点的第1~10分钟运行、应用程序B需要在每个整点的第6~15分钟运行、应用程序C需要在每个整点的第11~20分钟运行。可以看出,A和C的运行时段完全错开,因此理论上可以设置A与C复用相同的处理线程。假设A和C运行均需要5个处理线程,则在每个整点的第0分钟,从线程池中将5个线程分配给A使用,在第10分钟,A运行完毕后,将5个线程释放回线程池,这5个线程又可以在第11分钟分配给应用程序C使用。
然而在实际应用中,很多应用程序在运行期间对于线程的需求并不是保持不变的,而且往往是在程序运行的初始阶段需要较多的线程,随着运行时间的推进,所需的线程数量逐渐减少。例如,应用程序A在运行的前1~5分钟需要5个线程,在第6~10分钟仅需要2个线程。其中3个线程将在第5分钟使用完毕后提前释放回线程池,也就是说,这3个线程在每个整点的第6~10分钟是处于一种临时的完全闲置状态的。考虑到很多应用程序都具有这样的特性,因此系统整体的线程资源利用率仍然较低。
除了处理线程分配外,在其他一些应用场景,例如对于有限带宽资源、有限缓存资源的分配等等,也都存在着类似的资源闲置问题。
发明内容
针对上述技术问题,本申请提供一种资金资源的调度方法及装置,技术方案如下:
根据本申请的第1方面,提供一种资源调度方法,将每次分配操作所分配出的资源定义为一个资源集合、并将一个资源集合内分不同批次释放的资源定义为不同的资源子集,所述方法包括:
针对已分配的任意集合,确定该集合内各子集的剩余占用时长;
接收到已释放的任意子集、并确定该子集内的资源为临时闲置资源后,确定该闲置子集的剩余闲置时长;
在已分配且未释放的其他集合中,查找与所述闲置子集相匹配的当前被占用子集;其中,所述其他集合,与所述闲置子集所属的集合为不同集合;所述匹配为:被占用子集的剩余占用时长不大于所述闲置子集的剩余闲置时长、且被占用子集的资源数量不小于所述闲置子集的资源数量;
利用所查找到的被占用子集对所述闲置子集进行功能替换,并将所述闲置子集内的资源标识为非临时闲置资源;所述功能替换为:对资源分配计划进行更新,针对原本需要所述闲置子集资源承载的资源分配操作,将其承载对象修改为所查找到被占用子集的资源。
根据本申请的第2方面,提供一种资源调度装置,将每次分配操作所分配出的资源定义为一个资源集合、并将一个资源集合内分不同批次释放的资源定义为不同的资源子集,所述装置包括:
占用时长确定模块,用于针对已分配的任意集合,确定该集合内各子集的剩余占用时长;
闲置时长确定模块,用于在接收到已释放的任意子集、并确定该子集内的资源为临时闲置资源后,确定该闲置子集的剩余闲置时长;
查找模块,用于在已分配且未释放的其他集合中,查找与所述闲置子集相匹配的当前被占用子集;其中,所述其他集合,与所述闲置子集所属的集合为不同集合;所述匹配为:被占用子集的剩余占用时长不大于所述闲置子集的剩余闲置时长、且被占用子集的资源数量不小于所述闲置子集的资源数量;
替换模块,用于利用所查找到的被占用子集对所述闲置子集进行功能替换,并将所述闲置子集内的资源标识为非临时闲置资源;所述功能替换为:对资源分配计划进行更新,针对原本需要所述闲置子集资源承载的资源分配操作,将其承载对象修改为所查找到被占用子集的资源。
本申请所提供的技术方案,将每次分配操作所分配出资源按照不同的释放批次切分为不同的资源子集。这样,每当实际回收一份资源子集后,如果该子集处于临时闲置状态,则可以从当前正在被占用资源中,找到届时能够接替上述临时闲置子集的被占用子集,从而将临时闲置子集中的资源转换为非临时闲置资源。由于非临时闲置资源可以参与正常的资源分配而不受周期性资源调度的限制,因此使得整体的资源利用率得到了有效的提升。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1是本申请的资源调度方法的流程示意图;
图2是本申请的资源调度装置的结构示意图;
图3是用于配置本申请装置的一种设备的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本申请保护的范围。
背景技术中所描述的周期性资源调度是一种理想情况,更多的实际应用中,资源使用方对于资源的使用需求一般不会是完全固定的,因此往往需要预留出一部分资源,以应对不规律的资源使用需求。
仍以线程资源调度为例,由于每个线程都会消耗内存,如果同时运行的线程数量过多,会对系统的性能造成较大影响,因此,一般对会系统设定线程池,通过限定线程数量的方式来保证系统的性能。应用周期性资源调度的方案,在线程数量受限的前提下,如果系统中各应用程序的运行时间及线程需求数量都是相对固定的,那么理论上可以通过合理的安排,令有限的线程资源得到充分的利用。然而在实际应用中,不可能所有的应用程序都有固定的运行时间,因此除了给周期性执行的应用程序分配线程之外,一般还要在线程池中保留一定数量的线程,以应对那些突发的应用程序执行需求。考虑到这种实际应用需求,这些保留的线程也可以视为一种有效的资源占用。
然而,对于背景技术中所描述的情况,尽管应用程序A提前释放了3个线程,但是这三个线程还要在第11分钟时分配给应用程序C使用,因此这3个线程只是临时闲置,并不能等同于其他的保留线程,用于分配给突发的应用程序,除非刚好有应用程序需要在第6~10分钟使用线程,但是这种情况发生几率非常低。
针对上述问题,本申请提供资源调度方案如下:
首先,将每次分配操作所分配出的资源定义为一个资源集合,并且将一个资源集合内分不同批次释放的资源定义为不同的资源子集。
进而,对于任意一份已经分配出去的资源集合,基于资源使用方对资源的使用需求规律,可以确定出该集合内各个子集对应的资源释放时间,从而确定:从当前时刻开始计时,各个子集分别还需要多久会被释放,也即各个子集的剩余占用时长。可以理解的是,每个资源子集的“剩余占用时长”是会随着时间的推移而动态减小的。当某个资源子集的“剩余占用时长”变为0时,意味着对应的资源将被释放。
另一方面,对于一份刚刚被释放的资源子集,基于其在下一个调度周期的使用需求,可以确定出该子集对应资源的下次被分配时间,从而确定:从当前时刻开始计时,该子集还需要多久会被再次分配,也即各个子集的剩余闲置时长,或者说,该子集在下一次被分配之前,还要临时闲置多久。可以理解的是,“剩余闲置时长”也是会随着时间的推移而动态减小的。
在上述定义及说明的基础上,本申请提供一种资源调度方法,参见图1所示,该方法可以包括以下步骤:
S101,针对已分配的任意集合,确定该集合内各子集的剩余占用时长;
S102,接收到已释放的任意子集、并确定该子集内的资源为临时闲置资源后,确定该闲置子集的剩余闲置时长;
本申请方案主要针对“临时闲置资源”提出,即:在当前时间点统计,剩余闲置时长大于0的子集。对于非临时闲置资源,可能存在两种情况,一类是马上会被再次分配出去,对应的剩余闲置时长为0;另一类是没有确定的再次分配计划,可视为剩余闲置时长为∞,但是其功能上已经等同于保留资源,可以任意参与非计划性资源分配。可以看出,这两类“非临时闲置资源”的情况实际并不属于本申请需要解决的资源闲置问题范畴。
S103,在已分配且未释放的其他集合中,查找与所述闲置子集相匹配的当前被占用子集;
这里的“其他集合”是指与所述闲置子集所属集合不同的集合,而“匹配”需要同时满足两方面条件,定义如下:
a)被占用子集的剩余占用时长不大于所述闲置子集的剩余闲置时长;
b)被占用子集的资源数量不小于所述闲置子集的资源数量。
S104,利用所查找到的被占用子集对所述闲置子集进行功能替换,并将所述闲置子集内的资源标识为非临时闲置资源;
这里的“功能替换”是指:对原有的资源分配计划进行更新,针对原本需要所述闲置子集资源承载的资源分配操作,将其承载对象修改为所查找到被占用子集的资源。
“临时闲置资源”的“临时”性主要体现在:尽管资源被提前释放,但是该资源并不是完全意义上自由,这是因为根据资源分配计划,该资源将在未来的某个时间被再次分配。而本申请所提供的技术方案,通过切分资源子集的方式,能够预先了解到在未来的一段时间内,哪些当前正在被占用的资源子集会被释放、多久以后释放。进而,在当前时间点,针对任意一份的“临时闲置资源”Ri,如果能够在其他集合中找到一份与其匹配(匹配的定义可参见S103说明)的被占用资源Ro,相当于可以把Ri的“临时”的标签去掉,转换为能够参与正常的资源分配、不受周期性资源调度的限制的非临时闲置资源,而原本属于Ri的任务将“交接”给当前正在执行任务的Ro。只要Ro在未来按照正常的时间被释放,就能够及时接替原本属于R1的下一项任务。
在S103所描述的两个匹配条件中,条件a的对应的实际意义在于:Ro需要能够赶在Ri下一次被分配之前被释放;而条件b对应的实际意义在于:Ro需要有足够的能力承担原本属于Ri的任务。
在实际应用中,理想的情况是,对于临时闲置资源子集Ri,可以找到一个被占用子集Ro,使得Ro的剩余占用时长刚好等于Ri的剩余闲置时长、且Ro资源数量刚好等于Ri的资源数量;这种情况下,Ri与Ro在时间和资源数量方面完全匹配,理论上可以完全避免“临时闲置”的现象。可以理解的是,这里在时长上忽略了分配、释放等过程的时延,如果考虑上述处理时延,实际也可以将匹配条件设置为:Ro的剩余占用时略小于Ri的剩余闲置时长,即二者差的绝对值低于某个预设的阈值。
如果上述条件不容易满足,可以进一步配置一些次优的匹配策略,举例如下:
1)查找两个以上的当前被占用子集:Ro1、Ro2、……,要求同时满足如下匹配条件:
1.1)Ro1、Ro2、……的剩余占用时长均不大于Ri的剩余闲置时长;优选匹配条件仍然是“等于”,如果考虑分配处理时延则是“略小于”;
1.2)Ro1、Ro2、……的资源数量总和不小于Ri的资源数量;优选匹配条件仍然是“等于”。
2)对满足S103中匹配条件多个被占用子集Ro1、Ro2、……的剩余占用时长进行降序排列,优先选取剩余占用时长较高的被占用子集作为查找结果。
3)对S103中匹配条件多个被占用子集Ro1、Ro2、……的资源数量进行升序排列,优先选取资源数量较小的被占用子集作为查找结果。
可以看出,上述次优匹配策略的总体原则是:尽量缩小Ro从“被释放”到“代替Ri被分配”之间的时长、并且尽量使得Ro的资源能够被全部利用(当然,未被利用的Ro资源也可以转换为非临时闲置资源,本申请不再做进一步描述),从而降低资源的临时闲置率。在上述原则下,本领域技术人员还可以灵活设计其他匹配策略,从而衍生出更多的匹配策略,例如可以将上述的匹配策略结合使用,本申请对此并不需要进行限定。
下面结合一些具体的应用场景,对本申请方案进行说明:
实施例1:
在一个定时任务系统中,应用程序A需要在每个整点的第1~10分钟运行、应用程序B需要在每个整点的第6~15分钟运行、应用程序C需要在每个整点的第11~20分钟运行,3个应用程序运行均需要5个处理线程。由于A和C的运行时段完全错开,而且A和C运行均所需线程数相同,因此可以设置A与C复用相同的处理线程。以下为线程资源的初始化调度流程:
·第1分钟开始:
将5个处理线程分配给应用程序A,跟据A的运行规律得知:有3个线程将在第5分钟结束时释放、2个线程将在第10分钟结束时释放,可以将已分配给应用程序A的5个处理线程划分为两个子集,如表1.1所示:
子集编号 |
资源数量 |
剩余占用时长 |
A1 |
3 |
5分钟 |
A2 |
2 |
10分钟 |
表1.1
其中,表1.1中的“剩余占用时长”是是会随着时间的推移而动态减小的。当某个资源子集的“剩余占用时长”变为0时,意味着对应的资源将被释放。
·第5分钟结束(第6分钟开始):
首先,A1将被释放,根据调度计划,A1将在第10分钟再次被分配给应用程序C,因此A1成为临时闲置子集,此时系统的临时闲置子集如表1.2所示:
子集编号 |
资源数量 |
剩余闲置时长 |
A1 |
3 |
5分钟 |
表1.2
此时应用程序A占用的线程情况更新如表1.3所示:
子集编号 |
资源数量 |
剩余占用时长 |
A2 |
2 |
5分钟 |
表1.3
另一方面,在第6分钟开始,将5个处理线程分配给应用程序B,跟据B的运行规律得知:有3个线程将在第10分钟结束时释放、2个线程将在第15分钟结束时释放,则可以将已分配给应用程序B的5个处理线程划分为两个子集,如表1.4所示:
子集编号 |
资源数量 |
剩余占用时长 |
B1 |
3 |
5分钟 |
B2 |
2 |
10分钟 |
表1.4
此时,对于临时闲置子集A1,可以找到B1满足前述的“匹配条件”:B1剩余占用时长不大于A1的剩余闲置时长、B1和A1的资源数量相等,且B1和A1分别属于不同的集合。因此可以对A1和B1进行功能替换。替换之后,A1就成为了非临时闲置资源,可以参与正常的资源分配、不受周期性资源调度的限制。
·第10分钟结束(第11分钟开始):
A2和B1均被释放,由于之前的替换操作,此时原本分配方案“将A1+A2分配给应用程序C”变为“将B1+A2分配给应用程序C”。
B1+A2分配给应用程序C,又形成了一份新的资源集合,如果应用程序C也具有固定的线程释放规律,则再次统计该集合内各子集的剩余占用时长。
实施例2:
在综合业务系统中,不同的服务器业务数据的更新时间点和更新周期不同,而且业务数据刚刚更新后,业务服务器的访问量比较大,需要对访问侧提供较高的访问带宽,随着时间的推移,访问量逐渐减小,相应也地也可以逐渐减小对访问侧提供的访问带宽。
基于上述基本需求,假设在一个业务系统中,包含需要定期分配访问带宽资源的服务A、B、C。
服务器A在每天的0点和12点更新业务数据,在更新时间点需要为其分配访问带宽300M,每过4小时回收100M,直到下一个更新时间点重新将其访问带宽恢复至300M。
服务器B在每天的4点和16点更新业务数据,在更新时间点需要为其分配访问带宽150M,每过4小时回收50M,直到下一个更新时间点重新将其访问带宽恢复至150M。
服务器C在每天的4点和16点更新业务数据,在更新时间点需要为其分配访问带宽150M,每过4小时回收50M,直到下一个更新时间点重新将其访问带宽恢复至150M。
因此可以设置A与C复用相同的处理访问带宽。以下为访问带宽资源的初始化调度流程:
·0点钟:
将300M访问带宽分配给服务器A,跟据A的运行规律得知:分别有100M访问带宽将在4小时后释放、100M访问带宽将在8小时后释放,100M访问带宽将在12小时后释放(实际等效于不释放,为统一标识可视为释放后立即分配),可以将已分配给服务器A的300M访问带宽划分为3个子集,如表2.1所示:
子集编号 |
资源数量 |
剩余占用时长 |
A1 |
100M |
4小时 |
A2 |
100M |
8小时 |
A3 |
100M |
12小时 |
表2.1
其中,表2.1中的“剩余占用时长”是是会随着时间的推移而动态减小的。当某个资源子集的“剩余占用时长”变为0时,意味着对应的资源将被释放。
·4点钟:
首先,A1将被释放,根据调度计划,A1将在第12点再次被分配给服务器A,因此A1成为临时闲置子集,此时系统的临时闲置子集如表2.2所示:
子集编号 |
资源数量 |
剩余闲置时长 |
A1 |
100M |
8小时 |
表2.2
此时服务器A占用的访问带宽情况更新如表2.3所示:
子集编号 |
资源数量 |
剩余占用时长 |
A2 |
100M |
4小时 |
A3 |
100M |
8小时 |
表2.3
另一方面,将150M访问带宽分配给服务器B、将150M访问带宽分配给服务器C。跟据B和C的运行规律,可以分别将已分配给服务器B的150M访问带宽划分为3个子集、将已分配给服务器C的150M访问带宽划分为3个子集,如表2.4和2.5所示:
子集编号 |
资源数量 |
剩余占用时长 |
B1 |
50M |
4小时 |
B2 |
50M |
8小时 |
B3 |
50M |
12小时 |
表2.4
子集编号 |
资源数量 |
剩余占用时长 |
C1 |
50M |
4小时 |
C2 |
50M |
8小时 |
C3 |
50M |
12小时 |
表2.5
此时,对于临时闲置子集A1,从当前其他集合的被占用子集B1、B2、C1、C2中,无法找到单独一个子集满足与A1的匹配条件,原因是对应的资源数量不同。但是任意两个资源的组合可以满足与A1的匹配条件,为了便于管理,优先选择剩余占用时长相同的子集进行组合,结果包括:(B1+C1)和(B2+C2),进一步根据“优先选取剩余占用时长较高的被占用子集作为查找结果”,最终选取的结果为(B2+C2)。此时可以对A1和(B2+C2)进行功能替换。替换之后,A1就成为了非临时闲置资源,可以参与正常的资源分配、不受周期性资源调度的限制。
·8点钟:
A2、B1、C1被释放,成为闲置子集;其中A2的剩余闲置时长为4小时、B1、C1的剩余闲置时长为8小时。根据本实施例假设条件的限制,当前对A2、B1、C1均无法找到匹配的可替换资源子集,但是在实际应用中,很可能还有其他服务器可以提供可替换的资源子集,本实施例中不再做扩展描述。
·12点钟:
需要重新分配300M资源给服务器A,根据之前的替换操作,此时原本分配方案“将A1+A2+A3分配给服务器A”变为“将(C2+B2)+A2+A3分配给服务器A,并且又形成了一份新的资源集合。
实施例3:
本申请方案还可以应用在金融资源配置中,以降低资金的闲置率。以借贷业务为例,假设存在借贷关系的贷方x和借方y:在1月1日,x向y发放了一笔总额为12000元、期限为3个月的贷款,偿还方式为分3期按月偿还。放贷成功之后,x相应拥有了一笔总额为12000元、期限为3个月债权。为了尽快获得收益,x很快将这笔债权以资产转让的形式卖给z(实际交易价格可以在贷款本息总和上下一定范围内浮动,与本申请方案无关),并约定x在3个月期满后将本息一并结算给z。
如果不考虑逾期等非正常因素,x将在2月1日、3月1日,4月1日分别收到3笔来自y的还款现金。对于x而言:一方面,每次收到的还款现金实际是归z所有,因此并不能自由调配;另一方面,由于x与z的约定是3个月到期后一次性清算,因此前几个月收到的来自y的还款现金,在最后结算日之前,实际上一直处于闲置状态。
可见,在上述业务中,x在前几个月收到的来自y的还款现金,完全符合本申请中所描述的“临时闲置资源”,而对于“资金”这种资源而言,还有一个重要的特点:闲置资金无法获得收益,只有通过贷款、投资等方式,才能令资金不断增值。
为了避免资金闲置,一种容易想到的方案是:在每次收到分期还款现金后,利用这笔现金再次发放一笔新的、较短期的贷款。例如,理想的情况是:x在2月1日收到来自y的第一期还款(假设总额为4200元)后,立即再发放一笔总额为4200元、期限为2个月的贷款。但是实际上很难恰好碰到这样完全匹配的贷款需求,因此即便能够成功发放一笔短期贷款,往往也是额度、期限等多方面经过调整后的结果。资金的临时闲置仍然无法避免。
而应用本身申请所提供的资源调度方案,则可以有效地解决上述问题。
首先,在实际应用中,作为资源的调度方,贷方x应具有若干款金融产品,而在不同的时间点、不同的借方y1、y2、y3……总会从这些金融产品选择适合自己需要的产品,并且一定会按照产品协议来分期向x归还资金。基于这样的应用场景,可以将x发放的每一笔贷款视为一个资源集合,根据还款计划,将每次还款对应的现金流视为一个资源子集。
针对已分配的任意集合,确定该集合内各子集的剩余占用时长;
接收到已释放的任意子集、并确定该子集内的资源为临时闲置资源后,确定该闲置子集的剩余闲置时长;
在已分配且未释放的其他集合中,查找与所述闲置子集相匹配的当前被占用子集;其中,所述其他集合,与所述闲置子集所属的集合为不同集合;所述匹配为:被占用子集的剩余占用时长不大于所述闲置子集的剩余闲置时长、且被占用子集的资源数量不小于所述闲置子集的资源数量;
利用所查找到的被占用子集对所述闲置子集进行功能替换,并将所述闲置子集内的资源标识为非临时闲置资源;所述功能替换为:对资源分配计划进行更新,针对原本需要所述闲置子集资源承载的资源分配操作,将其承载对象修改为所查找到被占用子集的资源。相应的资金调配方法如下:
每发放一笔贷款后,根据还款计划,确定每笔现金流的归还时间。
每收到一笔分期还款现金流Ri后,确定该笔现金流的剩余闲置时长。然后在所有的其他笔已发放贷款中,查找与该笔已还款现金流Ri相匹配(匹配的定义可参见前面实施例的介绍,这里不再赘述)的未还款现金流Ro。查找成功后,对Ri和Ro进行功能替换,替换后Ri对应的现金流成为完全闲置资金,可以在不受限的情况下,以任何形式(例如投资、房贷)继续生息。而到最终结算期时,Ro也已经成为已还款现金流,将代替Ri所对应的现金流参与最终结算。
下面结合实例进行说明:
假设银行x向个人用户提供年利率为18%、期限为3个月、偿还方式为分3期按月“等额本息”的贷款产品。并且有大量用户“使用”该产品。
·2015年1月1日:
x向用户y1发放了一笔总额为12000、年利率为18%、期限为3个月的贷款,偿还方式为分3期按月“等额本息”偿还。还款计划如表3.1所示:
还款日期 |
月还款总额 |
本金 |
利息 |
2015/2/1 |
4120.60 |
3940.60 |
180.00 |
2015/3/1 |
4120.60 |
3999.70 |
120.89 |
2015/4/1 |
4120.60 |
4059.70 |
60.90 |
表3.1
贷款发放成功后,x将债权转让给z1,结算日期为2015年4月1日。那么对于上一笔已发放贷款,可以根据还款计划切分为3笔现金流,视为3个资源子集,如表3.2所示:
子集编号 |
资源数量 |
距还款日剩余 |
1.1 |
4120.60 |
1个月(近似) |
1.2 |
4120.60 |
2个月(近似) |
1.3 |
4120.60 |
3个月(近似) |
表3.2
为方便对方案进行说明,表3.2中的“距还款日剩余”以整月为单位近似表示,在实际应用中可以采用更为精确的统计方法,这并不影响本申请方案的实现。
·2015年2月1日:
x收到来自y1的第一笔还款,金额为4120.60元。该笔现金实际属于已被转让资产,需要在2015年4月1日结算给z1,因此该笔现金成为临时闲置子集,此时临时闲置子集如表3.3所示:
子集编号 |
资源数量 |
剩余闲置时长 |
1.1 |
4120.60 |
2个月(近似) |
表3.3
而此时y1未偿还的金额情况更新如表3.4所示:
子集编号 |
资源数量 |
距还款日剩余 |
1.2 |
4120.60 |
1个月(近似) |
1.3 |
4120.60 |
2个月(近似) |
表3.4
例如,假设此时刚好有用户y2向x借了一笔总额为12000、年利率为18%、期限为3个月的贷款,偿还方式为分3期按月“等额本息”偿还。对于该笔已发放贷款,可以根据还款计划切分为3笔现金流,视为3个资源子集,如表3.5所示:
子集编号 |
资源数量 |
距还款日剩余 |
2.1 |
4120.60 |
1个月(近似) |
2.2 |
4120.60 |
2个月(近似) |
2.3 |
4120.60 |
3个月(近似) |
表3.5
此时,对于临时闲置子集1.1,可以找到子集2.2满足匹配条件,因此利用子集2.2与子集1.1进行功能替换,替换完成后,1.1所对应的4120.60元现金流成为完全闲置资金,可以在不受限的情况下,以任何形式(例如投资、房贷)继续生息。
需要说明的是,上述“刚好有用户y2向x借贷款”的情形,仅是为了便于说明方案的一种举例。事实上,由于x的贷款是长期对外提供,且有大量用户“使用”该产品,因此,即便没有上述“刚好”的情形,也仍然有很大的可能在已经发放的其他笔贷款中,找到与子集1.1相匹配的子集,将查找结果与子集1.1进行功能替换。因此上述情形不应理解为对本申请方案的限制。
·2015年3月1日:
x收到来自y1的第二笔还款,金额为4120.60元。该笔现金实际属于已被转让资产,需要在2015年4月1日结算给z1,因此该笔现金成为临时闲置子集,此时临时闲置子集如表3.6所示:
子集编号 |
资源数量 |
剩余闲置时长 |
1.2 |
4120.60 |
1个月(近似) |
表3.6
而此时y1未偿还的金额情况更新如表3.7所示:
子集编号 |
资源数量 |
距还款日剩余 |
1.3 |
4120.60 |
1个月(近似) |
表3.7
为方便说明,这里仍然假设此时刚好有用户y3向x借了一笔总额为12000、年利率为18%、期限为3个月的贷款,偿还方式为分3期按月“等额本息”偿还。对于该笔已发放贷款,可以根据还款计划切分为3笔现金流,视为3个资源子集,如表3.8所示:
子集编号 |
资源数量 |
距还款日剩余 |
3.1 |
4120.60 |
1个月(近似) |
3.2 |
4120.60 |
2个月(近似) |
3.3 |
4120.60 |
3个月(近似) |
表3.8
此时,对于临时闲置子集1.2,可以找到子集3.1满足匹配条件,因此利用子集3.1与子集1.2进行功能替换,替换完成后,1.2所对应的4120.60元现金流成为完全闲置资金,可以在不受限的情况下,以任何形式继续生息。
·2015年4月1日:
x收到来自y1的第三笔还款,金额为4120.60元。此时x与z1的资产转让结算日已到。另外按照y2和y3的还款计划,此时子集2.2和子集3.3对应的还款现金流刚好到账,根据之前的两次替换结果,x将利用子集2.2(用于替换1.1)、子集3.1(用于替换1.2)和子集1.3所对应的现金流与z1进行结算。
可见,应用本申请方案,通过对资产进行切分、重组,突破了资金期限的约束。只要一笔转让资产在分配期内,发生至少两次还款行为,例如等额本金贷款、等额本息贷款、信用卡分期还款等,均可以应用本申请方案将每次收到的还款现金转换为完全闲置资金,从而使得这部分资金可以在不受期限约束的情况下,继续投入使用。并且,通过在多笔资产之间进行相互调度转换,理论上可以将资金闲置率压缩至0。
相应于上述方法实施例,本申请还提供一种资源调度装置,参见图2所示,该装置可以包括:
占用时长确定模块110,用于针对已分配的任意集合,确定该集合内各子集的剩余占用时长;
闲置时长确定模块120,用于在接收到已释放的任意子集、并确定该子集内的资源为临时闲置资源后,确定该闲置子集的剩余闲置时长;
查找模块130,用于在已分配且未释放的其他集合中,查找与闲置子集相匹配的当前被占用子集;匹配为:被占用子集的剩余占用时长不大于闲置子集的剩余闲置时长、且被占用子集的资源数量不小于闲置子集的资源数量;
替换模块140,用于利用所查找到的被占用子集对闲置子集进行功能替换,并将闲置子集内的资源标识为非临时闲置资源;功能替换为:对资源分配计划进行更新,针对原本需要闲置子集资源承载的资源分配操作,将其承载对象修改为所查找到被占用子集的资源。
在本申请的一种具体实施方式中,查找模块140可以具体用于:
查找两个以上的当前被占用子集;
两个以上当前被占用子集的剩余占用时长均不大于闲置子集的剩余闲置时长、且两个以上被占用子集的资源数量总和不小于闲置子集的资源数量。
在本申请的一种具体实施方式中,查找模块140可以具体用于:
查找满足以下条件的被占用子集:
被占用子集的剩余占用时长等于闲置子集的剩余闲置时长、
且被占用子集的资源数量等于闲置子集的资源数量。
在本申请的一种具体实施方式中,查找模块140可以具体用于:
对满足匹配条件的被占用子集的剩余占用时长进行降序排列,优先选取剩余占用时长较高的被占用子集作为查找结果。
在本申请的一种具体实施方式中,查找模块140可以具体用于:
对满足匹配条件的被占用子集的资源数量进行升序排列,优先选取资源数量较小的被占用子集作为查找结果。
本申请所提供的上述装置可以应用于个人电脑、手机、服务器等设备上,图3所示,为本申请所提供的用于配置上述装置的一种设备硬件结构示意图,该设备可以包括:处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本申请所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序,在通过软件或者固件来实现本申请所提供的技术方案时,相关的程序代码保存在存储器1020中,并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路,在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本申请方案所必需的组件,而不必包含图中所示的全部组件。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本申请的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。