Golang - Tony Bai

本文永久链接 – https://tonybai.com/2025/07/22/cedardb-choose-cpp-rather-than-rust

大家好，我是Tony Bai。

近年来，Rust 语言无疑是技术圈最炙手可热的明星。它以“内存安全”的核心承诺，向统治了系统编程领域数十年的 C++ 发起了强有力的挑战。无数文章和布道者都在宣扬一个近乎“神话”的观点：用 Rust，你就能告别段错误和内存泄漏。

然而，就在这股“Rust 替换一切”的热潮中，一个来自行业核心的声音，给我带来了深深的思考。

Moritz Sichert，高性能数据库 CedarDB 的联合创始人兼 CEO，最近发表了一个“反直觉”的观点：

“Rust 是一门很棒的语言，我真的很喜欢用它。然而，当涉及到数据库系统时，我仍然会选择 C++ 而不是 Rust。”

一个数据库 CEO，在一个对数据安全和系统稳定性要求极致的领域，放弃了以“安全”著称的 Rust，转而拥抱充满了“历史遗留问题”的 C++。这究竟是为什么？

这并非一次简单的“厚此薄彼”，而是一场关于工程现实与语言哲学之间深刻权衡的精彩案例。

理论安全 vs 工程现实：unsafe 的“逃生舱口”

Moritz 首先承认了 Rust 的优点：理论上，Rust 通过其所有权系统和借用检查器，提供了远超 C++ 的默认安全性。这正是大家喜爱 Rust 的原因。

但问题在于，像 CedarDB 这样的高性能数据库，其开发工作远不止是处理业务逻辑。它需要深入到硬件的毛细血管中，榨干每一滴性能。这意味着：

使用大量底层的 CPU 特性。
实现复杂的侵入式数据结构。
进行带有验证的、乐观且激进的内存访问。

在这些场景下，Rust 的安全检查反而成了“束缚”。为了完成任务，你必须使用 Rust 提供的“逃生舱口”——unsafe 关键字。

而 Moritz 抛出的重磅炸弹正在于此：

“一旦你在 Rust 中写下 unsafe 代码，所有的赌注都将失效。在 unsafe 代码中，你遇到未定义行为（UB, Undefined Bahavior）的风险，甚至比在 C++ 中还要高。”

unsafe Rust：一个更危险的“黑暗森林”？

这个论断足以颠覆许多人的认知。unsafe Rust 怎么会比 C++ 还危险？

关键在于理解 unsafe 到底意味着什么。它不是简单地“关闭”安全检查，而是程序员向编译器立下了一个契约：“编译器，请相信我，接下来的这段代码，我将手动保证它完全遵守 Rust 的内存模型和别名规则（Aliasing Rules）。”

这正是问题的核心所在。
* C++ 的危险是“已知的”：C++ 就像一片广阔的雷区，但经过几十年的探索，老兵们已经绘制出了详细的“排雷图”。虽然处处是坑，但如何避免、如何调试，已经积累了大量的工程实践和模式。
* unsafe Rust 的危险是“微妙的”：unsafe 区域就像一个“黑暗森林”，你不仅要面对 C++ 程序员熟悉的裸指针、内存布局等问题，更要命的是，你还必须手动维护 Rust 那套比 C++ 更为严格的别名规则（例如，在任何给定时间，你只能有一个可变引用 &mut T，或者任意数量的不可变引用 &T，但不能两者都有）。

对于一位经验丰富的 C++ 开发者而言，在 unsafe 块里很容易不自觉地写出 C++ 风格的指针操作，却无意中违反了 Rust 的核心不变量，从而触发 UB。这种“新规则”下的自由，反而成了一个更容易跌落的陷阱。

Moritz 的观点是：在一个必须大量使用 unsafe 的项目中，与其在一个受严格规则约束的环境里“戴着镣铐跳舞”，不如直接选择那个虽然危险、但规则更为人熟知且自由度更高的 C++。

聊聊 Go：一种不同的安全哲学

那么，聊了这么多 Rust 和 C++，我们作为 Gopher 能从中得到什么启发呢？这恰好能让我们更深刻地理解 Go 的设计取舍。

Go 语言同样有一个 unsafe 包。但与 Rust 的设计哲学截然不同。

Rust 的 unsafe 是语言的一等公民，是其系统编程能力的重要组成部分，是为了实现“零成本抽象”而设计的必要工具。

而 Go 的 unsafe，从其文档的第一句话起，就在极力地“劝退”你：

“任何使用了 unsafe 包的程序都可能在未来 Go 语言版本中无法移植……使用 unsafe 的代码，其安全性需要程序员手动保证，我们不建议使用。”

