分库分表路由方法及系统

技术领域

本发明涉及数据治理技术领域，特别涉及一种分库分表路由方法及系统。

背景技术

随着业务系统运行年限的增加，将产生越来越多的业务数据。随着单表中的数据量越来越大，数据库查询QPS(Query Per Second，每秒查询率)越来越高，相应的，对数据库的读写所需要的时间也越来越多，这将导致数据库的读写性能成为业务发展的瓶颈。传统解决方案使用分库/表分担单个数据库/表的压力。

传统分库/表方案是通过预估数据量，将原来的一个库/表拆分成固定的n个，定义根据业务编号路由的规则。新业务入库时，根据路由规则分发到具体的分库分表中。但随着后续业务量继续增长，采用该方式很快还会导致数据库重新到达性能瓶颈，此时如果要将原有数据分发到2n个，需要对原来各库/表的数据都重新分发。分发过程需要对数据库造成极大的读写压力，且重新分发期间将导致分库/表数据无法提供服务。

为了在应用程序中将逻辑表的查询请求路由分发到具体的分表中，保证查询的透明性，本发明提出了一种分库分表路由方法及系统。

发明内容

本发明为了弥补现有技术的缺陷，提供了一种简单高效的分库分表路由方法及系统。

本发明是通过如下技术方案实现的：

一种分库分表路由方法，其特征在于：从多维度定义分库分表规则，使用Elasticsearch搜索引擎提供高性能的读写支撑，使用Redis本地缓存系统缓存路由结果缓解Elasticsearch搜索引擎的存储压力，实现高并发下的数据库读写及查询要求；

包括以下步骤：

步骤S1、部署Elasticsearch搜索引擎和Redis本地缓存系统；

步骤S2、业务系统根据自身业务需求预估数据量，规划路由规则构成维度；

步骤S3、在业务系统分表配置中扩展路由规则，得到多维度路由ID，利用Redis本地缓存系统对多维度路由ID进行缓存，同时将多维度路由ID持久化到Elasticsearch搜索引擎中，为业务系统亿级数量提供高并发读写支持。

本发明分库分表路由方法，采用Mysql数据库或HBase数据库替代Elasticsearch搜索引擎，实现多维度路由ID的持久化。

所述步骤S2中，为避免固定分表导致的存储上限，根据业务数据属性，将数据从多个维度进行分库分表，包括但不限于时间、区域和平均分表三个维度。

当业务系统对相关逻辑表发出读写请求时，先查询Elasticsearch搜索引擎中是否有当前业务主键的路由信息，如果有，则使用存储的路由到具体的分表中读取或写入数据；如果Elasticsearch搜索引擎中没有索引信息，则根据路由规则生成主键对应的路由ID，持久化到Elasticsearch搜索引擎索引成功后，再进行具体分表的读写操作。

业务系统发起逻辑表读写请求后，先查询Redis本地缓存系统中是否有对应的主键路由信息，如果有，则进行具体分表的读写操作；如果没有，则先根据路由规则生成对应的路由ID，再持久化到Elasticsearch搜索引擎中，同时缓存到Redis本地缓存系统中，再进行具体分表的读写操作。

一种分库分表路由系统，其特征在于：包括业务系统、Elasticsearch搜索引擎和Redis本地缓存系统；

所述业务系统负责根据自身业务需求预估数据量，规划路由规则构成维度，在业务系统分表配置中扩展路由规则，得到多维度路由ID；

所述Elasticsearch搜索引擎负责实现多维度路由ID的持久化；

所述Redis本地缓存系统负责实现多维度路由ID的缓存；

所述Elasticsearch搜索引擎和Redis本地缓存系统为业务系统亿级数量提供高并发读写支持。

所述路由规则构成维度包括但不限于时间维度、区域维度和平均分表维度。

本发明分库分表路由系统，采用Mysql数据库或HBase数据库替代Elasticsearch搜索引擎，实现多维度路由ID的持久化。

本发明的有益效果是：该分库分表路由方法及系统，使用Elasticsearch搜索引擎持久化路由信息，通过Redis本地缓存系统进行缓存，解决了单次分库分表的局限性问题，在应用程序中能够将逻辑表的查询请求路由分发到具体的分表中，即保证了查询的透明性，又能支持高并发下的数据库请求。

附图说明

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

附图1为本发明分库分表路由方法示意图。

附图2为本发明路由规则构成维度示意图。

具体实施方式

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

Sharding-JDBC：定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

