CN112632157B - 一种分布式系统下的多条件分页查询方法 - Google Patents

Abstract

本发明公开了一种分布式系统下的多条件分页查询方法，通过构建数据子集并对获得数据子集做交集，得到ID列表数据，借助查询关键ID标识来代替查询整条数据，只对ID列表作分页来代替对整条数据的分页的方式，实现了当查询条件分布在多个数据源且查询结果数据量较大时，减少了整体数据加载耗时和内存占用的空间。

Description

一种分布式系统下的多条件分页查询方法

技术领域

本发明涉及数据处理领域，具体适用于分布系统下多数据源的分页查询。

背景技术

最近几年，随着单体应用向分布式系统演化以及微服务的普及，很多软件系统内部已经拆分为多个业务子系统，各个业务子系统都有自己独立的数据库。对于面向B端提供企业服务的软件产品，首先需要管理企业的员工帐号，通常都会为企业客户提供一套后台用户管理系统，每个企业的IT管理员可以管理自己企业的员工帐号。

为说明方便，以下我们将后台用户管理系统简称管理系统，下面举一个例子详细说明问题。假设管理系统的用户列表页面上需要显示姓名、手机、邮箱，部门、帐号状态、帐号类型、角色、开通功能等8个字段，终端页面显示的数据看起来像是全部来自一个后端应用，实际上这个管理系统后台对接了用户信息、组织部门、帐号管理、产品权限等多个子系统，这8个字段分别位于用户信息、组织管理、帐号管理、产品权限4个子系统，其中部门、帐号状态、帐号类型、角色、产品 5个字段作为高级筛选条件。 这是一个典型的分布式系统下多数据源多条件的分页筛选问题，需要考虑的实际问题如下：数据量问题，有的企业组织很庞大，可能多达几十万甚至上百万帐号，占用空间大，加载时间长； b)分页问题，数据跨多个子系统无法直接使用数据库自带的分页功能。

目前的方案，主要有独立设计一个为此复杂查询专门准备的新数据源，为方便说明我们将这个新数据源简称为子系统E，子系统E会将此查询用到的所有字段都保存到一张数据库表中，它的数据来自于其它几个子系统的实时自动同步，具体如下：1用户的姓名、手机号、邮箱可以在创建用户时，由用户信息子系统同步到子系统E； 2.组织部门信息可以在用户的组织部门变动时，由组织管理子系统同步至子系统E； 3.帐号状态、角色信息可以在相关信息变动时，由帐号管理子系统同步至子系统E； 4.帐号类型、开通功能可以在产品权限变动时，由产品权限子系统同步至子系统E；

不同子系统之间的数据同步，通过类似mq等异步消息队列机制来实现数据变化的通知； 由于所有字段都位于一张表，则通过一个多条件的SQL查询就可以完成数据的查询和分页。或者采用分布式系统设计成共用数据源，即各个子系统中只有应用程序是分布式，所用到的数据表都位于一个DB，通过多表联合查询及数据库自带的limit机制实现分页查询。或者采用现有的CN103853727 A公开的种提高大数据量查询性能的方法及系统，所述方法包括：A、将磁盘数据库中的数据以缓存ID-实体数据的键值对形式加载到分布式缓存中，同时将所述缓存ID以及实体数据中的关键信息存入内存数据库中的缓存ID表中；B、获取客户端发送的查询请求时，依据该查询请求查询缓存ID表，选出符合查询条件的缓存ID集合；C、依据所述缓存ID集合从相应的分布式缓存中获取实体数据并返回客户端。

上述方式方法，要么通过数据同步将多数据源变成单数据源，多子系统查询简化为数据库单表查询，从而避开了多数据源查询分页问题，但带来的问题也很多：数据一致性问题，多数据源同步很难做到数据在两个子系统中完全一致，宕机、断网、系统内部处理数据的失败都是无法避开的问题； 对架构的冲击很大，整个架构都需要作调整，要引入mq、新的子系统及相应DB存储等，需要对架构做比较大的调整，不利于系统的稳定性。

