Agili 的 Hacker Podcast by Agili 的 Hacker Podcast

May 31, 2025 Hacker News 每日播报 2025-05-31

欢迎收听 Hacker News 每日播报，今天我们将深入探讨从软件开发中的性能优化陷阱到宇宙膨胀率的最新发现，再到AI时代下劳动与技术的复杂关系。

今天我们要聊的话题是关于一个在软件开发中常常被用来提升性能，但也可能带来意想不到问题的编译器选项：fast-math。这篇来自 simonbyrne.github.io 的文章，标题就直接点明了主题——“Beware of Fast-Math”，也就是“警惕 Fast-Math”。

文章开篇就指出，fast-math 是一个存在于多种语言和编译器中的选项，比如 GCC/Clang 的 -ffast-math，Intel ICC 的 -fp-model=fast，MSVC 的 /fp:fast，以及 Julia 的 @fastmath 宏。顾名思义，它的目的是让浮点数运算更快。但这速度是有代价的。

文章的核心观点是，fast-math 通过允许编译器打破 IEEE 754 浮点数标准的一些规则来实现加速。虽然这些规则的破坏初看起来可能无伤大雅，但实际上可能导致显著甚至灾难性的错误。作者重点讨论了三个主要的危险点：

潜在的危险

首先是 -ffinite-math-only。这个选项告诉编译器，你可以假设运算参数和结果都不会是 NaN（非数字）或 Inf（无穷大）。这听起来很合理，如果你的代码确实不产生这些值。但问题在于，如果你的代码包含了专门用来检查和处理 NaN 或 Inf 的逻辑（比如 isnan(x)），编译器在 ffinite-math-only 的作用下可能会认为 x == x 永远为真（因为 NaN 不等于自身），从而直接移除这些检查代码。结果就是，一旦意外产生了 NaN，你的程序将无法正确处理，可能导致错误结果甚至崩溃。作者提到这是导致 fast-math 相关问题最常见的原因之一。

其次是 -fassociative-math。这个选项允许编译器重新排序浮点运算的顺序。例如，数学上 (a + b) + c 和 a + (b + c) 是等价的，但在浮点数运算中，由于舍入误差，它们的结果可能不同。编译器利用这个自由度可以进行向量化（SIMD）等优化，显著提升性能。然而，某些算法，特别是补偿算术（如 Kahan Summation），严格依赖于特定的运算顺序来控制误差。启用 fassociative-math 会破坏这些算法的逻辑，比如 Kahan Summation 中的误差修正项可能会被编译器“优化”掉，导致结果精度大幅下降，甚至完全错误。

第三个危险点是冲洗次正规数到零（Flushing Subnormals to Zero, FTZ），这通常包含在 -funsafe-math-optimizations 中。次正规数是非常接近零的浮点数。在某些处理器上处理它们会带来显著的性能损失。FTZ 的做法是直接将这些次正规数结果视为零。虽然在音频、图形等领域这可能可以接受，但在需要精确数值稳定性的场景下，FTZ 会破坏重要的数值分析性质，导致迭代算法不收敛等问题。更糟糕的是，FTZ 通常是通过设置浮点环境寄存器实现的，这个设置是线程级别的。这意味着一个链接了使用 fast-math（特别是包含 FTZ）编译的共享库的程序，即使自身没有使用 fast-math，其浮点运算结果也可能受到影响，这使得调试异常困难。

文章最后给出了对程序员和语言/编译器开发者的建议。对程序员来说，如果精度重要，应谨慎使用 fast-math，最好只启用特定的子选项，并进行严格的测试和验证。或者考虑重写代码，使其本身就适合向量化等优化，或者使用 OpenMP、SIMD 内联函数等更显式的并行化工具。对语言和编译器开发者，作者认为 fast-math 的广泛使用是设计上的失败，应该提供更精细、局部化的控制机制（如函数属性、Pragma 或宏），并改进文档和警告，教育用户其潜在风险。文章更新部分提到 GCC 13 修复了 FTZ 库的问题，以及 Rust 在探索更安全的“代数运算”API。

社区讨论与洞察

围绕这一话题，社区展开了热烈讨论，观点多样。

一个重要的讨论方向是 Rust 正在探索的“代数运算”API。有开发者提到 Rust 正在设计一种新的浮点运算 API，允许对特定操作序列进行基于代数属性的优化（如重排序），但这些操作是局部控制的，并且不会像 fast-math 那样引入未定义行为。这被视为一种比全局 fast-math 标志更安全、更可控的替代方案。

关于 IEEE 754 标准本身是否是问题根源的讨论也很有趣。一些开发者认为，标准本身并没有问题，它提供了严格的语义保证，问题在于许多编程语言强制了顺序执行语义，阻碍了自动向量化。另一些开发者则认为，标准的严格性确实是阻碍自动向量化的原因，也许某些特性应该设计成局部可选的。他们认为，对于许多不要求绝对精度的应用（如游戏、图形、ML），牺牲一些精度换取性能是合理的，而当前的语言/编译器缺乏灵活的方式来表达这种权衡。

关于 fast-math 的适用场景，开发者们也存在分歧。一些有科学计算背景的用户认为，在许多模拟中，物理噪声或模型误差远大于浮点数精度损失，fast-math 带来的性能提升是值得的。然而，来自 CAD、机器人、半导体光学等领域的开发者则强调，在他们的领域，即使是微小的精度差异也可能导致严重问题，浮点精度（包括可重现性）至关重要。这突显了不同应用领域对浮点数行为要求的巨大差异。

讨论中还提到了一些具体的细节和经验：-ffast-math 实际上是多个独立标志的集合，用户可以单独使用它们，这与文章中建议的精细控制相符。feenableexcept() 是一个有用的工具，可以在不使用 fast-math 的情况下，通过触发信号来帮助定位产生 NaN 的代码位置。FTZ/DAZ 的线程级别设置问题被再次强调，并被描述为“有趣的调试体验”，因为它可能导致难以追踪的跨模块影响。有人提到了固定点运算或有理数作为浮点数的替代方案，尤其是在不需要处理超越数（如三角函数、对数）或平方根的场景下，它们可以提供更好的精度或可重现性。

总的来说，开发者们普遍认识到：fast-math 是一个强大的性能工具，但其潜在的危险性常常被低估，尤其是在不完全理解其对浮点数语义改变的情况下。社区普遍认为需要更好的工具和语言特性，来实现性能优化，同时保持对数值行为的精细控制，而不是依赖一个粗粒度的、可能导致意外错误的全局标志。

Valkey 一周年：Redis 社区分叉的崛起

今天我们要聊的话题是 Valkey，这个从 Redis 分叉出来的社区项目，在诞生一周年之际的表现。

文章概览：Valkey 一周年，表现超越 Redis？

