CN112688799A - 基于Redis集群的客户号分配方法以及分配装置 - Google Patents

Abstract

本申请实施例提供一种基于Redis集群的客户号分配方法以及分配装置，方法包括：获取客户号分配请求和基础信息；根据所述基础信息查询是否存在对应的所述客户号；在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；在加锁成功后生成设定位数的自增序列；输出包含所述自增序列的客户号。在上述客户号分配方法中，将Redis集群原子操作及分布式锁应用于唯一客户号的分配，通过唯一客户号分配的互斥避免并发分配请求操作，从而保证客户号分配的唯一性；而且基于Redis集群，能够实现各节点之间的共享及同步，保证了客户号的一致性以及服务的高可用性。

Description

基于Redis集群的客户号分配方法以及分配装置

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种基于redis集群的客户号分配方法以及生成装置。

背景技术

保险、电商以及物流等服务行业都会有相应的客户管理系统，用于存储和管理与客户相关的数据信息。随着数据量的剧增，“以客户为中心”已经成为服务行业中客户管理系统数据管理的普遍设计思路，因此用于表示客户身份的客户号变得至关重要。

由于商业模式、渠道结构和IT系统建设等原因，客户信息通常分散在多个地方，由不同的IT系统分别创建。然而各个IT系统的业务范围、建设时间、处理逻辑与系统质量等一般会存在差异，因此很难实现客户的唯一识别；另外，由于客户信息分散在各个IT系统中，缺乏客户信息更新后的共享及同步机制，各个IT系统之间的客户信息存在不一致的情况，也导致了无法满足客户号的唯一性要求。

因此，现有的客户管理系统缺乏统一的客户编号或索引，真正做到“以客户为中心”存在很大困难。

发明内容

本申请实施例的目的在于提供一种基于Redis集群的客户号分配方法以及分配装置，以解决现有技术中客户号分配无法满足唯一性要求的问题。

基于上述目的，第一方面，本申请实施例提供一种基于Redis集群的客户号分配方法，包括：

获取客户号分配请求和基础信息；

根据所述基础信息查询是否存在对应的所述客户号；

在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；

在加锁成功后生成设定位数的自增序列；

输出包含所述自增序列的客户号。

在上述客户号分配方法中，将Redis集群原子操作及分布式锁应用于唯一客户号的分配，通过唯一客户号分配的互斥避免并发分配请求操作，从而保证客户号分配的唯一性；而且基于Redis集群，能够实现各节点之间的共享及同步，保证了客户号的一致性以及服务的高可用性。

在一种可能的实施方式中，所述利用Redis分布式锁对所述基础信息加锁，包括：

获取当前时间；

按顺序依次向N个Redis节点执行获取锁的操作；

计算总共消耗时间；

根据总共消耗时间是否超过锁有效时间，以及是否从大多数Redis节点获取锁成功，判断加锁是否成功。

在一种可能的实施方式中，所述获取锁的操作，包括：

发送获取锁指令，所述获取锁指令包括所述基础信息、随机字符串和锁有效时间；

在所述基础信息存在时，获取锁失败。

在一种可能的实施方式中，所述利用Redis分布式锁对所述基础信息加锁之后，还包括：

在加锁失败后的设定时间后，重新执行所述客户号分配方法。

在一种可能的实施方式中，所述生成设定位数的自增序列，包括：

利用Redis Incr命令生成设定位数的自增序列。

在一种可能的实施方式中，所述在加锁成功后生成设定位数的自增序列，包括：

在加锁成功后查询是否存在对应的所述客户号；

在所述客户号不存在时，利用Redis Incr命令生成设定位数的自增序列。

在一种可能的实施方式中，还包括：

利用数据库记录当前客户号的最大可用值；

在Redis集群出现问题重启后，从数据库加载最大可用值，继续进行客户号分配。

在一种可能的实施方式中，所述客户号为身份标识号、交易订单号、物流单号或产品序列号。

在一种可能的实施方式中，所述客户号为保险行业的身份标识号；