在 Go 的世界里，unsafe 更像一个被严格限制的“后门”，而非一个功能特性。它的存在主要是为了实现标准库（如 runtime、sync），或在极少数与 C 库交互、进行极致性能微调的场景下使用。

我们可以这样总结三者的哲学：
* C++：默认给予你全部的权力与危险，安全是你的责任。
* Rust：默认提供极致的安全，但给你一个 unsafe 的选项，让你在立下严格契约为前提下重获权力。
* Go：默认通过 GC 和简单的内存模型提供高度的工程安全与效率，unsafe 是一个官方不鼓励、非标准的“应急方案”。

Go 的选择是，在绝大多数场景下，宁愿牺牲掉那部分通过复杂手动内存管理换来的极限性能，也要保证语言模型的简单性和大规模团队协作的工程效率与安全。

小结：没有神话，只有权衡

Moritz Sichert 的观点，并非是对 Rust 的全盘否定，更不是在鼓吹 C++ 的回归。

它有力地击碎了“Rust=绝对安全”的技术神话，揭示了一个冰冷的工程现实：在任何复杂的系统中，安全都是一个连续的光谱，而不是一个二元的开关。

当你的业务场景把你推向性能金字塔的顶尖，逼迫你大量使用 unsafe 时，Rust 的安全优势就会被削弱，其复杂的底层规则甚至可能成为新的风险来源。

这个案例告诉我们，技术选型永远没有“银弹”，只有基于特定问题、特定团队、特定目标的深刻权衡。作为开发者，我们最重要的能力，就是理解自己手中工具的设计哲学、优势边界以及它为之付出的代价。

对于绝大多数的后端服务、云原生应用而言，Go 和 Rust 提供的现代安全模型无疑是巨大的进步。但请记住，当有人在讨论“是否选择 C++”时，他可能不是在开历史的倒车，而是在思考一个我们尚未触及的、更深层次的工程问题。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/22/go-swiss-table-map-user-report

大家好，我是Tony Bai。

Datadog 的故事始于一次对Go 1.24内存回归问题的追踪。在与 Go 社区协作修复了该问题后，他们在部署修复版本的过程中，观察到了一个意料之外的现象：在高流量环境中，内存使用不仅恢复了正常，甚至大幅下降。一个名为 shardRoutingCache 的巨型内存 map，其堆内存占用减少了约 500 MiB，考虑到 Go 的垃圾回收机制（GOGC=100），这相当于节省了近 1 GiB 的物理内存。

这一发现引出了两个核心问题：
1. Go 1.24 究竟做了什么，让 map 在某些场景下变得如此高效？
2. 为什么这种内存优化的效果并非在所有环境中都一致？

Go Map 的前世今生：从 Bucket 到 Group

要理解这一变革，我们必须回顾 Go map 的内部实现演进。

Go 1.23 及之前：基于 Bucket 的设计

在 Go 1.24 之前，Go 的 map 实现是基于传统的桶（Bucket）和链式地址法来解决哈希冲突的。

结构：map 由一个 Bucket 数组组成。每个 Bucket 内部有 8 个槽（slot），用于存放键值对。
插入与查找：当插入或查找一个键时，Go 会计算其哈希值以确定它属于哪个 Bucket。然后，它需要线性扫描该 Bucket 内的所有槽位来查找匹配的键。
溢出处理：当一个 Bucket 的 8 个槽都满了，后续哈希到此的键值对会被放入一个溢出桶（overflow bucket）中，并形成一个链表。这意味着，在最坏的情况下，一次查找可能需要遍历多个 Bucket。
扩容机制：当 map 的平均负载因子超过阈值（约 81.25%）时，会触发扩容。Go 会分配一个两倍大小的新 Bucket 数组，但并不会立即迁移所有数据。为了平摊延迟，数据迁移是增量进行的，在后续的写操作中，旧 Bucket 的数据会逐渐被搬迁到新 Bucket。这种设计虽然降低了单次操作的延迟，但其代价是在迁移期间，新旧两个 Bucket 数组会同时存在于内存中，导致瞬时内存翻倍。

Go 1.24 的革新：Swiss Table 与可扩展哈希

Go 1.24 引入了一套全新的、基于 Swiss Tables 和可扩展哈希（extendible hashing） 的 map 实现，彻底改变了游戏规则。

结构：数据被存储在组（Group）中，每个组同样包含 8 个槽。与 Bucket 不同的是，每个 Group 都有一个 8 字节的控制字（control word）。控制字的每个字节对应一个槽，其低 7 位存储了该槽位 key 哈希值的最后 7 位（h2），最高位则是一个标记，表示该槽是空闲（empty）、已删除（deleted）还是使用中（in use）。