这篇来自 Momento 博客的文章，标题非常引人注目：《Valkey 一周年：社区分叉如何将 Redis 甩在身后》。文章回顾了大约一年前，Redis Inc.（原 Garantia Data）将 Redis 的开源许可改为 SSPL，这一举动在开源社区引发了巨大争议和信任危机。作为回应，社区迅速行动，创建了 Valkey 这个分叉项目，旨在维护一个真正开源、由社区驱动的 Redis 替代品。

文章的核心观点是，Valkey 不仅成功存活下来，而且发展势头良好，甚至在实际基准测试中表现优于 Redis 8.0。作者通过详细的性能对比，展示了 Valkey 在吞吐量和延迟方面的优势，并深入探讨了实现这些性能提升的关键技术，特别是 I/O 线程模型的改进。

文章要点深入分析

分叉的背景与现状： 文章首先铺垫了 Redis Inc. 改变许可（从 BSD 到 SSPL）引发社区不满的历史。随后提到 Redis Inc. 最近试图修复关系，请回了原作者 Antirez，并将 Redis 8.0 重新开源（改为 AGPLv3 许可）。然而，文章认为 Valkey 作为社区分叉，已经形成了自己的势头。

性能基准测试： 文章的核心内容是 Valkey 8.1.1 与 Redis 8.0 在 AWS c8g.2xl 实例上的性能对比。在模拟实际工作负载（1KB 数据，300 万键空间，约 500 连接）下，Valkey 在 SET 和 GET 操作上均展现出更高的吞吐量和更低的 p99 延迟。具体数据显示，Valkey 的 SET 吞吐量比 Redis 高 37%，GET 高 16%，p99 延迟分别快 30% 和 60% 以上。

I/O 线程的关键作用： 文章强调了 I/O 线程对性能提升的重要性。虽然 Redis 早在 2020 年就引入了 I/O 线程，但文章指出，直到最近，特别是 Valkey 社区（文章特别提到 AWS 的贡献）对 I/O 线程模型进行了重大改进，才带来了显著的性能飞跃。测试表明，启用 I/O 线程后，吞吐量可以大幅提升，延迟显著降低。

性能调优细节： 文章分享了在基准测试中实现最佳性能的一些高级调优技巧，例如通过 ethtool 和 smp_affinity 将网络中断 (IRQ) 和 Valkey/Redis 进程分别绑定到不同的 CPU 核心，以减少上下文切换和提高缓存局部性。这部分提供了非常实用的技术指导。

基准测试的局限性： 作者也承认，基准测试是合成的，并不能完全代表所有实际工作负载。他们提到了 Valkey-benchmark 工具的一些不足之处，并推荐了他们公司使用的更灵活的工具 rpc-perf。

社区观点总结与分析

围绕文章引发了热烈讨论，观点多样且深刻：

Antirez 的回应与文章的准确性： Redis 原作者 Antirez 亲自下场，这是最受关注的焦点。他首先感谢了 Valkey 社区在 I/O 线程方面做出的贡献，但同时也对文章中关于 I/O 线程历史和其本人理念的描述提出了异议。他澄清说，他在 2020 年引入 I/O 线程正是因为它不违背他“共享无关”(shared nothing) 的核心理念，并且该功能当时并非“没有显著改进”，只是现在被进一步优化了。Antirez 的评论为讨论带来了重要的内部视角和技术细节，也引发了关于技术文章客观性的讨论。

许可之争与社区信任： 许多开发者围绕 Redis Inc. 的许可变更和社区信任展开。

Valkey 的优势： 普遍认为，Valkey 采用 BSD 许可，这对于大型云服务商和许多企业来说更具吸引力，因为它没有 AGPL 的传染性条款。即使 Redis 8.0 回归 AGPL，其对商业使用的限制以及贡献者需要签署 CLA 等因素，使得许多公司更倾向于 Valkey。Valkey 被视为维护了 Redis 最初的开放精神。

Redis Inc. 的信任危机： 许多用户表示，Redis Inc. 此前的“许可拉扯”(rug pull) 行为已经严重损害了信任，即使现在回归 AGPL，也难以挽回。这种“诱饵与转换”(bait-and-switch) 的感觉让许多公司在选择关键基础设施时会避开 Redis Inc. 控制的项目。

AGPL 的讨论： 有开发者认为 AGPL 是保护开源项目不被云服务商“白嫖”的必要手段，支持项目通过商业许可盈利。但也有开发者指出，AGPL 的限制性会阻碍社区贡献和广泛采用。

社区健康与企业支持： 开发者指出，Valkey 已经获得了包括 AWS、Google Cloud、Oracle、Percona、Ericsson 等多家大型公司的支持，并加入了 Linux Foundation。这表明 Valkey 拥有强大的企业后盾和健康的社区活动，贡献者众多。一些开发者认为，这种多方参与的模式比由单一公司主导的项目更具可持续性和抗风险能力。

实际应用与基准测试的差异： 一位用户分享了他们在 AWS 上使用托管 Valkey 时遇到的稳定性问题，导致他们切换回了托管 Redis。这引发了关于托管服务可靠性、云提供商特定实现问题以及基准测试结果与实际生产环境表现之间可能存在的差异的讨论。

分发版集成： 开发者提到 Valkey 正在被主要的 Linux 发行版（如 Debian, Arch, RHEL）集成，有时甚至取代了 Redis。这对于开发者和系统管理员来说是一个重要的便利因素。

合并的可能性： 有开发者询问 Valkey 和 Redis 是否有可能合并。但普遍认为，由于双方采用了不同的开源许可（BSD vs AGPL）以及信任问题，合并的可能性非常小，两个项目很可能会长期并行发展。

总的来说，这篇文章和社区讨论描绘了一幅开源项目在商业化、许可选择和社区信任危机背景下的生动图景。Valkey 在技术性能和社区支持方面展现出强劲势头，而 Redis Inc. 尽管试图修复关系并回归开源，但其此前的行为已造成了难以弥补的信任裂痕，且新的 AGPL 许可也带来了新的挑战。这场围绕 Redis 和 Valkey 的竞争与演变，无疑将继续是开发者社区关注的焦点。

梯度：图形学优化的新区间

今天我们要聊的文章来自 Matt Keeter 的博客，标题是《Gradients Are the New Intervals》。这篇文章深入探讨了在计算机图形学中，特别是处理隐式表面（Implicit Surfaces）和构造实体几何（CSG）时，如何优化渲染和求值过程。作者对比了传统的区间算术（Interval Arithmetic）方法与一种基于函数梯度（或更准确地说，Lipschitz 连续性）的新方法。

区间算术的局限性

文章首先介绍了隐式表面渲染的背景，以及区间算术如何被用于空间区域的剔除（skipping regions）和复杂表达式的简化。基本思想是，通过在空间的一个矩形区域（对应于输入变量的区间）上评估函数，得到函数在该区域内的值范围（一个输出区间）。如果这个输出区间不包含零，那么可以确定该区域完全在形状内部或外部，从而避免进一步处理，实现剪枝优化。区间算术的另一个好处是可以在 CSG 树中简化表达式。

