一种客户信息查询方法、装置、设备及可读存储介质

技术领域

本申请涉及金融领域，具体涉及一种客户信息查询方法、装置、设备及可读存储介质。

背景技术

随着金融行业的高速发展，银行拥有庞大的客户体量。业务处理的过程中涉及对客户信息的查询或修改，客户信息的存储及读写IO性能面临极大挑战。数据库从性能强大的ORACLE替换成轻量型的腾讯云企业级分布式数据库(Tencent Distributed Database，TDSQL)以满足现有需求。

但是目前采用的分库分表方式存在数据分布不均匀、数据库扩容及迁移复杂的问题，导致数据查询效率较低。

发明内容

有鉴于此，本申请提供一种客户信息查询方法、装置、设备及可读存储介质，能够有效提高数据查询效率。

为解决上述问题，本申请提供的技术方案如下：

第一方面，本申请提供一种客户信息查询方法，所述方法应用于服务器，包括：

响应于获取用户的查询请求，根据所述查询请求确定客户号；

基于数据库Info表获取与所述客户号对应的目标组和目标数据库；

根据所述目标组和所述目标数据库确定目标表格；

根据所述目标表格获取与所述查询请求对应的客户信息。

在一种可能实现的方式中，所述根据所述目标组和所述目标数据库确定目标表格，包括：

从所述数据库Info表中确定与所述客户号对应的目标组和所述目标组的数据库数；

根据所述客户号和所述数据库数确定所述目标数据库；

根据所述客户号、所述目标组以及所述目标数据库确定所述目标表格。

在一种可能实现的方式中，所述方法还包括：

响应于获取数据扩容请求，根据所述数据扩容请求确定待分配客户号和所述待分配客户号的客户信息；

采用Range垂直分区策略将所述待分配客户号分配到组层；

利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层；

采用所述Range垂直分区策略将分配到数据库层的待分配客户号的客户信息存储到表格层。

在一种可能实现的方式中，所述利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层，包括：

根据所述数据库层中每个数据库的承担数据比例和哈希算法的预设除数值将所述分配到所述组层的待分配客户号分配到所述数据库层。

在一种可能实现的方式中，所述方法还包括：

根据所述待分配客户号、所述组层以及所述数据库层更新所述数据库Info表。

第二方面，本申请提供一种客户信息查询装置，所述装置应用于服务器，包括：

确定模块，用于响应于获取用户的查询请求，根据所述查询请求确定客户号；

获取模块，用于基于数据库Info表获取与所述客户号对应的目标组和目标数据库；

所述确定模块，还用于根据所述目标组和所述目标数据库确定目标表格；

所述获取模块，还用于根据所述目标表格获取与所述查询请求对应的客户信息。

在一种可能实现的方式中，所述确定模块，用于根据所述目标组和所述目标数据库确定目标表格，包括：

确定子模块，用于从所述数据库Info表中确定与所述客户号对应的目标组和所述目标组的数据库数；根据所述客户号和所述数据库数确定所述目标数据库；根据所述客户号、所述目标组以及所述目标数据库确定所述目标表格。

在一种可能实现的方式中，所述装置还包括：

确定模块，还用于响应于获取数据扩容请求，根据所述数据扩容请求确定待分配客户号和所述待分配客户号的客户信息；

分配模块，用于采用Range垂直分区策略将所述待分配客户号分配到组层；

所述分配模块，还用于利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层；

存储模块，用于采用所述Range垂直分区策略将分配到数据库层的待分配客户号的客户信息存储到表格层。

在一种可能实现的方式中，所述分配模块，用于所述利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层，包括：根据所述数据库层中每个数据库的承担数据比例和哈希算法的预设除数值将所述分配到所述组层的待分配客户号分配到所述数据库层。

在一种可能实现的方式中，所述装置还包括：

更新模块，用于根据所述待分配客户号、所述组层以及所述数据库层更新所述数据库Info表。

第三方面，本申请提供一种客户信息查询设备，包括：处理器、存储器、系统总线；

所述处理器以及所述存储器通过所述系统总线相连；

所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述第一方面所述的客户信息查询方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，当所述指令在设备上运行时，使得所述设备执行上述第一方面所述的客户信息查询方法。

由此可见，本申请具有如下有益效果：