同时扩展性差，一旦需要增加一个新的筛选字段，例如职位，则不仅要新增加职位字段的数据同步机制，还需要将已经存在的职位数据全量洗一遍到子系统，不论是操作难度还是风险都很大； 其次，只要用户量稍微一大，多表联合查询性能会非常差，一条复杂联表SQL可能几十秒无法返回，直接拖慢整个DB，会不仅此复杂查询的性能无法保证，甚至会影响到整个系统的可用性。

同时目前的在后台用户管理系统中，为方便检索经常会提供高级筛选功能，高级筛选会有多个筛选条件，这些筛选条件对应的数据源可能分布在多个业务子系统中，传统基于SQL的条件查询一次只能查询一个业务子系统，单一业务子系统中无法得到符合全部条件的筛选结果，必须汇总每个业务子系统各自的条件查询结果才能合并出最终符合条件的数据集，基于符合条件的数据集才能给终端作分页显示。但最终符合条件的数据集可能很多达几万条，每条数据十几个字段，其中不乏像邮箱、部门等占用几十个字节的大字段，1条数据占用空间至少100B+，10万条数据至少10MB+，单将几万条数据从各个子系统查询并加载到内存可能就需要几秒甚至几十秒，这个响应延迟对终端使用是无法接受的。

发明内容

为解决上述技术问题至少之一，本发明提出一种分布式系统下的多条件分页查询方法

步骤1，为每个用户数据条目设置一个主标识userID，用户数据通过userID映射关联；

步骤2，获取终端发起的多条件查询请求，依据多条件查询请求，在各数据子系统中获取符合筛选条件的userID数据子集，所述userID数据子集的数量为N；

步骤3，对在数据子系统中所获得的符合筛选条件下的N个userID数据子集做交集运算，所述交集运算具体是：在N个userID数据子集中找出一个最小数据子集A，称为minList, 将N个userID数据子集转换为哈希表map结构，键表示userID，值表示此userID在各个userID数据子集中出现次数的计数，称为count，初始值都为1；

以选定最小数据集A ,minList为基准，依次遍历除了最小数据子集A之外的userID数据子集，在遍历时，当userID在哈希表map中不存在时，count值维持不变；当userID在哈希表map中存在时，count值+1； 当count值=N时，将对应的userID放入到数据总集userIDList中，全部遍历完后，userIDList为最终符合所有筛选条件的userID数据总集；其中，count用于判断一个userID是否在N个userID数据子集中都出现，等价于是否userID符合所有筛选条件；

步骤4 获得最终符合所有条件的userID 数据总集userIDList, 根据每页的数量做截取，获得分页结果，每页的userID子集用pageUserIDList表示。

优先的，所述步骤4进一步包括：获取userID 数据总集userIDList的单页userID子集pageUserIDList，在各个数据子系统中查询页面显示需要的字段信息并组合显示。

优选的，所述步骤4进一步包括，对最终符合所属有条件的userID 数据总集userIDList 进行缓存，以备翻页查询。

优选的，对userID 数据总集userIDList 做缓存的时间设置的参数，包括终端MAC的地址信息。

优选的，所述步骤1进一步包括：获取不同终端登录时的访问标识token, 建立一个以token为key的哈希表map、value，历史数据总集userIDList和历史筛选条件conditions组成的触发参数集；当接收到终端查询请求时，判断当前请求的筛选条件与缓存中最近一次的历史筛选条件是否一致；如果两次筛选的条件不一致，则清空userID数据总集；如果两次筛选条件一致，则表示用户只是在上一次筛选结果的基础上作翻页操作，直接复用缓存中已经存在的userID数据总集userIDList，执行分页结果集查询。

优先的，设置缓存数据的生命周期与各终端访问标识token的生命周期相同。

