ClickHouse Cloud团队将Postgres备份工具WAL-G用Rust重写为WAL-RUS，主要解决Go语言垃圾回收导致的内存不可预测问题，实现更高效、可预测的内存管理，同时保持与WAL-G的兼容性。

好的，这是根据您的要求，对原文进行中文重述和精简后的版本：

标题：我们为何用Rust重写Postgres备份工具WAL-G：WAL-RUS诞生记

在ClickHouse Cloud，Postgres的WAL归档是保障数据持久性和可恢复性的关键环节。WAL-G作为一款成熟可靠的备份工具，一直表现出色。然而，随着我们将Postgres部署到资源更受限的环境中，我们遇到了一个核心问题：内存使用的不确定性。

WAL-G基于Go语言开发，其垃圾回收机制虽然便于构建可靠软件，却导致内存占用难以预测。问题不仅在于常驻内存，更在于虚拟内存。Go运行时会预留远超实际需求的虚拟内存，其“锯齿状”的内存使用模式使得峰值消耗难以预估，给资源规划带来挑战。

对运维人员而言，这引出一个简单却重要的问题：究竟该为备份基础设施预留多少内存？ 答案往往是“宁多勿少”，但这部分预算无法分配给Postgres本身用于查询和缓存。由于Postgres在禁用内存过载时运行最稳定，虚拟内存成为了宝贵的资源。

我们并非认为WAL-G功能不足，它依然是久经考验的可靠工具。我们的目标是，在保持核心功能和兼容性的前提下，打造一个内存使用更可预测、资源消耗更低的备份系统。于是，WAL-RUS应运而生。

WAL-RUS是一个基于Rust的开源Postgres备份与WAL归档工具，其设计特点如下：

1. 可预测的资源使用：Rust提供了对内存分配和并发的直接控制。WAL-RUS通过有界的工作线程池和精细的并发管理，使内存消耗易于预估，减少了资源过度配置的需求。
2. 专为持续WAL归档设计：WAL-RUS采用守护进程架构，维护持久化的对象存储连接，持续处理后台归档请求，避免了为每个WAL文件新建进程和连接的开销。
3. 针对流式负载优化：WAL归档本质上是流式处理。WAL-RUS在整个流程中最小化不必要的缓冲和数据拷贝，从而以更小、更稳定的内存占用完成归档工作。
4. 与WAL-G兼容：WAL-RUS使用与WAL-G相同的WALG_配置变量，并经过持续测试确保互操作性。两者生成的归档文件可以互相读取，便于现有部署迁移。

性能基准测试

我们通过一个可复现的基准测试，在持续高负载下对比了WAL-RUS、WAL-G和pgBackRest的内存效率。所有工具均配置了四个并发归档工作线程。

• 内存效率：WAL-G的峰值虚拟内存接近2.8 GB，而WAL-RUS始终低于1 GB，降低了超过70%。WAL-RUS的内存曲线非常稳定，更易于在生产环境中规划资源。
• 归档吞吐量：WAL-RUS和WAL-G在整个测试中均能保持极小的积压，证明它们能跟上WAL生成速度。而pgBackRest在WAL活动高峰期出现了较大积压。
• CPU利用率：三者表现相当，主要消耗在LZ4压缩上。

总结

WAL-RUS旨在解决一个实际问题：以更小、更可预测的资源占用，提供可靠的PostgreSQL备份和WAL归档。它通过Rust的显式内存管理和守护进程流式架构，在保持与WAL-G相当的归档吞吐量的同时，显著降低了内存消耗。

重要的是，WAL-RUS完全兼容现有的WAL-G归档和配置，便于现有部署采用。我们计划将其作为ClickHouse Cloud中托管Postgres服务的默认备份机制。该项目已开源，欢迎反馈、测试和贡献。

根据评论内容，总结如下：

1. 性能与资源消耗的平衡性 - 主要观点：Go版本在CPU使用上仅增加1.5倍，内存/显存增加约2倍，性能损失可控。 - 关键引用： - "It does only use 1.5x the CPU and (predictably) much more RAM/VRAM, but not a crazy amount either (the expected increase is 2x)." - "Go is much easier to write and you don't pay for the convenience with an absurd performance loss like in Python or PHP"

2. 内存指标的具体质疑 - 主要观点：2.8GB峰值内存是虚拟内存还是常驻内存？Go会预分配大量虚拟内存但实际不占用物理内存。 - 关键引用： - "was the 2.8GB peak virtual or resident? Go reserves a large virtual arena it mostly never faults in" - "RSS tends to be a fraction of the virtual peak"

3. 混合事务场景的测试需求 - 主要观点：用户希望看到长事务与短事务混合的基准测试结果，因为WAL-E在此场景表现不佳。 - 关键引用： - "Do you have any benchmarks with a mix of long open transactions and short ones?" - "I've struggled a lot with WAL-E in the past there"

4. 命名混淆说明 - 主要观点：该项目与Supabase的WALRUS项目无关。 - 关键引用： - "PostgreSQL WAL-RUS, no relation to PostgreSQL WALRUS" - 附链接：https://github.com/supabase/walrus