对于证件类型为身份证的客户，所述客户号为身份证前6位+开户年份+自增序列；

对于证件类型为非身份证的客户，所述客户号为100100+开户年份+自增序列。

第二方面，本申请实施例提供了一种基于redis集群的客户号分配装置，包括：

获取模块，被配置为获取客户号分配请求和基础信息；

查询模块，被配置为根据所述基础信息查询是否存在对应的所述客户号；

加锁模块，被配置为在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；

分配模块，被配置为在加锁成功后生成设定位数的自增序列；

输出模块，被配置为输出包含所述自增序列的客户号。

本实施例的装置可以用于执行第一方面实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种基于Redis集群的客户号分配方法流程图一；

图2为本申请实施例提供的一种基于Redis集群的客户号分配方法流程图二；

图3为本申请实施例提供的一种基于Redis集群的客户号分配装置的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种基于Redis集群的客户号分配方法，客户号是表示某条数据的身份代码，实现数据的识别，广泛应用于数据管理系统。客户号可以用于指向某个具体的用户，也可以用于指向某项具体交易，还可以用于指向某个具体的产品。

例如，在保险行业，客户号可以为保单号和客户的身份标识号(ID)；在电商行业中，客户号可以为交易订单号；在物流行业中，客户号可以为物流单号；在制作行业中产品相应的产品序列号等。针对不同领域、不同的应用场景，客户号具有不同的含义，指向不同的对象，此处不一一列举。

为了能够准确地表示相应的对象，客户号应具有唯一性。

本申请实施例的客户号分配方法通过Redis集群(Redis Cluster)实现，其中，Redis Cluster是由多个Redis实例组成，采用无中心结构，包括主节点和从节点。每个节点保存数据和整个集群状态，每个节点均和其他节点相连，主节点提供数据存取，从节点则从主节点拉取数据备份，保证数据高可用性。

Redis Cluster是中Redis实例的数目可以根据应用场景设定，以6个Redis实例，采用三主三从集群部署模式，即3个为主节点，3个为从节点。一旦有主节点发生故障的时候，Redis Cluster可以选举出对应的从节点成为新的主节点，继续对外服务，从而保证服务的高可用性。

而且，采用Redis Cluster能够将客户号分配从各种具体的IT系统中分离出来，以独立于原有IT系统，保证分配逻辑和客户号质量的统一。

如图1所示，该基于Redis集群的客户号分配方法包括：

步骤S10：获取客户号分配请求和基础信息；

在请求分配客户号时，需要基于某些已有的数据信息发送客户号分配请求，此处已有的信息即基础信息。基础信息的具体项目通常为根据应用场景预先设定的项目。例如在保险服务商请求分配客户号时，基础信息通常为“五要素”信息，即姓名、性别、出生日期、证件号与证件类型。在物流服务商请求分配物流单号时，基础信息通常包括寄件时间、寄件类型、收发地址与收发人联系方式等。在电商服务商请求分配交易订单号时，基础信息通常包括交易时间、交易内容与客户信息等。

针对不同行业、不同应用场景的基础信息存在差异，此处不一一列举。

步骤S20：根据所述基础信息查询是否存在对应的所述客户号；

为了避免重复分配，需先根据基础信息查询与该基础信息对应的客户号是否已经存在，对于客户号已经存在的情形，客户号分配终止。可选的，在检测到已有对应客户号时，可以根据实际情况对基础信息进行更新。例如，经过对比发现，虽然已有客户号与该基础信息指向同一对象，但是基础信息的某些项目发生了改变，可对该改变的项目进行更新，如手机号码、地址等。

步骤S30：在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；

如果未查询到相关的客户号，可继续执行客户号分配步骤。为了保证客户号分配的唯一性，避免对同一分配请求进行重复分配，应在分配时仅允许对一条基础信息进行分配操作，也就是说，需要在不同进程互斥地访问共享资源，此种情形下分布式锁是一种非常有效的技术手段，Redis集群是实现分布式锁非常有效的技术手段。

