ShardingSphere-Proxy 数据库协议交互解读

最新推荐文章于 2025-07-16 22:00:00 发布

原创

最新推荐文章于 2025-07-16 22:00:00 发布 · 832 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #java #mysql #ShardingSphere #网络协议

本文介绍了数据库协议在MySQL、PostgreSQL中的特点，如MySQL的XProtocol和批处理优化，PostgreSQL的Pipelining支持。ShardingSphere-Proxy作为接入端，提供了统一的数据库访问入口，支持多种客户端和语言。文章还探讨了ShardingSphere-Proxy的交互流程，包括前端协议处理和后端JDBC执行，并给出了如何反馈Proxy协议问题的方法。

数据库协议对于大部分开发者来说算是比较冷门的知识，一般的用户、开发者都是通过现成的数据库客户端、驱动使用数据库，不会直接操作数据库协议。不过，对数据库协议的特点与流程有一些基本的了解，有助于开发者在排查数据库功能、性能问题的过程中提供一些发现问题的思路。

本文将简要介绍常用的 MySQL、PostgreSQL 等开源数据库协议的特点，并大致解读 ShardingSphere-Proxy 与客户端在数据库协议层面的交互。

文章目录

ShardingSphere 接入端介绍

Apache ShardingSphere 由 ShardingSphere-JDBC 和 ShardingSphere-Proxy 这 2 款既能够独立部署，又支持混合部署配合使用的产品组成。它们均提供标准化的基于数据库作为存储节点的增量功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。

在这里插入图片描述

ShardingSphere-JDBC 是一套基于 Java 开发的、实现了标准 JDBC 的 SDK，具备轻量级、高性能等特点，但局限性同样也很明显。不过，ShardingSphere-JDBC 在接入方面的局限性，在接入端 ShardingSphere-Proxy 得以解决：

ShardingSphere-Proxy 理论上支持通过任何数据库客户端、数据库驱动连接，不受限于 Java 等基于 JVM 的语言；
简化数据管理。尤其在使用数据分片或加密等功能的场景，使用 ShardingSphere-Proxy 作为统一入口操作数据，无须考虑数据实际存储的节点或手动进行解密等；
提供统一运维管控能力。集群模式下，可以使用 ShardingSphere-Proxy 统一管理 ShardingSphere 规则与配置；
可执行重量级操作。ShardingSphere-JDBC 与应用在同一进程内，重量级计算和 I/O 操作可能会影响应用性能；而 ShardingSphere-Proxy 作为独立进程启动，支持水平扩展，执行重量级操作不影响应用性能。

数据库协议特点简要介绍

目前互联网上已有不少关于 MySQL 或 PostgreSQL 协议的具体解读，本文不再详细介绍，本节主要介绍各数据库协议的特点，例如协议对 Pipelining 的支持、批量操作在协议的体现等。

MySQL 协议

MySQL 协议是典型的“一问一答”协议，例如使用 Prepared Statement 执行一条 SQL，在协议层面需要分别执行 COM_STMT_PREPARE 和 COM_STMT_EXECUTE：
在这里插入图片描述

图片来源 MySQL 文档 https://dev.mysql.com/doc/dev/mysql-server/latest/mysqlx_protocol_use_cases.html

MySQL 自 5.7.12 起增加了一个 X Plugin，让 MySQL 在保持原本关系型存储的基础上，增加了文档类型存储的支持。
X Plugin 使用了一套新的通讯协议 X Protocol，默认使用端口 33060，协议支持 pipelining，即客户端一次可以发送一批命令给客户端，减少“一问一答”的模式带来的 RTT（Round-trip time，来回通讯延时）。例如使用 Prepared Statement 执行一条 SQL，在协议层面分为 Prepare 和 Execute 步骤，但在网络传输层面上，这两个步骤可以合并发送。相比原来的协议，理论上能够减少一次 RTT。
在这里插入图片描述
图片来源 MySQL 文档 https://dev.mysql.com/doc/dev/mysql-server/latest/mysqlx_protocol_use_cases.html

不过，目前 MySQL 的 X Plugin 看起来并没有流行的趋势，大多数场景下客户端和服务端还是基于原本的 MySQL 协议进行通讯。
在批量操作的场景下，MySQL 协议执行 Prepared Statement 语句的命令 COM_STMT_EXECUTE 每次只能发送一组参数，“一问一答”的方式显得效率有些低下：
在这里插入图片描述
图片来源 MySQL 文档 https://dev.mysql.com/doc/dev/mysql-server/latest/mysqlx_protocol_use_cases.html

协议本身设计对批量操作的不支持，只能在客户端层面对批量操作进行优化。

以 MySQL Connector/J 为例，参数 rewriteBatchedStatements 启用后，MySQL Connector/J 内部会把通过 addBatch 方法设置的多组参数，合并 insert values 或将 update / delete 组成多语句，在协议层面一次性发送。通过增加少量 CPU 的开销，换取 RTT 的减少。

例如，对一个 Prepared Statement insert 语句，添加多组参数执行：