优选的，所述步骤4进一步包括，当检测到用户查询完后挂着页面不动或者直接关闭浏览器页签，则进一步判断是否超过释放时间阈值，如果是超过则释放，否则等待。

优选的，所述步骤4进一步包括：为userID数据总集设置分页数据的缓存阈值，大于缓存阈值后的分页数据不做缓存处理。

优选的，在执行多条件查询请求时，采用采用多叉树判别是否存在可用的中间结果的userID数据总集缓存。

本发明的系统通过包括上述方法实现了当查询条件分布在多个数据源且查询结果数据量较大时，通过只查询关键ID标识来代替查询整条数据，通过只对ID列表作分页来代替对整条数据的分页，来减少整体数据加载耗时和内存占用的空间，并最终满足生产环境功能、性能及用户体验上可用性的技术方案。不需要在不同子系统间同步数据，不存在数据一致性问题； 完全基于现有分布式系统架构来实现，不需要对架构做任何调整，最大程度保证了系统的稳定性； 扩展性良好，如果需要新增一个筛选条件，存储层不需要改动，只需要扩展查询接口的入参出参即可快速响应需求变化； 由于每个子系统都是单表查询，不存在多表联合查询带来的速度慢的风险和隐患。

附图说明

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

图1是本方法的流程示意图。

具体实施方式

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

实施例1

如图1所示，为了实现是在尽量不动现有分布式系统架构的前提下，通过查询和算法设计上的改进，来同时满足功能和性能上的需求，本方案更注重实用性。本基于分布式系统下多条件分页查询方法，采用的方法：

步骤1-2可以具体化为，用户管理系统，对每个用户设置一个主标识，我们暂称为userID，通过主标识将关联各个子系统中的相关数据，设置各个子系统中与用户相关的数据都可以直接或间接通过userID查询得到。构造的方法中，虽然页面显示需要的数据字段多、占用空间大、传输耗时长，但userID一般都很小，4个字节的无符号整数就可以表示40亿帐号，基本够绝大部分用户系统使用。对于一个10万员工的大企业来说，所有帐号的userID加起来占用的空间是：

100000 * 4（字节）= 400KB

即使从最慢的以机械硬盘作为存储介质的DB中查询400KB的数据，经实际测试也只需要300ms左右，已经处于可接受的范围，如果用SSD会更快。

这样对于终端发起的多条件查询请求，我们可以只查询userID，将各个子系统中符合条件的userID取交集，即可得到符合所有条件的userID数据集。这个userID数据集按照上面的占用空间计算，可以直接放到内存中，这样大组织带来的空间占用和加载耗时问题基本可控。

具体为：各个子系统分别查userID子集，举例子来说，有5个筛选条件位于3个不同的子系统中，以最坏的情况来说，终端请求的查询条件正好覆盖到3个子系统，则我们需要从3个子系统分别查询来得到3个userID数据子集，即：

userID子集A：符合部门筛选条件的userID数据集；

userID子集B：符合帐号状态、角色筛选条件的userID数据集；

userID子集C：符合帐号类型和功能权限筛选条件的userID数据集；

进一步分析，实际使用中用户并不会每次都选择所有条件，通常一两个条件的筛选占绝大多数，所以一次筛选中3个子系统都需要执行查询的属于极少数。

步骤3取交集，上述步骤中得到的3个userID子集分别满足各自子系统下的查询条件，只要对这3个userID子集执行取交集操作，即可得到符合所有条件的userID数据集，我们称为userIDList。取交集的方法如下：

从userID的3个子集A、B、C中找出一个最小数据集，称为minList, 将之转换为哈希表map结构，键表示userID，值表示此userID在各个数据子集中出现次数的计数，称为count，初始值都为1。count的作用在于判断一个userID是否在每个数据子集中都出现，等价于userID符合所有条件。

假设子集A为最小数据集minList，则我们依次遍历数据集B和C,在遍历时每个userID都有两种情况：

