使用 HTTP/3 提速 MySQL

在 PlanetScale，我们为用户提供基于 MySQL 的数据库服务。为了提供这一服务，保持与 MySQL 协议兼容是至关重要的，这允许用户使用 mysql-client 和任何支持 MySQL 的驱动程序操作数据库。
但如果我们不受这种限制呢？是否可以提供替代的接口和 API？

背景

在一些基础设施相关的项目中，我们需要为数据库引入新的 API 和连接特性。为支持无法通过 MySQL 协议实现的功能，我们决定开发一个面向公众的 HTTP API。尽管这个 API 目前尚未公布文档（未来一定会发布），它已经与 gRPC 兼容。
这个 HTTP 接口助力了我们的 JavaScript 无服务器驱动和 PlanetScale Connect 的开发。
在无服务器计算环境中，代码无法打开 TCP 套接字与 MySQL 二进制协议沟通。平台通常要求通过 HTTP(S) 进行通信，因此我们的 HTTP API 恰好符合这种需求。
有了这个 API，就引出了我的问题：

HTTP 是否可以比 MySQL 协议更快？

新 API 不仅仅支持 gRPC。具体来说，我们使用的是 connect-go，它与 gRPC 兼容并提供许多其他功能。其中一个功能是使用 HTTP/3 作为传输方式的潜力。通过 UDP 构建的 HTTP/3，让其具有了与传统 MySQL 二进制协议不同的特性。
我们理论假设新 API 在许多场景下将超越传统 MySQL 客户端，结果比预期还要令人惊讶。

实验设置

实验中，我们限定在 Go 环境下，通过开发一个支持数据库/sql 的自定义驱动，使用 protobuf 进行编码并通过 Snappy 进行压缩。然后将其与标准 MySQL 驱动进行比较。
对于 HTTP/2，我们使用 Go 标准库 HTTP 客户端；对于 HTTP/3，我们使用实验性的 quic-go 库。测试环境包括以下两种场景：

高延迟、低带宽：我的个人笔记本位于 Reno，NV，与数据库的地理距离较远。
低延迟、高带宽：一个位于 AWS us-west-2 的 EC2 实例，与数据库地理距离更近。

这两个场景旨在验证 HTTP，甚至 HTTP/3 在何时、何地以及是否相较于 MySQL 协议具有优势。

测试内容

从上述两个场景中，我们运行了以下测试，使用三种客户端对比：

MySQL 二进制协议客户端
使用 HTTP/2 的客户端（psdb）
使用 HTTP/3 的客户端（psdb + h3）

每种客户端运行以下七项测试：

Connect + SELECT 1：测试冷启动操作，逐次建立一个新连接并运行 SELECT 1。
Parallel SELECT 1：预热连接池，然后并行运行 SELECT 1。
Medium SELECT：从包含两列的表中读取 250 行（约为 50kb 数据）。
Medium INSERT：进行批量插入操作写入相同的数据集。
Large SELECT：从更大的表中读取 10000 行，11 列（约为 27.5mb 数据）。
Large INSERT：每次插入 2000 行。

这些测试旨在尝试覆盖场景，却不尝试对 PlanetScale 或底层 mysqld 进行实际性能基准测试。

测试结果

以下是测试的一些主要结论：

1. Connect + SELECT 1

冷启动测试结果显示，无论是高延迟还是低延迟场景，使用 HTTP 大幅优于 MySQL。

笔记本测试中，HTTP 的 min 降到了 35ms 左右，而 MySQL min 为 162ms。此外，HTTP 的 max 稳定，而 MySQL 的 max 波动较大。
在 AWS us-west-2 的 EC2 实例上，HTTP 的延迟从 11ms 降到了 3-4ms，显著优于 MySQL。

这很可能归因于 TLS 的差异：HTTP/2 和 HTTP/3 使用 TLS 1.3，而 MySQL 客户端较少支持 TLS 1.3，更常使用 TLS 1.2。TLS 1.3 支持 0-RTT 握手，节省了一个往返时间。

2. Parallel SELECT 1

测试中，高延迟场景下 HTTP/2 和 HTTP/3 展现出一定性能优势，而在低延迟场景下三者表现差异不明显。这表明即使在最快场景下，新 API 本身也未引入显著劣势。

3. Medium SELECT

在数据量较小时，结果趋于一致。高延迟场景中，HTTP 的尾部延迟略有改善，但低延迟场景完全受限于底层 mysqld 性能。

4. Medium INSERT

对于写操作，HTTP API 使用了客户端压缩，这使得其在高延迟场景下表现出明显的优势。

5. Large SELECT & Large INSERT

在更大的数据量下，高延迟场景中 HTTP 尤其是 HTTP/3 的表现开始显现优势。这可能是由于 QUIC 相较于 TCP 更擅长处理网络包丢失等问题。

总结

测试结果表明以下几点：

HTTP API 的强大性能：在大多数测试中，基于 HTTP 的解决方案优于 MySQL 协议，尤其是在高延迟和不可靠网络中表现更优。
冷启动性能显著改善：对于无服务器环境以及临时任务，减少连接和连接池创建的需求尤为关键。
HTTP/3 的潜力：尽管在某些场景下性能表现略不稳定，但长远来看，HTTP/3 是对 HTTP/2 的明确升级，在最坏情况下依然表现出优势。

目前，PlanetScale 已支持 HTTP/3。如果您使用产品中的 PlanetScale Web 控制台和现代浏览器，将默认通过 HTTP/3 连接。尽管 HTTP/3 目前在非浏览器环境中的采纳率较低，我们希望能推动这一领域的更广泛应用。未来几个月，我们会逐步发布有关 HTTP API 的更多文档，以探索更深层的优势以及其应用场景。

使用 HTTP/3 提速 MySQL插图