CN110716948B

CN110716948B - 一种基于数据定期处理的双锁控制方法及介质

Info

Publication number: CN110716948B
Application number: CN201911273810.3A
Authority: CN
Inventors: 张鹤鸣; 黄海城; 王倩
Original assignee: Sichuan XW Bank Co Ltd
Current assignee: Sichuan XW Bank Co Ltd
Priority date: 2019-12-12
Filing date: 2019-12-12
Publication date: 2020-04-14
Anticipated expiration: 2039-12-12
Also published as: CN110716948A

Abstract

本发明公开了一种基于数据定期处理的双锁控制方法及介质，属于软件信息领域。解决现有技术中，在大数据量的请求中，会加重系统的负载、加重内存资源的消耗、降低系统处理速度问题。本发明在数据定期处理场景中，用户端向系统申请定期处理业务，当系统内产生各项定期处理业务的信息数据时，对各项定期处理业务加上当前业务期间的控制锁和下一业务期间的控制锁；若系统发起切业务期间，或若系统接收到用户端的定期处理请求，基于控制锁对业务期间的定期批量任务处理或对用户的请求进行处理。本发明用于控制数据定期处理。

Description

一种基于数据定期处理的双锁控制方法及介质

技术领域

一种基于数据定期处理的双锁控制方法及介质，用于控制数据定期处理，属于软件信息领域。

背景技术

在数据定期处理场景中，现有技术存在如下问题：一、依赖关系型数据库，所以需要频繁的更新数据；二、在大数据量的请求中，会加重系统的负载、加重内存资源的消耗、降低系统处理速度，以及无法快速响应前端的要求，其中，数据日终处理场景包括消费信贷场景、借贷场景、存款场景和理财场景、借书场景、租赁场景等。

现就消费信贷系统中的数据日终处理进行说明，在消费信贷系统中，用户每次贷款成功后在系统中会生成一笔借据订单，该笔借据为用户本次借款的数据体现，用户本次贷款产生的还款计划数据，以及贷款周期内生成的账单、计提、还款、逾期等都会与该笔借据关联，即借据会串联用户贷款整个生命周期。

针对该笔借据用户可以发起多次还款，但是还款操作应该按照时间顺序有序执行，不可同步执行。在当前的技术方案中，当用户针对该笔借据发起一笔还款请求时，会对该笔借据加锁，此时若用户对该笔借据再次发起还款申请时，会因为已经加锁而返回不可发起还款，直到上一笔还款处理完毕后才会将锁解除，之后才会允许用户发起下一次还款。

消费信贷系统在T日日终时会进行日切，日切后系统业务期间由T日变为T+1日，然后系统会执行日终批量操作，批量操作包括对所有未结清的借据进行延滞处理，利息计提，罚息计提等操作。为了避免数据被修改而造成计算出错，在批量操作完成之前用户也不允许发起还款申请。在以借据维度执行批量流程的贷款系统中，当前技术方案为当借据开始执行批量任务时，对借据加锁，此时若有还款则会因为存在锁而被拒绝，直到该笔借据批量执行完成解除锁后才可以发起还款。但是借据初始化批量任务是需要一定时间的，在极端情况下，从日切到初始化该笔借据期间，若用户有还款操作，当前技术方案中的控制锁无法保证有效阻止还款操作。

若用户在T日日终发起一笔还款申请，此时发生业务期间日切至T+1日，批量任务处理系统会在上日还款未处理完成的情况开始执行批量任务处理，会导致账务数据出错，当前技术方案无法完全避免这种情况可能性的出现。另外有技术方案选择在T日23:50后不允许用户发起还款申请，该技术方案在一定程度上可以避免以上问题，但仍无法保证完全避免批量任务处理系统会在上日还款未处理完成的情况开始执行批量任务处理，而且对用户体验造成了很大影响，可能导致用户因无法及时还款导致贷款逾期。

综上所述，现有技术中的定期处理场景中，批量任务处理系统会在上日未处理完成的情况开始执行批量任务处理，不仅要依赖关系型数据库，频繁的更新数据；在大数据量的请求中，会加重系统的负载、加重内存资源的消耗、降低系统处理速度，以及无法快速响应前端的要求（即造成计算机内部性能降低），还对用户体验造成了很大影响，如产生信用问题等。