本申请提供一种客户信息查询方法、装置、设备及可读存储介质，响应于获取用户的查询请求，根据所述查询请求确定客户号；基于数据库Info表获取与所述客户号对应的目标组和目标数据库；根据所述目标组和所述目标数据库确定目标表格；根据所述目标表格获取与所述查询请求对应的客户信息。如此，增加了组的概念，将数据库划分为组层、数据库层以及表格层，组层、数据库层以及表格层结合实现数据平均分布，能够根据客户号确定对应的组层、数据库层以及表格层，从表格层获取与查询请求对应的客户信息，使得服务器运行在较均衡的状态，能够有效提高数据查询效率。

附图说明

图1为本申请实施例提供的一种客户信息查询方法的流程示意图；

图2为本申请实施例提供的一种网关服务器与分布式数据库模块的交互示意图；

图3为本申请实施例公开的一种数据层级与分库分表策略对应关系示意图；

图4为本申请实施例提供的一种客户信息查询装置的结构示意图；

图5为本申请实施例提供的一种客户信息查询设备的结构示意图。

具体实施方式

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

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

TDSQL内核是MySQL，它的单表可以存储10亿级数据，但是满载时性能较差。业界公认MySQL单表容量在1千万以下是最佳状态。所以分库分表的方式也是所有数据量大、并发高的分布式系统都必须采用的方式，用来突破单机性能局限。其中，分库分表是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分为若干数据库组成，将数据大表拆分成若干数据表，使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。

尽管分库分表的方式可以提高数据查询效率，减缓数据库压力，但常见的分库分表方案存在着数据可能分布不均匀，数据库扩容及迁移复杂的问题，导致数据查询效率较低。

基于此，本申请实施例提供一种客户信息查询方法、装置、设备及可读存储介质，响应于获取用户的查询请求，根据所述查询请求确定客户号；基于数据库Info表获取与所述客户号对应的目标组和目标数据库；根据所述目标组和所述目标数据库确定目标表格；根据所述目标表格获取与所述查询请求对应的客户信息。如此，增加了组的概念，将数据库划分为组层、数据库层以及表格层，组层、数据库层以及表格层结合实现数据平均分布，能够根据客户号确定对应的组层、数据库层以及表格层，从表格层获取与查询请求对应的客户信息，使得服务器运行在较均衡的状态，能够有效提高数据查询效率。

为了便于理解本申请实施例提供的技术方案，下面结合附图对本申请实施例提供的一种客户信息查询方法、装置、设备及可读存储介质进行说明。

需要说明的是，存在Range垂直分区映射策略和哈希取模路由策略两种路由策略。Range垂直分区映射策略是按照顺序切割客户号，数据库扩容时新增单一数据库数据库，将新增的一定范围客户号全部放在同一个新增数据库数据库中。该策略是根据数据库配置性能强弱，分配不同范围大小的数据，每个库存放的数据范围不同，多个新增的数据库也无法帮助这个数据库分担压力。新数据插入频繁，IO交互压力大，容易引起热点数据库出问题，导致宕机等意外情况，进而影响客户信息查询效率。

哈希取模路由策略包括简单哈希、一致性哈希以及带虚拟节点的一致性哈希。

简单哈希为在分布式系统中假设有n个节点，传统方案使用mod(key，n)映射数据和节点。当扩容或缩容时，哪怕只是增减1个节点，映射关系都会变动为mod(key，n+1)/mod(key，n-1)，绝大多数数据的映射关系都会失效，需要进行大面积数据迁移。

一致性哈希为按照常用的hash算法来将对应的key哈希到具有2

上述一致性哈希可以极大优化简单哈希带来的数据与服务起的映射关系问题，但当使用比较差的hash函数时，环形hash可能出现几台服务器都映射到一起，导致hash环上很多空间没有被利用上，即hash偏斜现象。一致性哈希算法引入了虚拟节点机制，对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体的：可以先确定每个物理节点关联的虚拟节点数量，然后在ip或者主机名后面增加编号。以上述三胎服务器为例，可以为每台服务器计算三个虚拟节点，于是可以分别计算“S0#1”、“S0#2”、“S0#3”、“S1#1”、“S1#2”、“S1#3”、“S2#1”、“S2#2”、“S2#3”的哈希值，形成九个虚拟节点。同时数据定位算法不变，只是多了虚拟节点到实际节点的映射，例如定位到“S0#1”、“S0#2”、“S0#3”三个虚拟节点的数据均定位到S0服务器上，定位到“S1#1”、“S1#2”、“S1#3”三个虚拟节点的数据均定位到S1服务器以此类推。能够解决服务节点少时数据倾斜的问题，但只是改善了hash偏移问题。