然而，区间算术存在一些缺点。它本质上是保守的，区间会随着计算层层放大，导致对函数值范围的估计过于宽松，从而需要更多的细分。此外，它对坐标变换（如旋转）很敏感，变换会放大输入区间的影响，进一步加剧保守性。

基于 Lipschitz 连续性的新方法

文章的核心是介绍了一种基于 Lipschitz 连续性的新方法。对于一个 Lipschitz 连续函数，其梯度（如果存在）的幅度是有界的。特别是对于规范化的符号距离场（Signed Distance Field, SDF），其梯度幅度理想情况下处处为 1。利用这个性质，作者提出了一种“伪区间”评估方法：在一个区域内，只在中心点进行一次函数求值，然后利用 Lipschitz 常数（例如 1）和区域中心到角落的最大距离，来估计函数在该区域内的值范围。这个估计值范围 [v - d, v + d] 就是一个“伪区间”。

这种伪区间方法相比传统的区间算术有几个优势：它只需要一次浮点数求值，计算成本更低；它对坐标变换不敏感，因为 Lipschitz 性质与坐标系无关。它同样可以用于区域剔除（如果伪区间不包含 0）和表达式简化。

文章接着讨论了如何处理非 Lipschitz 连续的函数，因为 CSG 操作（如 min 和 max）可能会破坏这个性质。作者探索了一种通过将函数值除以梯度幅度进行规范化的方法。然而，直接在 CSG 组合后进行规范化可能在不同梯度幅度的区域交界处引入值的不连续性。一个改进的策略是在进行 min 或 max 操作之前对每个输入函数进行规范化。虽然这改变了函数值本身，但保留了符号（对于 CSG 的布尔操作来说，符号是关键），并且有助于维持 Lipschitz 连续性。这种方法需要计算梯度，可以通过自动微分（Automatic Differentiation, AD）实现，但这会增加计算成本。

在性能方面，作者的实验表明，对于非 Lipschitz 函数，使用自动微分进行规范化后的伪区间方法与传统的区间算术方法性能接近，虽然在测试案例中略慢。但对于本身就是 Lipschitz 连续的函数，单点采样的伪区间方法预计会更快。

总的来说，文章认为，如果能保证函数的 Lipschitz 连续性（或者通过规范化使其满足），那么基于梯度/Lipschitz 性质的单点采样方法可以作为区间算术的有效替代，实现类似的优化效果，并且在某些方面（如对变换的鲁棒性）表现更好。

社区讨论与洞察

围绕这篇文章，社区展开了热烈的讨论，涵盖了多个角度：

首先，有开发者指出，文章中利用函数性质（如梯度界限）来估计区域内函数值范围的思想并非全新。有开发者提到了“Taylor model”（泰勒模型）和“neighborhood arithmetic”（邻域算术）等更早期的工作，它们使用泰勒展开和高阶导数的界限来获得更紧密的区间估计。这表明文章提出的方法与数值分析和区间分析领域的现有技术有历史渊源和联系。

其次，关于 Lipschitz 连续性的数学定义和文章中的用法引发了广泛讨论。多位开发者强调，Lipschitz 连续性的定义并不要求函数可微，其强大之处恰恰在于它适用于不可微函数（例如文章中使用的 min 和 max 操作）。他们认为文章中将 Lipschitz 性质等同于“梯度有界”的说法可能引起混淆，并且忽略了 Lipschitz 性质在处理不可微函数时的核心价值。这场讨论深入探讨了数学分析中 Lipschitz 连续性、可微性以及梯度/次梯度的关系，反映了理论定义与工程实践中简化描述之间的张力。

第三，数值精度和鲁棒性是另一个关注点。开发者指出，传统的区间算术通过控制舍入方向，可以提供数学上严格的计算结果和误差界限。而基于浮点数计算梯度的方法，可能会受到浮点误差和取消误差的影响，无法提供同样的严格保证。这引出了一个权衡：在图形学中，通常更看重视觉效果和性能，而不是数学上的绝对严格性，这与数值分析领域的优先级可能不同。

此外，开发者还提出了一些相关的想法和工作，例如建议在 SDF 中存储指向表面的位移向量（法线）信息，这可能有助于更有效地指导区域细分；以及提到了在神经隐式表面（Neural Implicit Surfaces）中使用区间分析进行光线步进的研究。

总的来说，社区不仅肯定了文章在优化 SDF/CSG 渲染方面的价值和启发性，也从历史、数学严谨性、数值计算等多个角度进行了深入的技术探讨和批判性分析，展现了 Hacker News 社区在技术细节上的高水平讨论氛围。

逆向工程 Linear 同步引擎：揭秘其流畅协作的奥秘

今天我们要聊的是一篇在 Hacker News 上引起广泛关注的文章，它深入探讨了 Linear 这款以速度和协作流畅著称的项目管理工具的核心——它的同步引擎。这篇由 wzhudev 在 GitHub 上发布的文章，通过逆向工程 Linear 的前端代码，为我们揭示了其同步机制的奥秘，甚至得到了 Linear CTO 的高度评价，称其为“可能比内部文档还好的文档”。

Linear 同步引擎 (LSE) 的核心机制

文章的核心在于解析 Linear Sync Engine (LSE) 如何在客户端实现数据的实时同步、离线可用以及流畅的协作体验。作者指出，传统的协作技术如 Operational Transformation (OT) 和 Conflict-free Replicated Data Types (CRDTs) 虽然强大，但在处理任意数据模型、部分同步、权限控制等方面可能存在复杂性或不足。LSE 提供了一种不同的、更贴近传统 ORM 开发体验的方案。

文章详细阐述了 LSE 的几个关键组成部分和概念：

模型 (Models): Linear 中的实体，如 Issue、Team 等，被定义为模型。它们有属性和对其他模型的引用。LSE 使用 MobX 使这些模型可观察，以便 UI 自动响应数据变化。模型有不同的加载策略（instant、lazy、partial 等），决定了它们何时被加载到客户端。

事务 (Transactions): 客户端的操作（创建、更新、删除等）被封装成事务发送到服务器。这些事务设计为只在服务器执行，并在客户端可逆，以应对网络问题。离线时，事务会缓存到 IndexedDB，连接恢复后自动重发。事务与一个单调递增的 sync id 关联，确保操作的顺序性。

增量包 (Delta Packets): 服务器执行事务后，会将变更以增量包的形式广播给所有连接的客户端。每个增量包也带有 sync id。增量包可能包含服务器执行事务产生的副作用。