1）在哈希表map中不存在，则count值维持不变；

2）在哈希表map中存在，则count值+1；

如果发现count=3(在3个数据子集中都出现)，就将其放入到数据总集userIDList中，全部遍历完后，userIDList即为最终符合所有条件的userID数据集。

优先的：这里count=3的条件判断根据筛选条件数量的不同会有变化，如果筛选条件只有部门和帐号状态，则我们只需要从组织部门、帐号管理两个子系统便可覆盖所有筛选条件，此时我们放入数据总集userIDList的判断条件就是count=2。

步骤4，对获取的数据执行分页和缓存设置具体可做如下设置。

对于分页问题的，在获取到取到userID数据集后，终端发起的分页查询请求就简化成了对内存中userID数据集的分页操作，假设一页显示20条数据，我们只需要对20个userID去各个子系统分别查询需要的字段，即可组装出满足终端显示需要的20条完整数据。

在用户翻页显示时，只有userID数据集会驻留内存一段时间，一个4GB内存的机器就可支持将近10000大企业客户（以10万员工帐号来算）的管理员同时使用，而真实场景这样的大企业客户不会有这么多，所以实际同时支持的访问数量会更多。

具体为：假设page表示页码，从1开始，pageCount表示每页数量，pageCount=20表示每页显示20条，则我们可以根据数组的起始下标和终止下标的方式在userID数据集中截取指定页码的userID子集。

用start表示分页起始下标，计算公式为：

start= (page – 1) * pageCount，

用end表示分页终止下标，计算公式为：

end = min(page * pageCount, totalCount),

其中totalCount表示数据总集userIDList中元素总数量，min()函数表示两个数值中取较小的值。

每页的userID子集用pageUserIDList表示，则pageUserIDList = userIDList[start,end],表示对userIDList按下标取start到end之间的子集，其中start包含，end不包含。 另外需要考虑边界值，如果start>=totalCount，则此页直接为空。

查单页请求结果集

根据查到的单页userID子集pageUserIDList，去各个子系统中查询页面显示需要的字段信息， 假设存在4个子系统，则4个子系统可能会返回4个数据集，分别包含不同的字段：

数据集1：userID, 姓名、手机号、邮箱，由用户信息子系统返回

数据集2：userID, 部门名称，由组织部门子系统返回

数据集3：userID, 用户状态，角色，由帐号管理子系统返回

数据集4：userID, 帐号类型，功能权限，由产品权限子系统返回

各个数据集中的数据都通过userID关联，分别对数据集1、2、3、4作遍历，即可将所有数据字段组装到一个结果集中，此结果集中每条数据都是完整可显示的一条数据，字段如下所示：

userID，姓名，手机号，邮箱，部门名称，用户状态，角色，帐号类型，功能权限

多次查询说明：虽然需要去每个子系统中分别做一次DB查询，不过由于每页userID子集一般只有几十条数据，且都是单表走索引查询，所以速度很快。

当条件不变，用户只点页码翻页时，第二步中得到的userIDList是可复用的，对于单纯的翻页操作仅需要执行原理图中右边蓝色部分所示的单页结果集查询，要达到这个目的，则userIDList需要缓存起来备翻页查询使用。

下面我们来分析缓存结构该如何建立：

由于管理员在不同终端查询时高级筛选条件也不同，所以做userIDList的缓存时要按终端来缓存; 在管理系统中，一般都需要管理员登录才能使用，所以不同终端登录时都会有类似访问标识token（有的系统使用session，其实类似）来作为此终端的访问凭证。不论用户选择多少次条件，真正能被翻页复用的只有最后一次筛选条件查到的userIDList，所以一个终端我们仅需要缓存最新一次查询的userIDList。

鉴于以上分析，我们可以建立一个以token为key的哈希表map、value是userIDList和相应筛选条件conditions组成的结构体。数据结构如：

map[key, value],key=token,value={userIDList， conditions }