因此在进行客户号分配时，对基础信息借助Redis分布式锁加锁，待客户号分配成功后进行锁释放。

步骤S40：在加锁成功后生成设定位数的自增序列；

获取锁成功后，即表明对基础信息加锁成功，可进入客户号分配步骤，利用相应命令生成设定位数的自增序列，具体位数可以根据实际确定。

在一种可能的实施方式中，自增序列设定为8位，位数不足前边补0。每年自增序列从1开始，使用INCR进行累加；Redis Incr命令将key中储存的数字值增一，如果key不存在，那么key的值会先被初始化为0，然后再执行INCR操作；如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误。

在自增序列生成完毕后进行锁释放。

步骤S50：输出包含所述自增序列的客户。

自增序列可以直接被用作客户号进行输出。在可能的实施方式中，客户号通常还应具有一定的含义，体现一些基本的属性，实现一定的可读性，例如客户号可以包含时间信息、位置信息以及身份信息等。

在上述客户号分配方法中，将Redis集群原子操作及分布式锁应用于唯一客户号的分配，通过唯一客户号分配的互斥避免并发分配请求操作，从而保证客户号分配的唯一性；而且基于Redis集群，能够实现各节点之间的共享及同步，保证了客户号的一致性以及服务的高可用性。

以保险服务商中的客户号为例，客户号的命名规则为：

对于证件为身份证的客户，客户号为：身份证前6位+开户年份+8位自增序列(位数不足前边补0)；对于证件为非身份证的客户，客户号为：100100+开户年份+8位自增序列(位数不足前边补0)。

根据上述规则可以看出，利用上述步骤得到的自增序列可以保证客户号的唯一性，并且结合上述规则，可以方便地得出客户的地域信息、开户时间，从而方便客户信息的管理。

可选的，如图2所示，步骤S30包括：

步骤S301：获取当前时间；

步骤S302：按顺序依次向N个Redis节点执行获取锁的操作；

N即Redis集群中的节点数，向1个Redis节点执行获取锁的操作与基于单机Redis获取锁的过程相同，基于单机Redis获取锁的过程：

向Redis发送获取锁指令，获取锁指令包括基础信息、随机字符串(my_random_value)，以及锁有效时间。在基础信息存在时，获取锁失败。

其中随机字符串是由客户端生成的一个随机字符串，它要保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的，并且，可以在释放锁时，通过对比随机字符串，保证一个客户端释放的锁是该客户端持有的锁，避免可能出现的是否非自己持有锁的情形，从而避免锁不安全的情况。

锁有效时间的设置用于保证即使锁没有被显式释放，锁也可以在锁有效时间后自动释放，避免资源被永远锁住。

为了保证在某个Redis节点不可用的时候算法能够继续运行，该步骤中获取锁的操作还包含有超时时间，超时时间要远小于锁有效时间。客户端在向某个Redis节点获取锁失败以后，应该立即尝试下一个Redis节点。

步骤S303：计算总共消耗时间；

计算方法是用当前时间减去步骤S101记录的时间。

步骤S304：根据总共消耗时间是否超过锁有效时间，以及是否从大多数Redis节点获取锁成功，判断加锁是否成功。

如果客户端从大多数Redis节点成功获取锁，并且获取锁总共消耗的时间没有超过锁有效时间，那么认为最终获取锁成功；如果客户端并非在大多数Redis节点成功获取锁，或者或者整个获取锁的过程总共消耗时间超过锁有效时间；则认为最终获取锁失败。

此处大多数是指至少为N/2+1。

如果最终加锁成功，锁有效时间应该重新计算，它等于最初的锁有效时间减去第3步计算出来的获取总共锁消耗时间。

另外，如果最终获取锁失败，客户端应该立即向所有Redis节点发起释放锁的操作。

为了避免在获取锁的过程中客户号分配完成，导致重复分配，步骤S40包括：

在加锁成功后查询是否存在对应的所述客户号；

在所述客户号不存在时，利用Redis Incr命令生成设定位数的自增序列。