本地存储 (IndexedDB): LSE 在客户端使用 IndexedDB 持久化数据。每个工作空间有一个独立的数据库，其中包含每个模型的表，以及存储元数据（如 lastSyncId）和缓存事务的特殊表。

lastSyncId: 这是 LSE 中一个非常关键的概念。它是一个全局的、单调递增的整数，代表整个数据库的最新版本。与 OT 中通常针对单个文档的版本号不同，LSE 的 lastSyncId 跨越整个系统。服务器控制着这个 ID 的增长，确保了所有操作的全局总顺序。客户端通过比较本地和服务器的 lastSyncId 来判断是否需要同步。

引导加载 (Bootstrapping): 客户端启动时，LSE 会根据本地 IndexedDB 的状态决定执行哪种类型的引导加载（full、local、partial）。全量引导加载会从服务器拉取所有必要模型的数据，存储到 IndexedDB，并将 instant 模型加载到内存中的对象池 (Object Pool)。

惰性加载与水合 (Lazy Loading & Hydration): 不是所有数据都在启动时加载。lazy 和 partial 模型的数据会在需要时按需加载，可能是从本地 IndexedDB 或通过网络请求。文章特别提到了“部分索引 (Partial Index)”的概念，用于高效查询与某个模型相关的惰性加载数据。

总的来说，LSE 采用了一种服务器权威、基于全局总顺序（通过 sync id）的同步模型，结合客户端的 IndexedDB 缓存、MobX 响应式系统以及精细的加载策略，实现了快速、流畅且支持离线的用户体验。它避免了客户端复杂的冲突解决逻辑，将排序和冲突处理集中在服务器端。

社区讨论与洞察

围绕这篇文章，开发者们展开了热烈讨论，主要集中在以下几个方面：

首先，对作者逆向工程工作的赞赏是亮点。Linear 的 CTO 亲自留言，称赞这篇文档的准确性和完整性，甚至认为它比公司内部的一些文档还要好，这极大地肯定了作者的努力和技术深度。

其次，许多开发者对如何为自己的应用构建同步引擎表现出兴趣并寻求建议。一位开发者描述了自己目前基于 WebSocket 和数据库触发器的简陋同步方案，并询问在 Rust/Postgres/Vue 技术栈下，未来应该选择哪条路。

这引出了关于现有同步解决方案和库的讨论。大家提到了多种替代方案：

Yjs: 被指出是一个 CRDT 数据结构库，而非完整的同步引擎，但可以作为构建同步引擎的基础。

ElectricSQL: 一个针对 Postgres 的同步解决方案。

LiveStore: 另一个被提及的库，据说有模仿 Linear 的例子。

PowerSync: 也是一个同步方案。

Loro (CRDT) + Iroh (字节传输): 有用户分享了自己使用这套组合的经验，并提到 CRDT 库在移动端表现良好。

Replicache: 结合 MobX 或 Orama 可以实现类似 Linear 的效果。

Firebase (Firestore) / MongoDB Realm: 被认为是提供类似同步体验的商业或开源方案。

讨论中还分享了 localfirstweb.dev 上的“本地优先”技术概览，以及 Martin Kleppmann 关于通用同步协议的演讲，强调了该领域的活跃和缺乏标准化。

此外，开发者也出现了一些对 LSE 方法的简短总结和讨论。有人试图用更简洁的语言概括 LSE，称其为“朴素的最后写入者获胜 (last-write-wins)，没有冲突检测，没有 OT，没有 CRDT”，并认为文章细节过多。但其他开发者和文章本身都表明，LSE 并非简单的 LWW，而是通过服务器控制的全局 sync id 来强制实现总顺序，从而避免了客户端的冲突解决，这是一种不同于传统 OT/CRDT 的集中式同步策略。

总的来说，这篇逆向工程文章为我们提供了一个深入了解 Linear 高性能同步引擎的宝贵机会，揭示了其基于服务器权威和全局 sync id 的独特设计。社区的讨论则进一步扩展了话题，对比了 LSE 与其他同步技术，并为正在探索构建类似系统的开发者提供了丰富的资源和视角。

Mary Meeker 2024 AI 趋势报告：变革浪潮与社区洞察

今天我们要聊的是备受关注的 Mary Meeker 最新趋势报告，这是她自 2019 年以来发布的第一份报告，聚焦于人工智能。这份报告由 BOND Capital 发布，深入分析了 AI 领域当前的发展速度、用户采纳、技术进步以及地缘政治影响。

报告核心观点与要点

报告的核心观点是：AI 正在以前所未有的速度推动变革，其速度甚至超过了互联网早期。这种加速得益于全球互联网基础设施的普及、海量数字数据的积累，以及像 ChatGPT 这样易于使用的突破性大型语言模型的出现。报告强调，无论是新兴的 AI 公司还是传统的科技巨头，都在以前所未有的力度进行创新、投资和竞争。

报告通过一系列图表和数据点阐述了几个关键要点：

前所未有的增长： AI 的用户增长、使用量和资本支出都呈现爆炸式增长。例如，ChatGPT 在短短 17 个月内周活跃用户达到 8 亿，其用户增长速度远超过去的互联网产品。大型科技公司在 AI 相关的资本支出上投入巨大。

技术进步与成本： 训练 AI 模型的计算成本仍然高昂且不断上升，但推理成本（即运行模型的成本）正在快速下降。算法和超级计算机的进步也显著提升了 AI 性能。报告展示了 AI 推理成本相对于其推出年份的价格下降速度，比电力和计算机内存等历史技术快得多。

广泛的应用与采纳： AI 的应用正在快速渗透到各个领域。报告展示了开发者生态系统的显著增长（如 NVIDIA 和 Google 的 AI 开发者数量），企业对 AI 的关注度大幅提升，以及在金融、医疗和餐饮等行业的具体应用案例。政府层面也在积极采纳 AI 并制定主权 AI 政策。

地缘政治竞争： 报告特别指出了美国和中国在 AI 技术发展和领导力方面的激烈竞争，认为技术和地缘政治力量正在深度交织。

效益与风险： 报告简要提及了 AI 的巨大潜在效益（解决复杂问题、提高生产力）和显著风险（滥用、偏见、就业影响、安全问题），引用了 Stuart Russell 和 Peter Norvig 的观点，并以 Stephen Hawking 的警示结尾。

社区讨论与洞察

围绕这份报告，Hacker News 的读者们表达了多样化的看法和深入的讨论：

首先，关于报告中将 ChatGPT 的增长速度与 Google 等早期互联网公司进行比较，引发了广泛争议。一些开发者认为这种比较不公平且误导，因为当前的互联网普及率和智能设备数量与 Google 诞生时不可同日而语。然而，另一些开发者则辩护说，这种比较的意义在于展示在当前基础设施下，一个突破性产品能够达到怎样的惊人增长速度，这对于预测未来产品的扩展潜力具有参考价值。