可知，哈希取模路由策略是把新增的客户号平均分散到新增的所有数据库里，解决了Range垂直分区映射策略中存在的数据库过热的问题。但是Hash分区有一个除数因子，该除数因子不能随意改动。而随着数据量的不断增大，扩容数据库的同时分库分表的策略会随着改变，该除数因子会影响已有数据的定位，必须进行数据迁移，需要系统停机进行数据迁移，影响部分业务正常运行。若未进行数据迁移或数据迁移出错，则可能会导致数据库中存在需要使用的数据，但单元定位策略的变动会导致找不到对应的数据，导致业务流程出错，严重降低查找效率和用户体验。

基于此，本申请实施例提出了一种组的概念(Group)，每一个组包含若干数据库节点，每一个组里都有一个独立的哈希路由算法。具体节点个数可根据扩容调整。例如：当银行需要进行客户号数据进行一次扩容时，需要先评估出扩容的银行客户号范围，以范围为(N，N+M)为例，根据单个数据库节点(DataBase，DB)性能配置可预计存放数据量，例如存放数据量为A，计算出需要多少数据库为一组，即需要M/A个数据库节点，通过Hash分区策略把客户号映射到这些数据库节点中。每个数据库节点中又存在多个分表，由于MYSQL性能的限制，每个分表一般最多存放2000万条数据，在每个数据库中，通过Range垂直分区策略，将这些客户号映射到对应的分表表格(Table)中。

本申请实施例提供的一种客户信息查询方法可以应用于服务器，更具体的，可以应用于数据库服务器，也可以应用于网关服务器，本申请实施例对此并不作限定。参见图1，图1为本申请实施例提供的一种客户信息查询方法的流程示意图，该方法具体包括S101-S104。

S101：响应于获取用户的查询请求，根据所述查询请求确定客户号。

用户在查询客户信息时，触发生成查询请求，该查询请求可以携带客户号。服务器可以通过网关模块接收该查询请求并提取客户号。本申请实施例并不限定客户号提取方式，可以根据实际需求进行选择。

S102：基于数据库Info表获取与所述客户号对应的目标组和目标数据库。

在执行确定客户号对应的目标组和目标数据库之前，预先构建了数据库信息表，可以为数据库Info表(DBInfo表)。该DBInfo表为Range策略客户号范围分区客户号映射与哈希取模客户号映射代码。表中可以包括客户号所属GroupId(即目标Group)、所属Group起始客户号、所属Group结束客户号、所属Group包含DB数，该DB数为哈希分区除数因子、DBId(即目标DB，每个Group都是从1开始编码)。其中主键为GroupId和DBId组成的联合主键。通过该DBInfo表，可以获得与客户号对应的GroupId、DB数。

预先搭建数据库应用服务，配置文件中可以包括DBIP地址、DB端口号、DB登录用户名、加密密码等信息。可以根据实际情况对Table层进行分表，比如一个Group有3个相同或不同配置的DB，3个DB预计总存储30亿数据量，一个DB按照其服务器内存配置参数计划存储10亿数据量，按照每张表存储1800万数据，则需要分为56张Table。

在一种可能实现的方式中，通过客户号和DB数可以确定DBId。网关模块在接收到查询请求后，查询DBInfo表，基于Range映射服务找到该客户号对应的GroupId，以及基于哈希取模映射服务确定该Group包含的DB数，在网关路由代码中实现hash算法，公式如下：

DBId＝客户号mod DB数

根据GroupId和DBId定位到对应DB的IP地址。

S103：根据所述目标组和所述目标数据库确定目标表格。

