[发明专利]一种网贷业务数据处理方法

说明书

本发明提供一种网贷业务数据处理方法，该方法使用Redis的Hashes结构实现网贷业务处理，不需要锁定整个业务流程，在还款分配、逾期分配和转让债权的业务流程开始时判断是否可以获取锁，并调用Redis的Hashes数据结构进行加锁运算操作；在业务流程结束时调用Redis的Hashes数据结构进行数据删除的解锁运算操作，从而降低了工作量，实现了运算、判断和锁定时间短以及效率高的技术效果。另外，该方法还实现了转让债权和转让债权业务在借款申请ID相同和债权ID不同的情况下的并发而其他业务场景均不能并发，并且解决了同一个借款申请下的不同债权不能同时进行业务处理的问题，从而极大地提升了业务效率。

技术领域

本发明涉及数据处理技术领域，尤其涉及一种网贷业务数据处理方法。

背景技术

在网贷业务发展初期，公司经历了野蛮增长、快速抢占市场的阶段。在这个阶段，所有业务都致力于快速实现。债权数据处于网贷最底层，也是最核心的数据，几乎所有业务流程都会对债权数据进行运算、更新。对于业务流程并发导致的数据一致性问题，传统技术方案采取相对简单且可实现分布式的关系型数据库悲观锁for update方式。在查询到一条债权数据的同时，对债权数据进行加锁，其他业务对该数据的增、删、改、查都需要等待，直到该业务计算和更新完成后，才会允许下一个业务对该条债权数据进行操作。

然而，随着客户量、债权数据量、业务量的增大，出现了两方面的问题。首先，由于业务量增大，等待锁来操作债权数据的数据库连接越来越多，数据库压力越来越大，业务高峰期甚至出现数据库宕机的情况。另外，基于数据库悲观锁的特性，同一个债权数据操作为顺序执行，大大降低了业务执行的效率，业务执行时间越来越长。基于上述问题，业务系统拆分、系统服务化和优化迫在眉睫。在这些工作进行期间，还款分配、逾期分配和转让债权等业务，依赖时间差来尽量避免业务并发出现的数据一致性问题。但由于庞大的业务量导致执行时间很长，仍然会有并发的情况出现。

随着微服务架构中的服务注册和发现的搭建，业务系统逐渐拆分为各个微服务，数据库悲观锁也升级为分布式锁。分布式锁目前比较常用的有基于Zookeeper实现的分布式锁和基于缓存(Redis)实现的分布式锁。

其中，使用Zookeeper技术上是基于Zookeeper临时有序节点实现的分布式锁。每个客户端对某个方法加锁时，在Zookeeper上与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。这种方式可以避免因服务宕机导致锁无法释放而产生的死锁问题。但是，Zookeeper实现的分布式锁存在效率不高的缺点。

另外，Redisson是一种基于缓存Redis的分布式锁，效率高，可以在锁定范围内进行防止并发的内存运算。但是，基于Redis技术的Redisson分布式锁在使用过程中主要存在以下两个方面的缺陷：

1.业务流程存在多次更新和复杂内存运算的时候，需要锁定整个业务流程，锁定时间长，过期时间不好确定。

2.Redisson分布式锁一般是锁定唯一的元素，而在网贷的还款分配、逾期分配和转让债权三个业务流程并发控制中，这种简单的分布式锁就不能实现对其并发的控制。

基于上述问题，使得简单的分布式锁不能实现网贷的该类业务场景。如图1所示，借款申请和债权数据是一对多的关系。一个借款申请下会有多个债权数据。

如图2所示，虽然还款分配、逾期分配和转让债权最终操作的都是债权数据，但还款分配和逾期分配业务流程基于借款申请，复杂运算后会更新借款申请下所有的债权数据。

如图3所示，转让债权业务流程基于债权数据，业务运算后会更新转出债权数据，并生成新的转入债权数据。