高效查找：当查找一个键时，不再需要线性扫描所有键值对。Go 可以利用单指令多数据流（SIMD）指令，将目标键的 h2 值与控制字中的 8 个字节并行比较，一次性找出所有可能匹配的槽位。这极大地加速了查找过程。
开放寻址与无溢出桶：当一个 Group 满了，新的键值对会通过开放寻址（probing）的方式，被尝试放入下一个 Group。这种快速的探测机制彻底消除了对溢出桶的需求。
更高的负载因子与更高效的扩容：由于探测速度极快，Swiss Table 可以安全地维持更高的负载因子（87.5%），这意味着在存储相同数量的元素时，所需的总槽位数更少，从而节省了内存。更重要的是，对于非常大的 map，Go 1.24 采用了可扩展哈希，将一个大 map 视为一个由多个独立的、大小有上限（128个Group）的 Swiss Table 组成的目录。当某个子表需要分裂时，只会影响该子表本身，而不是像旧版 map 那样保留整个旧的 Bucket 数组，这使得扩容过程的内存效率大大提高。

Datadog 实战：量化 Swiss Table 带来的巨大收益

Datadog 团队通过详细的计算，量化了这次底层变更对他们核心业务数据 shardRoutingCache 的影响。

案例背景：一个巨大的内存缓存 shardRoutingCache

这个 map 在服务启动时从数据库加载，并且很少写入，其结构如下：

// The key represents each routing key derived from the data payload
shardRoutingCache map[string]Response 

type Response struct {
    ShardID      int32
    ShardType    ShardType // ShardType is an int
    RoutingKey   string
    LastModified *time.Time
}

在 64 位架构下，每个键值对（不含 string 内容和 time.Time 结构体）的基础大小为 56 字节。

高流量环境：350 万元素的 map

Go 1.23 下的内存估算：为了存储 350 万个元素，并考虑到增量扩容期间新旧 Bucket 数组共存的情况，Datadog 估算出 map 的桶结构本身大约需要 696 MiB 内存。
Go 1.24 下的内存估算：得益于更高的负载因子和更高效的扩容机制，存储同样多的元素，Swiss Table 只需要大约 500,000 个 Group，分布在约 3900 个独立的子表中。每个子表独立管理内存，避免了全局的内存加倍。

最终结果是，仅 map 结构本身的内存占用就从近 700 MiB 降至约 200 MiB 左右，实现了约 70% 的惊人降幅，这与他们在生产环境中观察到的 500 MiB 堆内存节省高度吻合。

低流量环境：55 万元素的 map

然而，在元素数量级较小的环境中（约 55 万），内存节省效果（约 28 MiB）远没有那么显著。这点节省甚至不足以抵消 Go 1.24 中 mallocgc 的内存回归带来的开销（约 200-300 MiB RSS 增加）。这完美地解释了为什么内存优化的效果并非普遍存在：Swiss Table 的优势在处理大规模 map 时才能被最大化地体现出来。

超越运行时：应用层优化的锦上添花

受到运行时优化的启发，Datadog 团队还审视了自己的数据结构 Response。他们发现：
1. RoutingKey 和 LastModified 字段在该 map 的特定用例中从未被填充。
2. ShardType 作为一个只有 3 个值的枚举，却使用了 8 字节的 int 类型。

通过创建一个仅包含所需字段的新结构 cachedResponse，并将 ShardType 从 int 改为 uint8，他们将每个 value 的大小从 40 字节（带填充）锐减至 8 字节（带填充）。这一应用层面的优化，为他们高流量环境中的每个 pod 额外节省了约 250 MiB 的 RSS。

总结与启示

Datadog 的这次深度调查为 Go 开发者社区带来了宝贵的经验：

Go 1.24 的 Swiss Tables 是一个巨大的胜利：对于重度使用大型 map 的应用，升级到 Go 1.24 能带来立竿见影的、显著的内存节省和性能提升。
升级需谨慎，观测是关键：每个 Go 版本都可能带来优化和回归。没有深入的运行时指标（如 RSS）和堆分析，像 mallocgc 回归和 Swiss Table 优化这样的 subtle 变化很容易被忽略或误判。
运行时与应用层优化相辅相成：底层的改进为上层应用打开了新的优化空间。审视自己的数据结构，消除浪费，使用恰当大小的类型，这些看似微小的改动在规模化部署下能产生巨大的影响。
社区协作的力量：从发现问题到与 Go 团队协作验证修复，这次经历再次证明了 Go 社区开放协作文化的强大。

总而言之，Go 1.24 中 map 的革新是一次教科书式的工程优化。它不仅提升了 Go 语言的核心竞争力，也通过 Datadog 的分享，为所有 Go 开发者上了一堂生动的、关于性能分析与优化的实践课。

资料链接：https://www.datadoghq.com/blog/engineering/go-swiss-tables/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？