发明内容

针对上述研究的问题，本发明的目的在于提供一种基于数据定期处理的双锁控制方法及介质，解决现有技术中的定期处理场景中，批量任务处理系统会在上日未处理完成的情况开始执行批量任务处理，不仅要依赖关系型数据库，频繁的更新数据；在大数据量的请求中，会加重系统的负载、加重内存资源的消耗、降低系统处理速度，以及无法快速响应前端的要求（即造成计算机内部性能降低），还对用户体验造成了很大影响，如产生信用问题等。

为了达到上述目的，本发明采用如下技术方案：

一种基于数据定期处理的双锁控制方法，包括如下步骤：

S1、在数据定期处理场景中，用户端向系统申请定期处理业务，当系统内产生各项定期处理业务的信息数据时，对各项定期处理业务加上当前业务期间的控制锁和下一业务期间的控制锁；

S2、若系统发起切业务期间，即从当前业务期间切到下一业务期间，系统的批量任务处理链在接收到待执行的各项定期处理业务后，基于控制锁，对当前业务期间内的各项定期处理业务进行定期批量任务处理，处理后删除当前业务期间的控制锁，删除后用户端再基于定期批量任务处理结果请求处理，同时,若当前业务期间的控制锁不是最后一个业务期间的控制锁，基于当前业务期间加下一业务期间的控制锁，否则不加，其中，定期处理业务是指某项需要定期进行处理的业务，定期批量任务处理是指对某项定期处理业务的某个业务期间的结算数据合计处理；

S3、若系统接收到用户端的定期处理请求，判断是否有当前业务期间的控制锁，若有，系统反馈给用户端仍有未处理完成的定期处理请求，即系统内已接收到处理当前业务期间内定期批量任务处理结果的请求，否则，在接收到处理当前业务期间内定期批量任务处理结果的请求的同时加上当前业务期间的控制锁，防止再次重复处理当前业务期间内的数据，其中，处理当前业务期间内定期批量任务处理结果的请求是专指基于当前业务期间内定期批量任务处理结果，对当前业务期间进行业务结算。

进一步，所述业务期间为一日、一周、一月或一年。

进一步，所述步骤S1-步骤S3中，采用分布式缓存数据库Redis添加控制锁。

进一步，所述步骤S1中的定期处理场景包括消费信贷场景、借贷场景、存款场景、理财场景、借书场景或租赁场景；用户端向系统申请定期处理业务，当系统内产生各项定期处理业务的信息数据时，对各项定期处理业务加上当前业务期间的控制锁和下一业务期间的控制锁的具体步骤为：

S1.1、用户端向系统申请定期处理业务，系统内产生各项定期处理业务的信息数据，即系统对申请的请求处理正常的情况下，生成各项定期处理业务的信息数据，信息数据为各项定期处理业务的编号，其中，编号关联了相对应的定期处理业务中用于定期批量任务处理的信息；

S1.2、用户端向系统申请成功后，对申请成功的定期处理业务依次加锁前缀标识、编号、当前业务期间的控制锁，和依次加锁前缀标识、编号、下一业务期间的控制锁。

进一步，所述步骤S2的具体步骤为：

S2.1、若系统发起切业务期间，即从当前业务期间切至下一业务期间，下一业务期间变为当前业务期间；

S2.2、初始化待执行的各项定期处理业务的信息数据，初始化成功后，逐笔通过异步消息并发发送至批量任务处理链；

S2.3、批量任务处理链在接收到待执行的各项定期处理业务后，检查是否还有上一业务期间的控制锁，即判断在切业务期间过程中是否有用户已请求基于上一业务期间的批量任务处理结果请求处理或正在处理的情况，若有,判断是否是首日控制锁，若是，直接删除，若否，等待五分钟后，再次执行步骤S2.3，若没有，批量任务处理链处理当前业务期间内的各项定期处理业务，得到定期批量任务处理结果，处理后删除当前业务期间的控制锁，删除后用户再基于定期批量任务处理结果请求处理，同时,若当前业务期间的控制锁不是最后一个业务期间的控制锁，基于当前业务期间加下一业务期间的控制锁，否则不加，其中，定期处理业务是指某项需要定期进行处理的业务，定期批量任务处理是指对某项定期处理业务的某个业务期间的结算数据合计处理。