其次，关于 AI 的实际价值、用户构成和盈利能力，社区也出现了不同声音。有人质疑 ChatGPT 的部分用户（例如学生）是否主要用于“作弊”，以及这部分用户群体的长期价值。关于普通用户是否愿意为 AI 付费，有人持怀疑态度。但也有人指出，AI 的主要付费群体可能是企业，就像 Salesforce 或 Oracle 一样，企业会为了提高生产力而买单。关于 OpenAI 是否盈利的问题也被提及，开发者认为目前 OpenAI 尚未盈利，正处于追求超高速增长的阶段，未来的盈利模式和价值捕获能力仍有待观察。同时，也有人指出，考虑到全球大部分人口的收入水平，每月 20 美元的订阅费对他们来说是不现实的。

“够用就好”（Good Enough）的 AI 应用是另一个重要的讨论点。许多人认为，AI 并不需要达到完美的程度才能产生巨大价值。在许多场景下，“够用”的 AI 已经可以替代或辅助人类完成任务，即使偶尔出错，通过人工审核或在非关键任务中使用，其带来的效率提升和成本节约仍然显著。开发者举例包括软件开发的自动补全、搜索结果总结、基础网页开发、餐厅的语音点餐系统，甚至生物化学研究中的加速发现过程。他们认为，对于许多任务而言，检查和修正 AI 的输出比从头开始手动完成要快得多。然而，也有人指出，对于需要复杂上下文理解和高准确性的任务，当前的 AI 可能仍面临“上下文不足”或“上下文压缩和回忆能力差”的挑战，这比简单的“幻觉”问题更难解决。

此外，报告中提到的一些具体数据点也引发了讨论。例如，关于 Waymo 在旧金山叫车市场的份额，开发者澄清报告中的图表是 Waymo 与 Lyft 的比较，而非整个叫车市场（包括 Uber），但即便如此，Waymo 超过 Lyft 的速度也令人印象深刻。关于 Yum! Brands 采用 AI 平台的案例，有人质疑这是否仅仅是常规的 IT 系统升级被贴上了 AI 的标签，但也有人指出这确实包含了用 AI 替代人工进行得来速点餐等具体应用。

最后，关于报告的风格和呈现方式，一些读者觉得其图表标题和文字风格有些难以理解或显得过于夸张，甚至有人怀疑部分内容是否由 AI 生成。同时，报告的庞大体量也让一些人望而却步，认为其中可能包含不少营销成分，更希望看到对 AI 实际生产力提升的更深入量化分析，而不仅仅是投入和采纳的增长数据。

总的来说，Mary Meeker 的这份报告成功地描绘了当前 AI 领域惊人的发展速度和广泛的采纳趋势，特别是在用户增长、投资和技术进步方面。而社区的讨论则在肯定这些趋势的同时，对报告中的比较方法、AI 的实际价值、盈利模式以及“够用就好”的应用哲学进行了批判性思考和补充，展现了技术社区对这一变革性技术的复杂和多角度视角。

用小工具积极抵御机器人：个人网站的流量保卫战

这期节目，我们关注了一篇名为《Using lots of little tools to aggressively reject the bots》的文章。作者分享了他在运营一个小型个人网站时，如何应对突如其来的大量机器人流量，特别是那些被认为用于训练大型语言模型的爬虫。

网站遭遇机器人攻击

文章首先描述了问题：作者的个人网站，包括博客和自托管的 Gitea 实例，突然遭遇了异常高的流量。这些流量并非来自普通用户或像 Archive.org 那样友好的爬虫，而是来自声称是 Amazon、Facebook、OpenAI 等大型公司的机器人，以及大量伪装身份的爬虫。作者认为这些机器人是为了抓取数据用于自身目的，且行为粗暴，不顾及网站的资源消耗。这种流量激增导致他的小型服务器资源耗尽，网站服务中断，甚至影响了他日常使用 Gitea。

为了诊断问题，作者利用了他作为系统管理员的工具箱。他通过 Zabbix 监控系统观察到资源使用率（磁盘、CPU、内存）和网络请求量出现了异常峰值，流量比平时高出十倍。进一步，他使用 lnav 和 goaccess 等日志分析工具深入挖掘 Nginx 访问日志，识别出大量不同的 IP 地址和用户代理，确认了流量的来源多样且行为模式是全面抓取网站内容，尤其是针对 Gitea 中生成资源密集型数据的 URL，比如每个提交的 tarball。

多层防御策略

面对这一挑战，作者采取了多层防御措施。首先，他在 Nginx 中配置了一个用户代理黑名单，对于已知的不良机器人直接返回 403 Forbidden 错误。同时，他设置了每秒 5 个请求的速率限制，防止单个 IP 过快访问。更进一步，他结合 Fail2Ban 工具，监控 Nginx 日志中返回 403 错误的请求，一旦某个 IP 触发了设定的阈值，Fail2Ban 就会自动将其封禁 24 小时。作者展示了 Fail2Ban 的状态，显示已有数百个 IP 被封禁。

作者总结说，这些措施有效地阻止了恶意爬虫，恢复了网站的正常运行。他强调这些机器人流量，特别是针对 Gitea 仓库的抓取，是“令人厌恶且不必要的”，并且他无意让自己的内容被用于“AI 的劣质化”。尽管未来可能会对 Archive.org 等合法服务放行，但他对那些不尊重网站资源和规则的爬虫持强硬态度。

社区讨论与洞察

围绕这篇文章，社区展开了热烈讨论，观点多样：

一方面，许多开发者对作者的遭遇表示同情，并分享了自己网站也面临类似问题的经历。他们证实了 AI 爬虫行为的侵略性，包括忽略 robots.txt、伪造用户代理、使用住宅 IP 代理等手段来逃避检测和封锁。一些人提到，这些爬虫确实会消耗大量资源，特别是对于小型或非优化的服务器而言，即使每秒几十个请求也可能造成显著影响，甚至导致服务中断或费用增加。

另一方面，也有开发者对作者的应对方式提出了不同看法。有人认为，每秒 20 个请求对于一个现代 Web 服务器来说并不算多，作者应该优先优化网站或服务器配置来处理更高的流量，而不是急于封锁。他们认为，如果内容是公开的，就应该预期会被访问，包括被用于 AI 训练，就像 Google 索引或 RSS 阅读一样。他们质疑为什么人们可以接受 Google 抓取用于搜索索引，却不能接受 AI 抓取用于训练模型。

对此，支持作者的开发者反驳说，AI 抓取与传统搜索引擎索引不同，前者往往不导流回原网站，且行为模式更具侵略性，专门针对资源密集型端点（如 Gitea 的 tarball 生成），这给网站所有者带来了实际的资源成本和性能问题。他们认为，网站所有者有权保护自己的资源和数据，并设定访问规则，不遵守规则的爬虫理应被拒绝。

