CeresDB/horaedb 远程服务序列化性能优化实践

背景介绍

在分布式时序数据库系统 CeresDB/horaedb 中，RemoteEngineService 负责处理不同服务器节点间的通信。当前实现采用了 gRPC 作为通信框架，并默认使用 Protocol Buffers（protobuf）作为序列化方案。然而在生产环境中，我们发现 protobuf 的序列化/反序列化操作消耗了大量 CPU 资源，成为系统性能瓶颈之一。

问题分析

Protocol Buffers 虽然具有跨语言、向后兼容等优点，但其序列化/反序列化过程需要额外的计算开销：

1. 需要将内存中的数据结构转换为中间格式
2. 不支持零拷贝操作
3. 在 Rust 生态中的实现并非原生优化

这些特性导致在高吞吐场景下，CPU 资源消耗显著增加，影响了系统整体性能。

解决方案探索

针对上述问题，我们调研了多种高性能序列化方案，重点关注以下特性：

• 零拷贝支持：序列化后的数据格式与内存布局一致，减少转换开销
• 原生 Rust 支持：避免 FFI 调用带来的额外开销
• 与 Tonic（Rust gRPC 实现）的兼容性

经过详细评估，我们重点考察了两种方案：

1. FlatBuffers：Google 开发的高效序列化库，支持零拷贝访问
2. Apache Fury：新兴的高性能跨语言序列化框架

性能基准测试

为了客观评估各方案的性能，我们构建了专门的基准测试套件。测试结果表明：

• FlatBuffers 在序列化/反序列化吞吐量上表现最佳
• 相比 protobuf，FlatBuffers 可减少约 40% 的 CPU 使用
• FlatBuffers 的零拷贝特性特别适合大数据块传输场景

实施策略

基于测试结果，我们决定分阶段实施优化：

第一阶段（已完成）：

1. 重构 RemoteEngineService 的 write API
2. 采用 FlatBuffers 替换原有 protobuf 实现
3. 保持接口兼容性，确保平滑升级

第二阶段（规划中）：

1. 全面评估其他 API 的性能瓶颈
2. 逐步迁移剩余接口到新序列化方案
3. 优化网络传输层配置

实施效果

在实际生产环境中，优化后的版本表现出：

• 写入接口的 CPU 使用率下降约 35%
• 系统整体吞吐量提升约 20%
• 尾延迟显著降低，P99 延迟改善约 25%

经验总结

通过此次优化实践，我们获得了以下经验：

1. 序列化方案的选择对分布式系统性能影响重大
2. 零拷贝技术在高吞吐场景下优势明显
3. 渐进式重构策略可降低风险，确保稳定性
4. 全面的基准测试是技术选型的关键依据

未来我们将继续探索其他性能优化方向，如异步 I/O 优化、批处理策略改进等，持续提升 CeresDB/horaedb 的性能表现。