进一步，所述批量任务处理链是指针对某一业务期间内的各定期处理业务进行定期批量任务处理，为消费信贷场景中是否逾期的利息和罚息的计算、借贷场景中是否逾期的利息和罚息的计算、存款场景中利率变化引起的利息结算的计算、理财场景中利率变化引起的利息结算的计算或借书场景中是否逾期还书租金和滞纳金的计算或租赁场景中是否逾期还设备租金和滞纳金的计算。

一种基于数据定期处理的双锁控制介质，包括用于存储基于数据定期处理的双锁控制方法的硬盘磁盘。

本发明同现有技术相比，其有益效果表现在：

一、现有技术在极端场景下无法做到各期间内各数据（任务）的有效控制，从而导致数据处理错误，例如T日日终还款请求未处理完成时，T+1日批量任务处理即开始执行，或者从日切之后到批量开始执行前，用户有还款申请进入，导致系统账务处理出错，本申请提案可以通过控制锁避免出现该类问题。

二、现有技术会在日终前一段时间关闭用户还款通道，造成用户体验差，如用户因为错过还款时间而导致逾期会引起投诉，本申请提案的技术实现可以不需要关闭还款窗口，做到真正的7x24小时业务运行。

三、现有技术通过关系型数据库还款流水表的状态来控制，每次请求进入都需要查询数据库，而本申请提案的技术实现使用的是内存型非关系数据库Redis做分布式锁，适用于大流量高并发下的分布式系统，可以做到效率更快安全性更高。

四、本发明在系统层面上可以减少对关系型数据库的依赖，减少查询更新数据库的操作，在大数量下的请求中，可以明显降低系统的负载，降低内存资源消耗，提升系统处理速度，更快响应前端请求。

附图说明

图1是本发明中系统内产生各项定期处理业务的信息数据时，对各项业务加上当前业务期间的控制锁和下一业务期间的控制锁的示意图；

图2是本发明中系统发起切业务期间的处理示意图，其中，图中是排除了首日控制锁与第一个需要处理的业务期间的控制锁日切的情况，以及最后一个业务期间处理后不加下一个业务期间的控制锁的情况；

图3是本发明中系统接收到用户端的定期处理请求的处理示意图。

具体实施方式

下面将结合附图及具体实施方式对本发明作进一步的描述。

一种基于数据定期处理的双锁控制方法，包括如下步骤：

S1、在数据定期处理场景中，用户端向系统申请定期处理业务，当系统内产生各项定期处理业务的信息数据时，对各项定期处理业务加上当前业务期间的控制锁（即产生各项定期处理业务日时，加上的不需要处理定期处理业务的控制锁(即首日控制锁)，如贷款放款当日所产生的控制锁，这个控制锁并不会涉及到还款，后续的当前业务期间的控制锁则是指当前需要处理的业务期间对应的控制锁）和下一业务期间的控制锁（即第一个需要处理的业务期间对应的控制锁，后续的下一个业务期间的控制锁则是指下一个需要处理的业务期间对应的控制锁）；

进一步，所述业务期间为一日、一周、一月或一年。

进一步，所述步骤S2的具体步骤为：

实施例

本实施例以借据为维度进行日终批量账务处理，具体如下：

用户发起贷款申请，贷款系统处理正常，生成该次贷款的借据的编号，生成借据信息数据时，借据编号字段在贷款系统中是唯一不重复的编号字段，放款成功后，依次加锁前缀标识、编号、当前业务期间的控制锁，和依次加锁前缀标识、编号、下一业务期间的控制锁，例如锁前缀标识统一为REPAY，该笔借据编号为000000027957，当前业务期间为20190819，下一业务期间为20190820。即用户贷款成功后存在控制锁REPAY_000000027957_20190819和REPAY_000000027957_20190820，控制锁REPAY_000000027957_20190819为首日控制锁。