此外，讨论中还涉及了封锁策略的权衡。虽然基于用户代理和速率限制的封锁是有效的初步措施，但过于激进的 IP 封锁可能会误伤使用 VPN 或其他隐私工具的合法用户。一些开发者提到了 Anubis 或 Tirreno 等更复杂的机器人管理工具，它们可能提供更精细的检测和应对手段，例如通过验证挑战来区分人类和机器人。

总的来说，这篇文章及其讨论揭示了当前互联网上一个日益突出的问题：随着 AI 训练对数据需求的增加，侵略性爬虫对小型网站造成的资源压力和运营困扰。社区对此既有技术层面的讨论（如何有效检测和封锁），也有伦理和哲学层面的辩论（公开数据的使用权、AI 抓取与传统索引的区别、网站所有者的权利与责任）。这反映了在新的技术浪潮下，互联网生态中不同参与者之间正在形成的紧张关系。

精密时钟 Mk IV：DIY 硬件的极致追求

今天，我们深入探讨一个在 Hacker News 上引起广泛关注的项目：精密时钟 Mk IV。这不仅仅是一个普通的时钟；它是一个关于在 DIY 硬件项目中实现极致时间精度和显示完美的深入探索。

项目目标与技术亮点

创作者 mitxela 旨在打造一款终极精密时钟，融入了前几代产品多年来的功能需求。核心目标是达到毫秒级精度，无任何可感知的抖动，以及即使在每秒 20,000 帧的相机下也无闪烁的稳定显示——这一挑战促使他避免了主数字显示采用传统的 PWM 方式。

文章详细介绍了这个雄心勃勃的项目从构想到实现的过程。主要功能包括纯粹基于 GPS 坐标的自动时区检测，无需互联网或蜂窝连接——这是一个出人意料的复杂问题，需要板载世界地图数据和预计算的时区数据库。一个突出的机械特性是铰链式设计，允许时钟在宽阔的单行显示（模仿 ISO 时间戳）和更紧凑的两行格式之间转换。

在技术层面，这个时钟堪称奇迹。它使用了两个微控制器和一个基于电压控制 LED 和缓冲芯片的定制显示驱动系统，通过 DMA 驱动，实现了显示更新的零 CPU 开销。亮度通过 DAC 和可调 LDO 改变这些缓冲芯片的供电电压来控制。铰链之间的连接仅通过四根线实现，巧妙地复用了电源、双向数据、模拟亮度控制和一个高精度锁存信号，利用 UART 时序。该项目还具有一个强大的链式加载引导程序，通过 USB 大容量存储轻松进行固件和数据更新，设计得像复制文件一样简单。作者讲述了克服重大硬件和软件挑战的经历，从调试由不良 PCB 布局引起的振荡器干扰，到处理复杂的中断优先级，以及将桌面级代码（如时区检测）移植到内存有限的微控制器上。该设计甚至包括一个带校准 RTC 的电池备份，以便在断电时保持准确时间，并且如果 GPS 信号丢失，显示会动态降低精度（减少数字）。

社区讨论与洞察

围绕这项工程壮举，社区展开了热烈的讨论。

普遍的反馈是压倒性的积极。许多开发者对项目的技术雄心、对细节的精益求精以及详细描述设计过程的精美文章表示敬佩。一些实际拥有者证实了其令人印象深刻的无闪烁显示和高精度，称其为“艺术品”。还有用户表示他们日常使用前几代产品来同步高速视频处理，并计划购买新款，这突显了其在特定小众领域的实用价值。

技术讨论同样引人入胜。开发者深入探讨了时钟的精度，辩论了 GPS 信号抖动（可能数百纳秒）与显示毫秒级分辨率所施加的限制，以及两个铰链显示器之间如何保持同步。PCB 设计选择引发了讨论，特别是作者自我施加的两层板限制及其对 EMI/EMC 性能的影响。一些开发者质疑某些布局选择在实现低辐射发射方面的可行性，而另一些则为该方法辩护，或指出主要的大电流信号（LED）的开关频率相对较低，低于标准 EMI 合规范围。Micro-USB 而非 USB-C 的选择也引起了关注，讨论了焊接难度和基本 USB-C 电源输入所需的简单电阻设置等实用点。

自然地，社区也提出了对潜在 Mk V 的功能请求和想法，包括添加 NTP 服务器功能、WiFi，甚至集成芯片级原子钟，以在 GPS 丢失时实现终极保持精度。自动时区功能因其复杂性以及使用板载地图数据和预计算数据库的优雅解决方案而受到特别赞赏，尽管一些用户询问了手动设置与当前位置不同时区的可能性。

总的来说，精密时钟 Mk IV 被视为一个卓越的、技术深厚的项目，它突破了 DIY 硬件的界限，通过巧妙的工程设计和对质量的执着，解决了复杂的问题。它真正体现了 Hacker News 社区所蕴含的热情和技能。

“鸡化逆向半人马”的复仇：算法控制下的劳动与反抗

今天，我们深入探讨 Cory Doctorow 在 Pluralistic 上发表的一篇引人深思的文章，题为《Revenge of the Chickenized Reverse-Centaurs》。

算法、劳动与剥削

文章探讨了技术、劳动和剥削的交集，用一些生动的术语来构建讨论。其核心是探讨算法和数字平台如何被用来对工人施加控制，反驳了这仅仅是自由市场中个体谈判的观点。

Doctorow 引入了两个关键概念：

首先，“半人马”（centaur），借用自 AI 领域，描述的是人机协作，其中人被机器增强——想象一位使用电脑的国际象棋大师。人是主导，机器是工具。

其次，“鸡化”（chickenization），一个来自劳动领域的术语，指的是剥削性的安排，其中名义上独立的工人或小企业变得依赖于单一的主导买家或加工商。就像美国家禽养殖户受制于少数垄断性加工商一样，这些工人被规定了投入、流程和时间表，但对他们获得的报酬没有议价权，使他们长期负债且没有筹码。

文章认为，以 Uber、Amazon Delivery 和 DoorDash 等公司为代表的零工经济，正在将这两个概念融合。零工工人正在成为“逆向半人马”（reverse-centaurs）——算法是“大脑”，通过摄像头等监控技术指挥任务、路线和监控绩效，而人则被简化为“身体”，执行算法命令的物理组件。这与“鸡化”相结合，这些“独立承包商”受到平台的控制，通常必须使用特定的设备或车辆，并且在工作完成之前对总报酬等关键信息一无所知。这使得平台能够诱骗工人从事无利可图的任务，有效地以牺牲工人为代价来补贴低廉的客户价格。

Doctorow 认为，这不仅仅是个人选择的问题；这是一种结构性的权力不平衡，其中整合后的公司与原子化的工人进行谈判。历史上，工会提供了工人力量，但几十年的反工会努力削弱了它们。然而，文章指出劳工组织正在复苏，并越来越多地利用技术来对抗雇主策略。