conditions也是map，存储着查出userIDList时所用到的查询条件，如：

department_id=222,

account_type=1

……

缓存查询条件conditions的目的在于，每次收到终端查询请求时，会判断当前请求的筛选条件与缓存中最近一次的筛选条件是否一致，有两种结果：

1）如果两次筛选条件不一致，则表示用户发起了一次新的条件筛选，缓存中的userID数据集已经无效需要清空；

2）如果两次筛选条件一致，则表示用户只是在上一次筛选结果的基础上作翻页操作，我们可以直接复用缓存中已经存在的userID数据集，执行分页结果集查询即可； 对于后端服务器是集群的情况，每次分页的查询请求是随机分发到一台服务器上的，为了让缓存userID数据集被所有机器都访问到，可以将第二步的userID数据集缓存到分布式缓存系统(如：Redis)中，每个服务器节点都从分布式缓存中查找和复用userID数据集。

关于缓存中数据的生命周期，简单做法可以和token的生命周期相同，在用户退出登录时销毁，但分布式缓存和内存都是极宝贵的资源，我们还是有必要针对终端可能的场景作进一步优化。假如用户查询完后挂着页面不动或者直接关闭浏览器页签，我们缓存的数据其实已经用不上，在token尚未过期时，后端服务器并不知道缓存的数据是否还会使用，针对这种情况我们可以设置一个缓存失效时间，例如10分钟未使用，就过期释放。如果用户真的10分钟后又发起翻页操作，对于后端来说也只不过是将步骤一和步骤二再执行一遍，查询结果的正确性方面不会有什么问题。

优选的，对查询条件作出判断后，可以通过缓存的数据集来判断是否存在相应的结果。

识别机制采用多叉树判别在执行多条件查询请求时是否存在可用的中间结果集缓存。

可选的，多叉树单节点可以包含高并发下读写锁、当前节点可存储where子句、运算符、值、缓存数据库ID、表名、缓存属性数组、缓存过期时间、缓存头id；子节点执行查询任务SQL语句经解析后化为以下二叉树的一条路径；

执行新的SQL语句时，将语句划分为选择条件、表名与查询属性，并将选择条件依照文本顺序进行排序，经过选择条件在二叉树中查找后，满足全条件均与二叉树内某一条路径存储数据相同或范围小于二叉树内标示范围时，若尾节点存在满足与查询执行数据库标识、表名相同，查询属性范围相同或大于当前查询目标属性且缓存未过期，则说明当前缓存可用；若之前存在查询范围不一致情况，则对该缓存结果执行二次查询后，

可选的也可以做二次查询，通过查询条件的合并，做拼接为新的中间结果集包，等待后续中间结果集缓存返回后执行合并操作并返回给客户端；反之直接生成中间结果集包等待后续处理，合并缓存的结果集适用于userID数据集。

更进一步，实际情况一次查询结果有几万条用户的意义其实不大，例如一页20条，20万条数据要翻10000页才能翻到，没有用户会有耐心去翻完这10000页，所以其实可以从产品功能设计上限制结果数据量太多时的页码数量，比如超过500页时后面的则忽略，这样能减少userID数据集的内存缓存占用，系统便可以支撑更多后台管理员并发使用。

实施例2

基于如上所述的示例，在一个实施例中涉及方法步骤的特征，可以被本发明提供的一种计算机设备/或系统实现，该计算机设备/系统包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现如上述各实施例中的任意一种方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性的计算机可读取存储介质中，如本发明实施例中，该程序可存储于计算机系统的存储介质中，并被该计算机系统中的至少一个处理器执行，以实现包括如上述各视频播放方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

据此，还提供一种存储介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如上述各实施例中的任意涉及的方法步骤。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (6)

1.一种分布式系统下的多条件分页查询方法，其特征在于：