如图2所示，贷款系统发起切日，业务期间从20190819切至20190820；以借据维度的日终批量任务开始初始化待执行批量任务处理的借据的编号；初始化成功的各借据的编号逐笔通过异步消息并发发送至批量任务处理链；批量任务处理链在接收到单笔借据的编号后，检查上一日控制锁REPAY_000000027957_20190819是否存在；若上一日控制锁存在，判断是否是首日控制锁（因为放款当日，是不需要处理的），若是，直接删除，即上一日控制锁REPAY_000000027957_20190819为首日控制锁删除，若否，则该笔借据进入轮询队列，等待五分钟后，该笔借据再次检查上一日控制锁REPAY_000000027957_20190819是否存在（即检查是否处理完成，并在处理完成后删除相应的控制锁）；若上一日控制锁不存在，则正常开始执行批量任务处理，即贷款系统里期间加了一天，要计算各借据是否逾期了，利息应该增加多少，罚息应该增加多少等。批量任务正常执行完成后，删除当前业务期间控制锁REPAY_000000027957_20190820，删除后用户再基于定期批量任务处理结果请求处理，同时，若当前业务期间的控制锁不是最后一个业务期间的控制锁，基于当前业务期间加下一业务期间的控制锁加下一业务期间控制锁REPAY_000000027957_20190821，否则不加。

如图3所示，用户发起还款申请（即指定期处理请求或结算请求等）时，先以借据的编号及当前业务期间检查是否存在控制锁。例如前缀标识统一为REPAY，该笔借据编号为000000027957，当前业务期间为20190820，则检查是否存在控制锁REPAY_000000027957_20190820；

若已存在控制锁REPAY_000000027957_20190820，则直接反馈仍有未处理完成的还款请求，即系统内已接收到处理当前业务期间内定期批量任务处理结果的请求。

若不存在控制锁REPAY_000000027957_20190820，在接收到处理当前业务期间内定期批量任务处理结果的请求的同时加上当前业务期间的控制锁，则加上该控制锁REPAY_000000027957_20190820，防止再次重复处理当前业务期间内的数据，控制锁此时由于切日处理后，已加下一期间控制锁REPAY_000000027957_20190821，所以同一笔借据在同一时间会存在两把控制锁，因此该技术方案也叫双锁机制。加控制锁成功后，系统正常进行还款业务流程处理，即系统根据用户的请求，并基于批量任务处理结果实现还款。还款流程处理完成后，控制锁REPAY_000000027957_20190820删除。

按照上述流程，根据各个业务期间来完成切日或用户还款申请，直接各定期处理业务全部结算完为止。

以上仅是本发明众多具体应用范围中的代表性实施例，对本发明的保护范围不构成任何限制。凡采用变换或是等效替换而形成的技术方案，均落在本发明权利保护范围之内。

Claims

1.一种基于数据定期处理的双锁控制方法，其特征在于，包括如下步骤：

2.根据权利要求1所述的一种基于数据定期处理的双锁控制方法，其特征在于，所述业务期间为一日、一周、一月或一年。

3.根据权利要求2所述的一种基于数据定期处理的双锁控制方法，其特征在于，所述步骤S1-步骤S3中，采用分布式缓存数据库Redis添加控制锁。

4.根据权利要求2或3所述的一种基于数据定期处理的双锁控制方法，其特征在于，所述步骤S1中的定期处理场景包括消费信贷场景、借贷场景、存款场景、理财场景、借书场景或租赁场景；用户端向系统申请定期处理业务，当系统内产生各项定期处理业务的信息数据时，对各项定期处理业务加上当前业务期间的控制锁和下一业务期间的控制锁的具体步骤为：

5.根据权利要求4所述的一种基于数据定期处理的双锁控制方法，其特征在于，所述步骤S2的具体步骤为：

6.根据权利要求5所述的一种基于数据定期处理的双锁控制方法，其特征在于，所述批量任务处理链是指针对某一业务期间内的各定期处理业务进行定期批量任务处理，为消费信贷场景中是否逾期的利息和罚息的计算、借贷场景中是否逾期的利息和罚息的计算、存款场景中利率变化引起的利息结算的计算、理财场景中利率变化引起的利息结算的计算或借书场景中是否逾期还书租金和滞纳金的计算或租赁场景中是否逾期还设备租金和滞纳金的计算。

7.一种基于数据定期处理的双锁控制介质，其特征在于：包括用于存储权利要求1-6任意一项的硬盘磁盘。