[发明专利]一种分布式系统下的多条件分页查询方法

说明书

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

技术领域

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

背景技术

最近几年，随着单体应用向分布式系统演化以及微服务的普及，很多软件系统内部已经拆分为多个业务子系统，各个业务子系统都有自己独立的数据库。对于面向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，会不仅此复杂查询的性能无法保证，甚至会影响到整个系统的可用性。