# 用 Rust FFI 替换 Protobuf：PgDog 序列化性能优化实践 > 剖析 PgDog 如何通过直接 C-Rust 绑定替换 Protobuf 序列化，实现 5 倍解析性能提升的工程路径。 ## 元数据 - 路径: /posts/2026/01/23/pgdog-rust-ffi-protobuf-replacement/ - 发布时间: 2026-01-23T23:46:51+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 PgDog 是一个面向 PostgreSQL 的水平扩展代理，其核心职责是解析和理解 SQL 查询以实现自动分片等功能。在技术选型上，PgDog 采用 Rust 编写，通过 libpg_query C 库与 PostgreSQL 解析器交互。最初的设计使用 Protobuf 作为 Rust 与 C 之间的序列化层，这一选择保证了跨语言绑定的一致性，却在性能敏感的代理场景中造成了显著的开销。本文深入剖析 PgDog 团队如何通过直接 C-to-Rust 绑定替换 Protobuf，最终实现解析性能提升 5 倍、去解析性能提升近 10 倍的工程实践。 ## 性能瓶颈的发现：采样分析定位热点 任何性能优化工作的起点都应该是精确的瓶颈定位。PgDog 团队使用 samply 作为采样分析工具，该工具与 Firefox profiler 深度集成，能够通过每秒数千次的调用栈采样，高频统计各函数消耗的 CPU 时间比例。这种方法不依赖代码插桩，对运行时性能影响极小，非常适合在线服务的性能诊断。 通过 samply 生成的火焰图，团队定位到 `pg_query_parse_protobuf` 函数占据了解析流程的绝大部分时间。这个函数是所有 pg_query 绑定的统一入口，但真正执行 PostgreSQL 语法解析的 `pg_query_raw_parse` 在火焰图中几乎不可见。这一发现颠覆了直觉：SQL 解析本身经过数十年优化已经非常高效，真正的瓶颈在于 Protobuf 序列化与反序列化过程。 火焰图的参数视图清晰地展示了 Protobuf 序列化在各类型节点上的开销分布。对于一个需要处理大量并发查询的代理服务而言，这种固定开销会在高 QPS 场景下被急剧放大。团队意识到，单纯优化解析算法或缓存查询结果无法从根本上解决问题，必须从序列化层的架构层面寻求突破。 ## 缓存策略的尝试与局限性 面对已识别的高开销环节，团队首先尝试了缓存方案。这一策略的核心思想是用空间换时间：将解析后的抽象语法树缓存于内存中，避免对相同结构查询的重复解析。具体实现采用 LRU 淘汰策略的哈希表作为缓存后端，使用查询文本本身作为键，解析结果作为值。 缓存方案在prepared statement场景下效果显著。多数应用程序使用参数化查询，查询模板如 `SELECT * FROM users WHERE id = $1` 保持不变，仅参数值变化。这意味着相同的查询模板可以复用缓存的 AST，大幅降低解析频率。初步测试显示缓存命中率较高，性能有可观提升。 然而，缓存策略很快遇到两类难以回避的边界情况。第一类是 ORM 工具的缺陷实现：某些 ORM 会生成大量结构独特的查询，例如将 `value IN ($1, $2, $3)` 展开为独立参数而非使用 `value = ANY($1)` 数组语法，导致相同业务含义的查询产生数千种文本变体，缓存失去意义。第二类是老旧客户端驱动的不兼容问题：Python 的 psycopg2 等广泛使用的驱动不支持预处理语句，所有查询都以完整文本形式发送，缓存命中率急剧下降。 这些边界情况暴露了纯缓存方案的脆弱性：它无法覆盖所有真实工作负载，且在缓存失效时仍需承担完整的序列化开销。团队意识到，必须从根本上消除 Protobuf 序列化这一固定开销源，才能获得稳定可靠的性能收益。 ## 直接绑定的技术方案：bindgen 与 AI 辅助代码生成 确定目标后，团队着手将 Protobuf 序列化层替换为直接的 C-Rust 绑定。这一工作的核心挑战在于：PostgreSQL 的 AST 结构极其复杂，包含数百种节点类型，类型间的层级关系和指针引用错综复杂，手工编写完整的转换代码既耗时又容易出错。 方案利用了三个有利条件作为实施基础。其一，pg_query 本身提供了完整的 Protobuf 规范文档，Claude 能够从中提取所有结构定义和预期数据类型。其二，pg_query.rs 已集成 bindgen 工具，只需调整配置即可将 AST 结构体纳入 bindgen 的输出范围。其三，原有的 Protobuf 实现提供了完整的参考实现和测试用例，可作为新实现的验证基准。 团队采用 AI 辅助的方式完成绑定代码生成。初始提示简洁明确：要求 Claude 将 Protobuf 替换为 bindgen 生成的 Rust 结构体，实现与 Postgres AST 的直接映射。经过两天的迭代调优，Claude 生成了约 6000 行递归 Rust 代码，涵盖 `parse`、`deparse`、`fingerprint`、`scan` 四个核心方法。这四个方法在 PgDog 的分片、查询重写等关键路径中高频调用，优化收益可直接传导至整体系统性能。 实现细节上，转换代码使用 `unsafe` Rust 函数包装 C 结构体指针，将 C 类型直接传递给 libpg_query API 完成 AST 构造。返回时采用递归算法遍历 AST 树：每个节点对应一个转换函数，接收不安全的 C 指针并返回安全的 Rust 结构体。AST 以数组形式存储在内存中，递归算法逐个处理列表元素，对包含子节点的节点递归调用转换函数，直至抵达叶子节点。 对于标量类型数据如整数和字符串，算法直接复制到对应的 Rust 类型。对于复合节点，算法首先检查指针是否为 null（防御性编程），然后根据节点标签匹配具体的结构体类型，将 C 指针转换为 Rust 可访问的结构体实例。这种模式在数百种 SQL 语法节点上重复执行，最终组合成完整的 Rust AST 表示。 ## 机器可验证的测试策略与迭代优化 代码生成过程中最关键的一环是测试验证。团队利用 Rust 的 `PartialEq` 派生 trait，将 Protobuf 实现与直接绑定实现的输出进行字节级比较。对于每个测试用例，同时调用 `parse` 和 `parse_raw`，若两者结果存在任何差异，Claude Code 必须重新生成代码直至完全一致。 这种机器可验证的测试策略带来了双重保障。一方面，它确保了直接绑定实现的语义正确性不会劣于原有实现，避免了优化反而引入 bug 的风险。另一方面，它为 AI 代码生成提供了清晰的收敛标准：测试通过即表示代码可用，无需人工逐行审查数千行递归转换代码的正确性。 团队还尝试将递归算法改写为迭代实现以规避潜在的栈溢出风险，但测试结果显示迭代版本反而更慢。深入分析表明，迭代版本引入了额外的内存分配、哈希表查找和多轮树遍历开销。而递归算法每个 AST 节点恰好处理一次，完全利用程序启动时分配的栈空间，CPU 缓存局部性也更优——同一函数的连续调用使指令已预加载至 L1/L2 缓存。这一结果印证了递归在树结构转换场景中的天然优势。 ## 性能收益与工程启示 切换至直接绑定后的性能提升数据如下：解析吞吐量从每秒 613 次提升至 3357 次，提升幅度达 5.45 倍；去解析（将 AST 还原为 SQL 字符串）从每秒 759 次提升至 7319 次，提升近 10 倍。在 PgDog 的整体 pgbench 基准测试中，这一改动直接带来了约 25% 的性能提升。 从工程角度看，这一案例提供了若干可复用的经验。首先，跨语言绑定的序列化层开销在高频调用场景下可能成为主要瓶颈，尤其是当被调用方本身已高度优化时。其次，缓存策略虽然有效，但存在固有的覆盖面限制，无法替代对根本开销的消除。第三，AI 辅助代码生成在结构化、机器可验证的任务中表现出色，6000 行复杂代码的生成和调优在两天内完成。最后，递归算法在树结构转换中仍有独特价值，不应因对栈溢出的过度担忧而盲目采用迭代方案。 对于构建高性能数据库代理或中间件的团队而言，PgDog 的实践表明：精心设计的 FFI 边界可以直接传递 C 库的性能优势，同时保持 Rust 侧的安全性和表达能力。这种零拷贝设计思路值得在类似场景中借鉴。 --- **参考资料** - [Replacing Protobuf with Rust to go 5 times faster - PgDog](https://pgdog.dev/blog/replace-protobuf-with-rust) - [samply - Sampling Profiler](https://github.com/mstange/samply) ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。