ShardingSphere-Proxy：从实际场景出发，快速上手（一）

本篇文章主要从项目中实际场景出发，讲解分库分表等功能在日常运维中遇到的问题，以及 ShardingSphere-Proxy 对应的解决方案，版本号：v5.1.0。

如无特别声明，以下示例中的数据库指 MySQL。

一、这个项目做什么
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 的方式进行了水平分库，那么此时客户端连接数据库的方式是这样：

 
我们举例工作中真实存在的几个场景：

1. 测试同学想看下用户 ID 123456 的信息在数据库表里情况，需要你提供下用户在哪一张分表；
2. 公司领导需要技术提供一份 2022 年用户的增长总量以及用户信息；
3. 公司举行 8 周年活动，需要技术提供一份注册日期超过 8 周年的活跃老用户名单。

因为数据分库分表后，数据是散落在不同的库表中，对于上述的场景实现并不容易；如果为了实现类似临时需求，每次都需要开发代码，显得有些笨重。这个时候就需要文章主角 ShardingSphere-Proxy 登场了。

ShardingSphere-Proxy 隐藏了后端实际数据库，对于客户端来说就是在使用一个数据库，不需要关心 ShardingSphere 如何协调背后的数据库，对于使用非 Java 语言的开发者或 DBA 更友好。

比如说 t_user 在数据库层面拆分为若干真实表：t_user_0 到 t_user_9，在客户端操作 ShardingSphere-Proxy 的过程中，只会知道有一张 t_user 逻辑表，路由至真实表的过程都在 ShardingSphere-Proxy 内部执行。

1. 逻辑表：相同结构的水平拆分数据库（表）的逻辑名称，是 SQL 中表的逻辑标识。 例：用户数据根据主键尾数拆分为 10 张表，分别是 t_user_0 到 t_user_9，他们的逻辑表名为 t_user。
2. 真实表：在水平拆分的数据库中真实存在的物理表。 即上个示例中的 t_user_0 到 t_user_9。
    

2. JDBC 和 Proxy 的区别
看了上面的描述，怎么感觉 ShardingSphere-Proxy 和 ShardingSphere-JDBC 这么像，两者有什么区别？

简单总结下两者的不同：

1. ShardingSphere-JDBC 是一个 Jar 包，底层通过重写 JDBC 组件完成 SQL 解析、路由、改写、执行等流程；需要在项目中添加对应功能的配置文件，对应用有一定侵入性；
2. ShardingSphere-Proxy 是一个进程服务，大部分情况下定位为辅助开发运维的效率工具。它将自己伪装为数据库，应用对接后对代码是无侵入的；对 SQL 的执行逻辑同 ShardingSphere-JDBC 一致，两者复用同一内核。

ShardingSphere-Proxy 既然对应用无侵入，而且两者复用同一内核，那为什么大家还要用 ShardingSphere-JDBC 呢？

1. 应用通过 ShardingSphere-JDBC 是直接操作数据库，相当于只有一次网络 IO；而应用连接 ShardingSphere-Proxy 是一次网络 IO，ShardingSphere-Proxy 再操作数据库，又会发生一次网络 IO；
2. 应用调用链路多了一层，容易形成流量瓶颈，对应用增加了潜在的风险；一般来说，应用程序会搭配 ShardingSphere-JDBC 使用。

当然，ShardingSphere-JDBC 和 ShardingSphere-Proxy 可以进行混合部署，ShardingSphere-JDBC 适用于 Java 开发的高性能的轻量级 OLTP 应用，ShardingSphere-Proxy 适用于 OLAP 应用以及对分片数据库进行管理和运维的场景。

文章转自公众号：龙台的技术笔记