以网关服务器为例进行说明，参见图2，图2为本申请实施例提供的一种网关服务器与分布式数据库模块的交互示意图。在一种可能实现的方式中，所述根据所述目标组和所述目标数据库确定目标表格，包括：从所述数据库Info表中确定与所述客户号对应的目标组和所述目标组的数据库数；根据所述客户号和所述数据库数确定所述目标数据库；根据所述客户号、所述目标组以及所述目标数据库确定所述目标表格。

网关服务器调用Group定位服务，将客户号作为入参，查询返回该客户号所对应的Group。调用DB定位服务，将客户号和Group作为入参，查询返回该客户号所对应的DB。调用Table定位服务，将客户号、DB和Group作为入参，查询返回该客户号所对应的Table。

S104：根据所述目标表格获取与所述查询请求对应的客户信息。

Table层使用的是Range分区策略，客户号划分范围是整个Group的范围，例如，Group存放0-30亿的客户号，该Group下的某个DB划分56张分表，那么第一张分表范围就是0-5357万(30亿除以56)，但是该表只会存放1786万条数据(30亿除以3再除以56)，因为该表里的数据被哈希分区了，满足TDSQL性能要求。

确定目标表格之后，可以从该目标表格存储的数据中获取与查询请求的客户号对应的客户信息。需要说明的是，本申请实施例并不限定该客户信息的获取方式，可以根据实际需求进行选择。

本申请实施例采用Hash取模对Range垂直分区策略进行优化的分库分表扩容方案，结合了Hash取模评分数据库节点压力的邮件，与Range垂直分区扩容不需要数据迁移的优点。采用Group的方式，新增数据压力被Hash平均分配到了组里的所有数据库中，或者根据各数据库服务器性能动态分配数据量。可以避免Range垂直分区的数据库扩容导致新增数据库压力过大。

基于上述步骤S101至S104的内容可知，响应于获取用户的查询请求，根据所述查询请求确定客户号；基于数据库Info表获取与所述客户号对应的目标组和目标数据库；根据所述目标组和所述目标数据库确定目标表格；根据所述目标表格获取与所述查询请求对应的客户信息。如此，增加了组的概念，将数据库划分为组层、数据库层以及表格层，组层、数据库层以及表格层结合实现数据平均分布，能够根据客户号确定对应的组层、数据库层以及表格层，从表格层获取与查询请求对应的客户信息，使得服务器运行在较均衡的状态，能够有效提高数据查询效率。

在另一种可能实现的方式中，当需要扩容数据库时，所述方法还包括：响应于获取数据扩容请求，根据所述数据扩容请求确定待分配客户号和所述待分配客户号的客户信息；采用Range垂直分区策略将所述待分配客户号分配到组层；利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层；采用所述Range垂直分区策略将分配到数据库层的待分配客户号的客户信息存储到表格层。

当需要扩容数据库时，只需要增加Group，每次扩容增加的Group与原有Group之间是并列关系，互不影响，只需要在网关服务器中维护新增Group信息以及该Group下的DB、Table信息即可，不需要进行任何数据迁移。

参见图3，图3为本申请实施例公开的一种数据层级与分库分表策略对应关系示意图。可知，Group层和Table层采用Range分区的分库分表策略，DB层采用哈希取余的分库分表策略。

在一种可能实现的方式中，所述利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层，包括：根据所述数据库层中每个数据库的承担数据比例和哈希算法的预设除数值将所述分配到所述组层的待分配客户号分配到所述数据库层。

以下对哈希取余策略进行说明，本申请实施例可以在基本流程上优化哈希取余算法。

若新增数据库节点性能各不相同则使用一般的Hash算法平分数据压力仍会出现热点问题，因此可以设定Hash算法除数固定为10，余数为0到9是个数字，根据扩容数据库的性能分析每个数据库承担数据比例。需要说明的是，被除数为客户号，默认客户号是按顺序增加的。数据库性能是根据服务器内存配置决定的，例如：数据库服务器A的运行内存16G，存储内存1T，数据库服务器B的运行内存32G，存储内存5T，可知数据库服务器B承担的数据量就可以是数据库服务器A的5倍，数据库服务器A可以存储余数为0、1的客户号，数据库服务器B可以存储2-9的客户号。

