数据库协议对于大部分开发者来说算是比较冷门的知识,一般的用户、开发者都是通过现成的数据库客户端、驱动使用数据库,不会直接操作数据库协议。不过,对数据库协议的特点与流程有一些基本的了解,有助于开发者在排查数据库功能、性能问题的过程中提供一些发现问题的思路。
本文将简要介绍常用的 MySQL、PostgreSQL 等开源数据库协议的特点,并大致解读 ShardingSphere-Proxy 与客户端在数据库协议层面的交互。
文章目录
- ShardingSphere 接入端介绍
- 数据库协议特点简要介绍
- MySQL 协议
- PostgreSQL 协议
- openGauss 协议
- ShardingSphere-Proxy 前端交互流程解读
- ShardingSphere-Proxy 与数据库协议的关系
- 接入端整体流程
- ShardingSphere-Proxy 前端流程
- 如何向 ShardingSphere 社区反馈疑似 Proxy 协议问题?
- 问题复现方式简单的可提供 Demo
- 直接提交问题修复 PR
- 使用抓包工具捕获客户端与 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 语句,添加多组参数执行:
INSERT INTO tbl VALUES (?, ?, ?);
addBatch [1, "foo", "bar"]
addBatch [2, "baz", "fuz"]
MySQL Connector/J 实际执行的语句:
INSERT INTO tbl VALUES (1, "foo", "bar"),(2, "baz", "fuz");
对于批量 update / delete,MySQL Connector/J 会通过 COM_QUERY 执行多语句,例如:
UPDATE tbl SET name = ? WHERE id = ?;
addBatch ["foo", 1]
addBatch ["bar", 2]
MySQL Connector/J 实际执行的语句:
UPDATE tbl SET name = "foo" WHERE id = 1;UPDATE tbl SET name = "bar" WHERE id = 2;
PostgreSQL 协议
与 MySQL 协议相比,PostgreSQL 协议定义看起来会更简单一些,而且 PostgreSQL 协议支持 Pipelining。
PostgreSQL 的 Extended Query 将 SQL 执行拆解为多个步骤,常用的几个操作有:
- Parse:SQL 解析为 Prepared Statement;
- Describe:获取 Prepard Statement 或 Portal 的元数据;
- Bind:Prepared Statement 绑定实际参数,产生可执行的 Portal;
- Execute:执行 Portal;
- Close:关闭 Prepared Statement 或 Portal。
PostgreSQL JDBC 与数据库的协议交互示例如下:
在批量操作的场景下,客户端可以将多组参数以连续的 Bind、Execute 一次性发送,虽然在协议层上是多个数据包,但在 TCP 传输层面,每次可以发送一批数据包出去。
支持 Pipelining 的协议,结合 I/O 多路复用,在吞吐量上存在一定的优势。例如基于多路复用 I/O 的数据库驱动 Vert.x PostgreSQL 曾在 TechEmpower Benchmark 第 15 轮测试的 Single Query 场景(数据库点查)得到第一名的成绩。
图片来源 https://www.techempower.com/benchmarks/#section=data-r15&test=db
openGauss 协议
openGauss 在沿用 PostgreSQL Protocol 3.0 的情况下,增加了一个 Batch Bind 的消息。PostgreSQL 协议的 Bind 消息一次只能发送一组参数,openGauss 新增的 Batch Bind 支持同时发送多组参数。
另外,openGauss 在认证安全性方面进行了增强。协议总体流程与 PostgreSQL 一致。
ShardingSphere-Proxy 前端交互流程解读
ShardingSphere-Proxy 与数据库协议的关系
数据库协议如同 HTTP 等协议,是客户端与服务端之间通讯的标准。每个数据库都定义了自己的协议,例如 MySQL 数据库定义了一套自己的协议,还有基于 Protobuf 的 X Protocol;PostgreSQL 也定义了一套自己的协议……
一般用户或开发者都是使用现成的客户端或相应的驱动,协议对于他们来说相对透明。因此,ShardingSphere-Proxy 实现数据库协议并以此对外提供服务,对于用户来说,使用 ShardingSphere-Proxy 就如同使用数据库一样。
目前,ShardingSphere-Proxy 支持的数据库协议具体版本为:
- MySQL Protocol 4.1(自 MySQL 4.1 起)
- PostgreSQL Protocol 3.0(自 PostgreSQL 7.4 起)
- openGauss Protocol 3.00 / 3.50 / 3.51
接入端整体流程
ShardingSphere-Proxy 与 ShardingSphere-JDBC 共用 ShardingSphere 内核模块,对用户提供了不同的接入方式。ShardingSphere-Proxy 是一个独立进程存在,以数据库协议对外提供服务;ShardingSphere-JDBC 是一套 SDK,用户直接通过代码调用。
ShardingSphere-Proxy 前端流程
ShardingSphere-Proxy 前端使用 Netty 实现数据库协议。基于 Netty 事件驱动的方式处理前端连接,让 ShardingSphere-Proxy 前端可以维护较大数量的客户端连接。协议的拆包、编码逻辑主要在 Netty EventLoop 线程内执行。由于 ShardingSphere-Proxy 后端仍然使用 JDBC 与数据库交互,为避免 Netty EventLoop 线程阻塞,协议数据拆包后,会使用专门的线程池执行 ShardingSphere 内核逻辑、数据库交互。
PacketCodec 主要进行数据的拆包和编码。在前面的数据库协议介绍提到,PostgreSQL 协议支持 pipelining,能够一次发送一批数据包。
示例:下图是 PostgreSQL 客户端使用 Prepared Statement 执行 select current_schema()
语句所对应的请求协议。Prepared Statement 的 SQL 解析、执行等步骤,由客户端一次性发送给服务端执行。
服务端接收到的就是一串字节流,如何能够把这一串字节流拆分为多个协议包?
以 PostgreSQL 协议格式为例,除了 Startup Message,每个协议包的格式都是 1 字节消息类型 + 4 字节数据长度(包含长度自身)+ 数据,结构如下:
MySQL 协议数据包格式与此相似。
PacketCodec 只需遵循协议格式定义,即可把接收到的字节流正确拆分。
字节流拆分后,剩余的步骤就是按照数据库协议解析数据,得到要执行的 SQL 与参数。有了 SQL 与参数后,剩余的执行流程就与通过 ShardingSphere-JDBC 执行 SQL 基本一致。
ShardingSphere-Proxy 后端通过 JDBC 执行 SQL 后,得到的结果集为 Java 对象,PacketCodec 会调用具体的编码逻辑,将 Java 对象按照数据库协议转换为字节流,组装成数据包后响应客户端。
以上就是 ShardingSphere-Proxy 前端数据库协议交互的大致流程。
如何向 ShardingSphere 社区反馈疑似 Proxy 协议问题?
由于 ShardingSphere-Proxy 与数据库的计算能力存在差异,Proxy 对数据库协议的实现尚未达到 100% 的支持度,在使用过程中难免会存在一些不支持的情况,且不支持的情况在不同的数据库客户端、数据库驱动之间存在一定差异。
当用户在使用 Proxy 的过程中,遇到疑似 Proxy 协议实现不完善导致的问题,本文给出一些反馈问题的建议。
问题复现方式简单的可提供 Demo
如果遇到的问题,能够通过构造出简单的代码复现(例如只需使用 Python 语言并安装一些简单的依赖),可以在 issue 中直接提供复现问题的代码与步骤。
案例:社区同学曾经提交过一个 Django.db 连接 ShardingSphere-Proxy MySQL 的事务问题 https://github.com/apache/shardingsphere/issues/18461
作者在 issue 中提供了复现的方式,为 ShardingSphere 团队修复该问题提供了帮助。
直接提交问题修复 PR
对于一些相对简单的问题,ShardingSphere 团队可以提供修复的思路,有条件的社区同学可以考虑直接提交 PR 修复。
案例:社区同学反馈了一个通过 Python asyncpg 连接 ShardingSphere-Proxy 报错的问题:https://github.com/apache/shardingsphere/issues/23885
该问题为 Python asyncpg 数据库驱动在向 ShardingSphere-Proxy 发送 client_encoding 时,在编码名称上增加了引号。由于 ShardingSphere-Proxy PostgreSQL 没有考虑到编码名称包含引号的情况(PostgreSQL 数据库支持这种情况),导致编码识别报错。
Issue 作者已经具备了复现问题的条件,加上作者具备修复该问题的技能,便在 ShardingSphere 团队的指导下,直接提交了 PR 修复该问题。
使用抓包工具捕获客户端与 Proxy 的通讯流量
对于一些使用异构语言的用户,在使用 ShardingSphere-Proxy 过程中可能会遇到和具体功能不相关、疑似协议层面的问题。由于用户与 ShardingSphere 团队存在技术栈上的差异,ShardingSphere 团队可能无法快速在本地完成问题的复现。此时可以考虑通过捕捉客户端与 ShardingSphere-Proxy 之间网络流量的方式,向 ShardingSphere 社区反馈问题。
抓包工具可以选择 Wireshark 或 tcpdump。工具的使用互联网上有大量资料,本文不展开介绍。
案例:社区同学前段时间提交了一个 .NET MySqlConnector 使用 ShardingSphere-Proxy 报错的问题:
https://github.com/apache/shardingsphere/issues/23857
Issue 中反馈了一个 .NET 连接 ShardingSphere-Proxy 报错的问题,根据堆栈,该报错是在 TryResetConnectionAsync
期间导致的,而且最后抛出异常的地方是在 Protocol 相关代码下,所以这可能是一个 ShardingSphere-Proxy 协议实现与 MySQL 表现不一致导致的问题。
An error occurred using the connection to database .....
MySqlConnector.MySqlProtocolException: Packet received out-of-order. Expected 1; got 2.
at MySqlConnector.Protocol.Serialization.ProtocolUtility.<DoReadPayloadAsync>g__AddContinuation|5_0(ValueTask`1 readPacketTask, BufferedByteReader bufferedByteReader, IByteHandler byteHandler, F
unc`1 getNextSequenceNumber, ArraySegmentHolder`1 previousPayloads, ProtocolErrorBehavior protocolErrorBehavior, IOBehavior ioBehavior) in /_/src/MySqlConnector/Protocol/Serialization/ProtocolUtility.cs:
line 476
at MySqlConnector.Core.ServerSession.ReceiveReplyAsyncAwaited(ValueTask`1 task) in /_/src/MySqlConnector/Core/ServerSession.cs:line 943
at MySqlConnector.Core.ServerSession.TryResetConnectionAsync(ConnectionSettings cs, MySqlConnection connection, IOBehavior ioBehavior, CancellationToken cancellationToken) in /_/src/MySqlConnect
or/Core/ServerSession.cs:line 616
由于该问题的复现具备一定的环境搭建成本,不便于 ShardingSphere 团队在本地复现问题,社区同学也提供了客户端与 Proxy 之间协议通讯流量。
根据协议抓包结果,ShardingSphere 团队立即确认了该问题为 ShardingSphere-Proxy MySQL 数据包编码逻辑实现问题。
🔗 官方网站:
https://shardingsphere.apache.org
🔗 GitHub:
https://github.com/apache/shardingsphere
🔗 Slack:
https://apacheshardingsphere.slack.com