步骤1，为每个用户数据条目设置一个主标识userID，用户数据通过userID映射关联；获取不同终端登录时的访问标识token，建立一个以token为key的哈希表map，value是历史数据总集userIDList和历史筛选条件conditions组成的触发参数集结构体，其中哈希表map 的数据结构为： map[key, value], key=token, value={userIDlist, conditions}；

当接收到终端的多条件查询请求时，判断当前请求的筛选条件与缓存中最近一次的历史筛选条件是否一致；如果两次筛选的条件不一致，则清空userID数据总集，跳转到步骤2；如果两次筛选条件一致，则表示用户只是在上一次筛选结果的基础上作翻页操作，直接复用缓存中已经存在的userID数据总集userIDList，执行分页结果集查询；

步骤2，获取终端发起的多条件查询请求，依据多条件查询请求，在各数据子系统中获取符合筛选条件的userID数据子集，所述userID数据子集的数量为N；

步骤3，对在数据子系统中所获得的符合筛选条件下的N个userID数据子集做交集运算，所述交集运算具体是：在N个userID数据子集中找出一个最小数据子集A，称为minList,将N个userID数据子集转换为哈希表map结构，键表示userID，值表示此userID在各个userID数据子集中出现次数的计数，称为count，初始值都为1；

以选定最小数据集A ，minList为基准，依次遍历除了最小数据子集A之外的userID数据子集，在遍历时，当userID在哈希表map中不存在时，count值维持不变；当userID在哈希表map中存在时，count值+1； 当count值=N时，将对应的userID放入到数据总集userIDList中，全部遍历完后，userIDList为最终符合所有筛选条件的userID数据总集；其中，count用于判断一个userID是否在N个userID数据子集中都出现，等价于是否userID符合所有筛选条件；

步骤4 获得最终符合所有条件的userID 数据总集userIDList, 根据每页的数量做截取，获得分页结果；

其中，获得最终符合所有条件的userID 数据总集userIDList, 根据每页的数量做截取，获取分页结果具体为：在获取到userID数据集后，将终端发起的分页查询请求简化成对内存中userID数据集的分页操作，设定page表示页码，从1开始，pageCount表示每页数量，pageCount=20，表示每页显示20条，根据数组的起始下标和终止下标的方式在userID数据集中截取指定页码的userID子集；用start表示分页起始下标，计算公式为：

start= (page – 1) * pageCount，

用end表示分页终止下标，计算公式为：

end = min(page * pageCount, totalCount),

其中totalCount表示数据总集userIDList中元素总数量，min()函数表示两个数值中取较小的值；每页的userID子集用pageUserIDList表示，则pageUserIDList = userIDList[start,end]，表示对userIDList按下标取start到end之间的子集，其中按下标取到的start到end之间的子集中，包含含有起点start的子集，不包含含有终点end的子集；当如果start>=totalCount，则此页直接为空；

获取userID 数据总集userIDList的单页userID子集pageUserIDList，在各个数据子系统中查询页面显示需要的字段信息并组合显示；

对最终符合所属有条件的userID 数据总集userIDList 进行缓存，以备翻页查询。

2.如权利要求1所述的方法，其特征在于：设置缓存userID数据总集userIDList数据的生命周期与各终端访问标识token的生命周期相同。

3.如权利要求2所述的方法，其特征在于：所述步骤4进一步包括，

当检测到用户查询完后挂着页面不动或者直接关闭浏览器页签，则进一步判断是否超过释放时间阈值，如果是超过则释放，否则等待。

4.如权利要求3所述的方法，其特征在于：所述步骤4进一步包括：为userID数据总集设置分页数据的缓存阈值，大于缓存阈值后的分页数据不做缓存处理。

5.如权利要求1所述的方法，其特征在于：在执行多条件查询请求时，采用多叉树判别是否存在可用的中间结果的userID数据总集缓存。

6.一种计算机存储介质，所述计算机存储介质上存储由计算机程序，所述计算机程序用于执行权利要求1-5中任一所述的方法。

Images