Elasticsearch是一个分布式、RESTful风格的搜索和数据分析引擎，能够解决不断增长的大量数据。

Redis是一个开源(BSD许可)的、内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。

该分库分表路由方法，从多维度定义分库分表规则，使用Elasticsearch搜索引擎提供高性能的读写支撑，使用Redis本地缓存系统缓存路由结果缓解Elasticsearch搜索引擎的存储压力，实现高并发下的数据库读写及查询要求；

包括以下步骤：

步骤S1、部署Elasticsearch搜索引擎和Redis本地缓存系统；

步骤S2、业务系统根据自身业务需求预估数据量，规划路由规则构成维度；

步骤S3、在业务系统分表配置中扩展路由规则，得到多维度路由ID，利用Redis本地缓存系统对多维度路由ID进行缓存，同时将多维度路由ID持久化到Elasticsearch搜索引擎中，为业务系统亿级数量提供高并发读写支持。

该分库分表路由方法，采用Mysql数据库或HBase数据库替代Elasticsearch搜索引擎，实现多维度路由ID的持久化。

所述步骤S2中，为避免固定分表导致的存储上限，根据业务数据属性，将数据从多个维度进行分库分表，包括但不限于时间、区域和平均分表三个维度。

1).时间维度

根据业务系统预估的办件量，如每年有一亿数据产生，则时间维度以年为单位，划分20AB_维度(AB为年份)。如每季度便会产生一亿数据，则时间维度以季度为单位，划分20AB_C维度(AB为年份，C为季度)。

时间来源有两种：接收到数据的时间及业务属性中自带的时间。前者无需业务属性中含时间字段，和业务的耦合性不高，更具通用性，但是在批量迁移历史数据时，容易造成某个时间维度下的分表数据多于其它维度，导致数据不均匀。后者需要业务属性中有时间相关字段，可以保证批量迁移历史数据时数据是平均分布的。

2).区域与其他维度

根据时间划分后，可进一步根据业务中的其它属性做划分，如根据区划，划分20AB_C_DEF(DEF为区划标识)维度。选择的业务属性应避免联表查询等场景，且不影响统计等功能。

3).平均分表维度

在上述两个维度划分后，再将剩余的数据平均成n份，划分为20AB_C_DEF_N(N为分表数)。这里的N可根据下式计算得到：

N＝(主键.hashCode()&Integer.MAX_VALUE)％n

对于预估的不同维度数据量，n可以灵活设置为不同的值。

上述定义的路由规则(20AB_C_DEF_N)受多个因素影响，在后续查询时，仅仅根据主键无法重新计算出具体路由信息，因此需要将路由信息进行持久化。

由于历史数据批量迁移的过程中，存在大量数据读写需求，因此选择将数据持久化到Elasticsearch搜索引擎中，在并发读写的情况下，比持久化到Mysql数据库或HBase数据库的性能更好。

当业务系统对相关逻辑表发出读写请求时，先查询Elasticsearch搜索引擎中是否有当前业务主键的路由信息，如果有，则使用存储的路由到具体的分表中读取或写入数据；如果Elasticsearch搜索引擎中没有索引信息，则根据路由规则生成主键对应的路由ID，持久化到Elasticsearch搜索引擎索引成功后，再进行具体分表的读写操作。

业务系统对逻辑表的每一次读写请求都会导致Elasticsearch搜索引擎的查询，所以引入Redis缓存机制。

业务系统发起逻辑表读写请求后，先查询Redis本地缓存系统中是否有对应的主键路由信息，如果有，则进行具体分表的读写操作；如果没有，则先根据路由规则生成对应的路由ID，再持久化到Elasticsearch搜索引擎中，同时缓存到Redis本地缓存系统中，再进行具体分表的读写操作。

该分库分表路由系统，包括业务系统、Elasticsearch搜索引擎和Redis本地缓存系统；

所述业务系统负责根据自身业务需求预估数据量，规划路由规则构成维度，在业务系统分表配置中扩展路由规则，得到多维度路由ID；

所述Elasticsearch搜索引擎负责实现多维度路由ID的持久化；

所述Redis本地缓存系统负责实现多维度路由ID的缓存；

所述Elasticsearch搜索引擎和Redis本地缓存系统为业务系统亿级数量提供高并发读写支持。

所述路由规则构成维度包括但不限于时间维度、区域维度和平均分表维度。

该分库分表路由系统，采用Mysql数据库或HBase数据库替代Elasticsearch搜索引擎，实现多维度路由ID的持久化。

以上所述的实施例，只是本发明具体实施方式的一种，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。