具体的，例如DB_0的性能是DB_1和DB_2的两倍，则可以将余数0、1、2、3、4这五个余数映射到DB_0，将余数5、6、7三个余数映射到DB_1，剩下的余数8、9映射到DB_2，这样就可以按照服务器指标，设计数据量分配。以上仅为示例，这里hash算法只是将数据打散平均分到各个DB中，只要保证每个DB存储的数据量相对平均即可，上述具体例子并不对本申请进行任何限制。

在一种可能实现的方式中，新增数据库后，所述方法还包括：根据所述待分配客户号、所述组层以及所述数据库层更新所述数据库Info表。

按照更新后的数据库Info表实现客户信息查询，能够支持更完善的数据查询，以提高客户信息查询效率和用户体验。

需要说明的是，本申请提供的一种客户信息查询方法、装置、设备及可读存储介质可用于金融领域或其他领域，例如，可用于金融领域中的客户信息查询的应用场景。其他领域为除金融领域之外的任意领域，例如数据处理技术领域。上述仅为示例，并不对本申请提供的客户信息查询方法、装置、设备及可读存储介质的应用领域进行限定。

前述本申请实施例提供基于上述的一种客户信息查询方法。接下来说明本申请实施例中还提供的一种客户信息查询装置，该装置执行前述图1所示的方法，接下来对客户信息查询装置的功能进行说明，所述客户信息查询装置的结构示意图如图4所示，确定模块401以及获取模块402。

确定模块401，用于响应于获取用户的查询请求，根据所述查询请求确定客户号；

获取模块402，用于基于数据库Info表获取与所述客户号对应的目标组和目标数据库；

所述确定模块401，还用于根据所述目标组和所述目标数据库确定目标表格；

所述获取模块402，还用于根据所述目标表格获取与所述查询请求对应的客户信息。

在一种可能实现的方式中，所述确定模块401，用于根据所述目标组和所述目标数据库确定目标表格，包括：

确定子模块，用于从所述数据库Info表中确定与所述客户号对应的目标组和所述目标组的数据库数；根据所述客户号和所述数据库数确定所述目标数据库；根据所述客户号、所述目标组以及所述目标数据库确定所述目标表格。

在一种可能实现的方式中，所述装置还包括：

确定模块，还用于响应于获取数据扩容请求，根据所述数据扩容请求确定待分配客户号和所述待分配客户号的客户信息；

分配模块，用于采用Range垂直分区策略将所述待分配客户号分配到组层；

所述分配模块，还用于利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层；

存储模块，用于采用所述Range垂直分区策略将分配到数据库层的待分配客户号的客户信息存储到表格层。

在一种可能实现的方式中，所述分配模块，用于所述利用哈希取余策略将分配到所述组层的待分配客户号分配到数据库层，包括：根据所述数据库层中每个数据库的承担数据比例和哈希算法的预设除数值将所述分配到所述组层的待分配客户号分配到所述数据库层。

在一种可能实现的方式中，所述装置还包括：

更新模块，用于根据所述待分配客户号、所述组层以及所述数据库层更新所述数据库Info表。

本申请实施例提供一种客户信息查询装置，包括确定模块和获取模块。确定模块用于响应于获取用户的查询请求，根据所述查询请求确定客户号；获取模块用于基于数据库Info表获取与所述客户号对应的目标组和目标数据库；所述确定模块还用于根据所述目标组和所述目标数据库确定目标表格；所述获取模块还用于根据所述目标表格获取与所述查询请求对应的客户信息。如此，增加了组的概念，将数据库划分为组层、数据库层以及表格层，组层、数据库层以及表格层结合实现数据平均分布，能够根据客户号确定对应的组层、数据库层以及表格层，从表格层获取与查询请求对应的客户信息，使得服务器运行在较均衡的状态，能够有效提高数据查询效率。

参见图5，图5为本申请实施例提供的一种客户信息查询设备的结构示意图。基于上述方法实施例提供的一种客户信息查询方法，本申请实施例还提供一种客户信息查询设备，包括：处理器、存储器、系统总线；

所述处理器以及所述存储器通过所述系统总线相连；

所述存储器用于存储一个或多个程序，所述一个或多个程序包括指令，所述指令当被所述处理器执行时使所述处理器执行上述任一项实施例所述的客户信息查询方法。

基于上述方法实施例提供的一种客户信息查询方法，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，当所述指令在设备上运行时，使得所述设备执行上述任一项实施例所述的客户信息查询方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。