本篇文章主要从项目中实际场景出发,讲解分库分表等功能在日常运维中遇到的问题,以及 ShardingSphere-Proxy 对应的解决方案,版本号:v5.1.0。
如无特别声明,以下示例中的数据库指 MySQL。
正文开始之前,向大家推荐一款新开源的商城项目。基于 DDD 领域驱动模型,代码设计优雅,涵盖商城核心业务。内置分布式锁、分布式事务、分库分表、消息队列、数据搜索、服务监控等功能。
这个项目做什么
ShardingSphere-Proxy,可以让用户像使用原生数据库一样使用 Apache ShardingSphere。
了解一项技术的开始,一般从官网开始。先来看一看官网对 ShardingSphere-Proxy 的定义是什么样的:
定位为透明化的数据库代理端,提供封装了数据库二进制协议的服务端版本,用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL(兼容 openGauss 等基于 PostgreSQL 的数据库)版本,它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如:MySQL Command Client, MySQL Workbench, Navicat 等)操作数据,对 DBA 更加友好。
先明确一个概念,ShardingSphere-Proxy 是一个服务进程。从客户端程序连接来说,它和 MySQL 数据库并没有什么区别。
为什么要用 Proxy
在做了分库分表或其他规则的情况下,数据会分散到多个数据库实例上,在管理上难免会有一些不便;或者使用非 Java 语言的开发者,需要 ShardingSphere 所提供的能力…… 以上这些情况,正是 ShardingSphere-Proxy 力所能及之处。
1. Proxy 应用场景
日常工作中,大家使用 ShardingSphere-JDBC 进行分库分表的场景是比较多的。假设你有一张用户表,通过用户 ID 以 Hash 的方式进行了水平分库,那么此时客户端连接数据库的方式是这样:
我们举例工作中真实存在的几个场景:
- 测试同学想看下用户 ID 123456 的信息在数据库表里情况,需要你提供下用户在哪一张分表;
- 公司领导需要技术提供一份 2022 年用户的增长总量以及用户信息;
- 公司举行 8 周年活动,需要技术提供一份注册日期超过 8 周年的活跃老用户名单。
因为数据分库分表后,数据是散落在不同的库表中,对于上述的场景实现并不容易;如果为了实现类似临时需求,每次都需要开发代码,显得有些笨重。这个时候就需要文章主角 ShardingSphere-Proxy 登场了。
ShardingSphere-Proxy 隐藏了后端实际数据库,对于客户端来说就是在使用一个数据库,不需要关心 ShardingSphere 如何协调背后的数据库,对于使用非 Java 语言的开发者或 DBA 更友好。
比如说 t_user 在数据库层面拆分为若干真实表:t_user_0
到 t_user_9
,在客户端操作 ShardingSphere-Proxy 的过程中,只会知道有一张 t_user 逻辑表,路由至真实表的过程都在 ShardingSphere-Proxy 内部执行。
- 逻辑表:相同结构的水平拆分数据库(表)的逻辑名称,是 SQL 中表的逻辑标识。 例:用户数据根据主键尾数拆分为 10 张表,分别是
t_user_0
到t_user_9
,他们的逻辑表名为t_user
。 - 真实表:在水平拆分的数据库中真实存在的物理表。 即上个示例中的
t_user_0
到t_user_9
。