反算法行动主义

这引出了“反算法行动主义”（counter-algorithmic activism）的概念——工人利用技术来重新获得自主权。例子包括：

像 Para 这样的应用程序，揭示 DoorDash 等平台上的隐藏薪酬信息，让工人能够做出明智的决定，并可能自动化地让平台相互竞争。

像 #DECLINENOW 这样的运动，工人集体拒绝低薪工作，迫使算法提高报价。

更直接的“黑客”行为，比如亚马逊司机将手机挂在仓库附近以操纵调度算法，或者印度尼西亚的 tuyul 应用程序，通过伪造 GPS 数据帮助司机避开危险交通或获得更好的工作。

将此扩展到在线创作者（TikTok、YouTube），他们的生计依赖于不透明的算法，迫使他们使用“算法语言”来绕过过滤器。Tracking Exposed 等倡议有助于逆向工程这些算法，为创作者提供透明度和工具。

文章总结说，这种理解和“掌控算法”的斗争至关重要，不仅对零工工人、在线创作者，而且随着“老板软件”（bossware）和算法管理变得越来越普遍，可能对所有工人都是如此。

社区讨论与洞察

围绕这篇文章，讨论深入探讨了论点的几个方面。

许多开发者立即认识到其中的反乌托邦潜力，并将其与现有文学和历史进行类比。Marshall Brain 2003 年的著作《Manna》经常被提及，该书描述了一个自动化普及、社会两极分化（一些人靠 UBI 生活，另一些人从事算法管理的零工服务）的未来，被认为具有惊人的预见性。关于“公司商店”和“工资奴役”的历史例子，特别是通过歌曲《Sixteen Tons》所引用的，与“鸡化”概念产生了强烈共鸣，强调这种形式的依赖并非全新，只是技术上得到了更新。

“鸡化”的例子本身引发了关于家禽业现实的详细讨论。开发者证实了合同的压迫性，加工商通常拥有家禽和饲料，根据效率指标向农民支付报酬，而农民则承担基础设施成本和风险。讨论随后转向了农民为何不直接加工和销售自己的鸡。开发者指出了重大障碍：严格的食品安全法规要求昂贵、专业的设施；与工业加工商竞争所需的巨大规模；建立分销渠道到主要零售商的挑战；以及大型加工商对试图独立或组建合作社的农民进行报复或抵制的可能性。

文章中“非熟练劳动”（unskilled labor）一词的使用也引起了一些开发者的反驳。他们认为，通常被标记为“非熟练”的工作，如驾驶或清洁，仍然需要重要的技能、职业道德和经验，这些都会极大地影响绩效和工人福祉。他们认为这个词通常被贬低性地用来为低工资辩护，而“高供给”可能更准确地描述那些进入门槛低的工作，这些工作由于市场力量自然会压低工资，无论实际技能如何。

最后，还有一场关于资本主义本身的更广泛的哲学辩论。一些开发者认为剥削是资本主义的固有特征，无论监管如何，并引用了剩余劳动价值等概念。他们认为需要根本性的变革，即使确切的替代系统尚不清楚。另一些开发者则反驳，质疑在没有具体、经过验证的替代方案的情况下放弃资本主义的呼吁，认为尽管它有缺陷，但它可能仍然是“最不坏”的选择。

总的来说，讨论强化了文章关于算法和平台对工人日益增长的权力的核心论点，同时增加了历史背景、剥削机制的实际细节，以及对劳动、技能和经济体系性质的细致辩论。

韦布望远镜助力哈勃常数：宇宙膨胀率的新洞察

好的，各位听众，今天我们要聊的是来自 Hacker News 上一篇关于宇宙学的重要文章，标题是“Webb telescope helps refine Hubble constant”。这篇文章发表在 phys.org 上，讨论了詹姆斯·韦布空间望远镜（JWST）如何帮助我们更精确地测量宇宙的膨胀速度，并可能解决一个长期存在的宇宙学难题。

文章主题概括

这篇文章的核心是利用詹姆斯·韦布空间望远镜的最新数据，对宇宙的膨胀率——也就是哈勃常数——进行了新的测量。这项新的测量结果与早期宇宙测量值更加接近，这可能意味着困扰宇宙学家多年的“哈勃张力”（Hubble tension）并非源于标准宇宙模型的缺陷，而是测量误差。

文章重点内容阐述

长期以来，科学家们在测量宇宙膨胀速度时遇到了一个棘手的问题。通过观测宇宙早期遗留下来的宇宙微波背景辐射（CMB）得出的哈勃常数值，与通过测量附近星系和超新星等天体得出的当前宇宙膨胀值存在显著差异。前者大约是 67.4 千米/秒/百万秒差距，而后者通常在 73 左右。这个差异被称为“哈勃张力”，它挑战了我们目前对宇宙的最佳描述——标准宇宙模型。如果这个张力是真实的，可能意味着我们需要新的物理学来解释宇宙的演化。

文章指出，芝加哥大学的 Wendy Freedman 教授团队利用强大的詹姆斯·韦布空间望远镜，结合哈勃望远镜的数据，对本地宇宙的膨胀率进行了更精确的测量。韦布望远镜的优势在于其极高的分辨率（是哈勃的四倍）和灵敏度（约十倍），尤其是在红外波段。这使得科学家能够：

穿透星际尘埃： 尘埃会遮挡和扭曲可见光，是测量距离的主要障碍。韦布望远镜的红外能力可以有效地看穿尘埃，获得更清晰、更准确的恒星亮度数据。

分辨单个恒星： 在遥远星系中，哈勃望远镜可能只能看到模糊的恒星群，而韦布望远镜可以分辨出用于测量距离的关键恒星，比如造父变星、红巨星和碳星。

增加样本量和精度： 通过更清晰的观测，团队能够将用于校准超新星的星系样本量增加一倍以上，显著提高了统计精度。

基于这些改进的测量，Freedman 团队得出了一个新的哈勃常数值：70.4 千米/秒/百万秒差距，误差为 ±3%。这个值与宇宙微波背景测量值 67.4 ± 0.7% 在统计上是吻合的。这意味着，哈勃张力可能并非是标准模型的问题，而更可能是本地测量方法中存在的系统性误差导致的。

Freedman 教授表示，这项新证据表明标准宇宙模型目前看来是站得住脚的，至少在哈勃常数这个问题上是如此。尽管科学家们仍在努力寻找标准模型的“裂缝”来解释暗物质和暗能量等未解之谜，但哈勃常数可能不是突破口。团队计划明年继续使用韦布望远镜观测后发星系团（Coma cluster），以期获得更直接、更高精度的测量结果。

社区观点总结与分析

社区对这个话题展开了热烈讨论，主要围绕以下几个方面：

