网站建设算固定资产吗,韶关市建设局网站,企业营销策划实现的途径,建站公司人员配置数据库协议对于大部分开发者来说算是比较冷门的知识#xff0c;一般的用户、开发者都是通过现成的数据库客户端、驱动使用数据库#xff0c;不会直接操作数据库协议。不过#xff0c;对数据库协议的特点与流程有一些基本的了解#xff0c;有助于开发者在排查数据库功能、性…数据库协议对于大部分开发者来说算是比较冷门的知识一般的用户、开发者都是通过现成的数据库客户端、驱动使用数据库不会直接操作数据库协议。不过对数据库协议的特点与流程有一些基本的了解有助于开发者在排查数据库功能、性能问题的过程中提供一些发现问题的思路。
本文将简要介绍常用的 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即客户端一次可以发送一批命令给客户端减少“一问一答”的模式带来的 RTTRound-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 / deleteMySQL 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 执行拆解为多个步骤常用的几个操作有
ParseSQL 解析为 Prepared StatementDescribe获取 Prepard Statement 或 Portal 的元数据BindPrepared Statement 绑定实际参数产生可执行的 PortalExecute执行 PortalClose关闭 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/#sectiondata-r15testdb
openGauss 协议
openGauss 在沿用 PostgreSQL Protocol 3.0 的情况下增加了一个 Batch Bind 的消息。PostgreSQL 协议的 Bind 消息一次只能发送一组参数openGauss 新增的 Batch Bind 支持同时发送多组参数。 另外openGauss 在认证安全性方面进行了增强。协议总体流程与 PostgreSQL 一致。
ShardingSphere-Proxy 前端交互流程解读
ShardingSphere-Proxy 与数据库协议的关系
数据库协议如同 HTTP 等协议是客户端与服务端之间通讯的标准。每个数据库都定义了自己的协议例如 MySQL 数据库定义了一套自己的协议还有基于 Protobuf 的 X ProtocolPostgreSQL 也定义了一套自己的协议……
一般用户或开发者都是使用现成的客户端或相应的驱动协议对于他们来说相对透明。因此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.DoReadPayloadAsyncg__AddContinuation|5_0(ValueTask1 readPacketTask, BufferedByteReader bufferedByteReader, IByteHandler byteHandler, F
unc1 getNextSequenceNumber, ArraySegmentHolder1 previousPayloads, ProtocolErrorBehavior protocolErrorBehavior, IOBehavior ioBehavior) in /_/src/MySqlConnector/Protocol/Serialization/ProtocolUtility.cs:
line 476at MySqlConnector.Core.ServerSession.ReceiveReplyAsyncAwaited(ValueTask1 task) in /_/src/MySqlConnector/Core/ServerSession.cs:line 943at 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