在一种可能的实施方式中，该客户号分配方法还包括：

利用数据库记录当前客户号的最大可用值；

在客户号分配过程中设置一个固定步长，例如100万，在Redis集群分配客户号的同时，若分配至步长整数倍序号时，在数据库记录当前序号+步长，当前序号+固定步长即最大可用值。

在Redis集群出现问题重启后，从数据库加载最大可用值，继续进行客户号分配；

如此设计，可以借助数据库用来应对Redis集群宕机的风险，进一步保证可靠性。

可选的，为减轻加锁对于分配客户号的影响，在第一次加锁冲突后会等待设定时间，例如100ms，再进行分配客户号的分配流程。

需要说明的是，本申请实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本申请实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

另外，上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

图3为本申请实施例提供的一种客户号分配装置的结构示意图，如图3所示，本实施例的装置可以包括：

获取模块100，被配置为获取客户号分配请求和基础信息；

查询模块200，被配置为根据所述基础信息查询是否存在对应的所述客户号；

加锁模块300，被配置为在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；

分配模块400，被配置为在加锁成功后生成设定位数的自增序列；

输出模块500，被配置为输出包含所述自增序列的客户号。

本实施例的装置可以用于执行图1所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

为了描述的方便，描述以上装置是以功能分为各种模块分别描述。当然，在实施本申请实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种基于Redis集群的客户号分配方法，其特征在于，包括：

获取客户号分配请求和基础信息；

根据所述基础信息查询是否存在对应的所述客户号；

在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；

在加锁成功后生成设定位数的自增序列；

输出包含所述自增序列的客户号。

2.根据权利要求1所述的客户号分配方法，其特征在于，所述利用Redis分布式锁对所述基础信息加锁，包括：

获取当前时间；

按顺序依次向N个Redis节点执行获取锁的操作；

计算总共消耗时间；

根据总共消耗时间是否超过锁有效时间，以及是否从大多数Redis节点获取锁成功，判断加锁是否成功。

3.根据权利要求2所述的客户号分配方法，其特征在于，所述获取锁的操作，包括：

发送获取锁指令，所述获取锁指令包括所述基础信息、随机字符串和锁有效时间；

在所述基础信息存在时，获取锁失败。

4.根据权利要求1-3中任一项所述的客户号分配方法，其特征在于，所述利用Redis分布式锁对所述基础信息加锁之后，还包括：

在加锁失败后的设定时间后，重新执行所述客户号分配方法。

5.根据权利要求1-3中任一项所述的客户号分配方法，其特征在于，所述生成设定位数的自增序列，包括：

利用Redis Incr命令生成设定位数的自增序列。

6.根据权利要求5所述的客户号分配方法，其特征在于，所述在加锁成功后生成设定位数的自增序列，包括：

在加锁成功后查询是否存在对应的所述客户号；

在所述客户号不存在时，利用Redis Incr命令生成设定位数的自增序列。

7.根据权利要求1所述的客户号分配方法，其特征在于，还包括：

利用数据库记录当前客户号的最大可用值；

在Redis集群出现问题重启后，从数据库加载最大可用值，继续进行客户号分配。

8.根据权利要求1所述的客户号分配方法，其特征在于：所述客户号为身份标识号、交易订单号、物流单号或产品序列号。

9.根据权利要求1或8所述的客户号分配方法，其特征在于：所述客户号为保险行业的身份标识号；

对于证件类型为身份证的客户，所述客户号为身份证前6位+开户年份+自增序列；

对于证件类型为非身份证的客户，所述客户号为100100+开户年份+自增序列。

10.一种基于redis集群的客户号分配装置，其特征在于，包括：

获取模块，被配置为获取客户号分配请求和基础信息；

查询模块，被配置为根据所述基础信息查询是否存在对应的所述客户号；

加锁模块，被配置为在所述客户号不存在时，利用Redis分布式锁对所述基础信息加锁；

分配模块，被配置为在加锁成功后生成设定位数的自增序列；

输出模块，被配置为输出包含所述自增序列的客户号。

Images