距离阶梯的可靠性： 许多开发者认为，用于测量本地宇宙膨胀率的“宇宙距离阶梯”（Cosmic Distance Ladder）是整个测量中最薄弱的环节，容易累积误差。他们提到对超新星作为“标准烛光”的假设、尘埃的影响等。普遍认为，提高距离测量的精度是解决哈勃张力的关键。文章中韦布望远镜在穿透尘埃和分辨恒星方面的优势，正是直接回应了这一担忧。

误差棒与统计显著性： 有开发者对文章中声称的“统计上吻合”提出了疑问，因为简单计算两个测量值的误差范围似乎并不重叠。其他开发者则解释了科学测量中的误差通常是基于标准差（sigma）的，而非简单的均匀分布范围。他们计算得出，这两个值之间的差异大约是 1.4 sigma，这在物理学领域通常不被认为是具有高置信度的、需要新物理来解释的显著差异（通常需要 5 sigma）。这部分讨论很好地展示了科学结论的严谨性，以及理解统计学在解释实验结果中的重要性。

对新物理的期待与“失望”： 一些开发者表达了一种“沮丧”的情绪，认为像大型强子对撞机（LHC）和韦布望远镜这样的新工具，似乎更多地是证实了现有理论，而不是发现急需的新物理来解释暗物质、暗能量等问题。他们期待看到能“打破”标准模型的发现。这反映了科学探索中，既有证实现有理解的价值，也有突破边界、发现未知领域的渴望。

哈勃“常数”的含义： 有开发者提出了基础性问题，比如为什么宇宙膨胀率会随距离增加（用气球模型解释了空间本身的膨胀），以及为什么一个随时间变化的量被称为“常数”（解释了它在空间上是常数，但在时间上是变化的）。这些讨论对于非专业听众理解核心概念非常有帮助。

科学研究的价值与资助： 讨论中出现了大量关于 NASA 预算削减、科学资助重要性、政府机构效率与私人资助的优劣等话题。虽然偏离了文章的科学内容本身，但这反映了社区对科学研究整体环境的关注，以及对韦布望远镜这样重大项目的价值的认可。

总的来说，这篇关于韦布望远镜测量哈勃常数的文章，不仅带来了重要的科学发现——可能解决了哈勃张力并支持了标准宇宙模型——也引发了社区对测量方法、统计解释、科学进展方向以及科学资助等多个层面的深入讨论。韦布望远镜的强大能力正在以前所未有的精度揭示宇宙的奥秘，即使结果是证实了现有理论，其背后的技术进步和对理解宇宙基础参数的贡献仍然是巨大的。

更简单的退避策略：算法生成与查找表的权衡

今天我们来聊聊一个在分布式系统和网络编程中非常常见的话题：重试机制，特别是指数退避（Exponential Backoff）和抖动（Jitter）。这篇 Hacker News 文章《Simpler Backoff》提出了一种让这种机制更“简单”的实现方式。

指数退避与抖动

文章首先展示了指数退避加抖动的一种典型 Go 语言实现。这种实现方式通常涉及一个循环，在每次失败后，计算下一次重试的等待时间。计算方法是基于前一次的等待时间乘以一个因子（比如 2），然后限制在一个最大值内，并加入一个随机的抖动量（比如 ±25%），以避免大量客户端同时重试导致服务器雪崩。代码中定义了最大尝试次数、基础延迟和最大延迟等常量，并在循环内动态更新延迟值。

作者认为，虽然这种算法实现很常见，但可以通过使用查找表（lookup table）的方式使其更简单。他提出了另一种 Go 代码实现，直接定义了一个包含所有重试延迟时间的数组。每次失败后，代码直接从数组中取出对应尝试次数的预设延迟值，然后加上抖动。作者认为这种方式变量更少，作用域更小，更容易理解每次迭代的行为，而且计算错误不会影响后续的延迟值，因此更具可读性和可编辑性。他总结说，对于少量、固定的值集合，与其编写代码生成它们，不如直接使用查找表。

社区讨论与洞察

围绕着哪种实现更“简单”以及查找表的适用性，开发者们展开了热烈讨论，呈现了多样化的观点：

许多开发者对查找表是否真的“更简单”提出了质疑。他们认为，虽然查找表在某些固定场景下可能直观，但对于需要根据不同服务或不同情况调整重试策略的场景，算法生成的方式更加灵活。如果需要不同的退避策略，使用查找表意味着要创建多个不同的表，或者在运行时生成表，这反而增加了复杂性。

有开发者提出，原有的算法实现可以通过更好的参数化来提高灵活性和可读性，例如将基础延迟、增长因子、最大延迟等作为参数传入函数。还有人建议使用 Go 语言新支持的迭代器（iterator）或生成器（generator）来封装退避逻辑，这样可以在循环外部以更声明式的方式使用它，同时保留参数化的能力。

关于可读性，一些开发者认为，指数退避的算法模式是业界普遍接受和熟悉的，因此原有的算法实现对有经验的开发者来说反而更易读。而查找表虽然直观，但如果尝试次数很多，列表会变得很长，维护起来可能更麻烦。

抖动的重要性在讨论中被反复强调，被认为是防止“重试风暴”的关键。有开发者引用了 AWS 关于重试策略的文档，进一步说明了抖动和更高级的自适应重试（adaptive retries）策略（服务器可以向客户端提供重试建议）在大型分布式系统中的重要性。自适应重试可以帮助系统在过载时更好地分散客户端的重试请求。

也有开发者认为，文章的重点可能更多在于倡导一种“声明式”的编程风格，即直接声明所需的结果（延迟列表），而不是描述如何计算结果。

总的来说，虽然文章提出了一个有趣的简化思路，但社区的讨论表明，对于退避策略的实现，“简单”的定义取决于具体的应用场景和需求。灵活性、可参数化能力以及在大型系统中的行为（如防止重试风暴）是开发者在选择实现方式时需要重点考虑的因素。查找表可能适用于固定、简单的场景，但对于更复杂或需要动态调整的场景，参数化的算法或更高级的抽象（如迭代器或专门的库）可能更为合适。

相关链接：

Beware of Fast-Math
Valkey Turns One: Community fork of Redis
Gradients Are the New Intervals
Reverse engineering of Linear's sync engine
Mary Meeker's first Trends report since 2019, focused on AI
Using lots of little tools to aggressively reject the bots
Precision Clock Mk IV
Revenge of the Chickenized Reverse-Centaurs
Webb telescope helps refine Hubble constant
Simpler Backoff

...more

Share Agili 的 Hacker Podcast

Sign up to save your podcasts

Agili 的 Hacker Podcast

FAQs about Agili 的 Hacker Podcast:

How many episodes does Agili 的 Hacker Podcast have?

Agili 的 Hacker Podcast episodes:

FAQs about Agili 的 Hacker Podcast:

How many episodes does Agili 的 Hacker Podcast have?