系统与数据库2024usenix.org
负载不是你应该均衡的东西：介绍 Prequal
Load is not what you should balance: Introducing Prequal
进阶 · 约 45 分钟读完前置知识：分布式系统基础、负载均衡概念、尾延迟概念
导读
Google 在 NSDI'24 发表的 Prequal 论文，针对 YouTube 等大规模服务的负载均衡问题。核心观点是传统基于 CPU 负载的均衡并不合适，Prequal 改为根据估计延迟和在途请求数（requests-in-flight）来选择服务器，在 YouTube 上实现了尾延迟降低 2 倍、尾 RIF 降低 5-10 倍、内存和 CPU 尾部占用改善 10-20%/2 倍，并显著提高了数据中心利用率目标、节省大量资源。
HN 关注点：大规模分布式系统的负载均衡实践，讨论焦点在于“不均衡负载”的说法是否成立，以及业界是否真的还在用简单 CPU 利用率做均衡。
HN 评论精选
这几条评论里：支持 1 质疑 2 补充 1
支持惊叹 Prequal 带来的收益规模巨大，远超个人职业价值
论文引用：Prequal 在 YouTube 上所有指标都有显著改善，包括尾延迟降低 2 倍、尾 RIF 降低 5-10 倍、尾内存占用降低 10-20%、尾 CPU 利用率降低 2 倍，并几乎消除了因负载不均导致的错误。除了满足 SLO，这还让 Google 能大幅提高各数据中心的流量利用率目标，节省了大量资源。这感觉就像“我公司省下的钱超过我整个职业生涯的预期收入”。
djoldman查看英文原文
> With Prequal we saw dramatic improvements across all metrics [for youtube], including reductions of 2x in tail latency, 5-10x in tail RIF, 10-20% in tail memory usage, 2x in tail CPU utilization, and a near-elimination of errors due to load imbalance. In addition to meeting SLOs, this also allowed us to significantly raise the utilization targets that govern how much traffic we are willing to send to each datacenter, thereby saving significant resources. This feels like one of those "my company realized savings greater than my entire career's expected compensation."
质疑质疑标题：按延迟和在途请求数选服务器本质上还是负载均衡
来自论文：Prequal 并不均衡 CPU 负载，而是根据估计延迟和在途请求数来选择服务器。所以，这仍然是负载均衡。
andyg_blog查看英文原文
From TFA: > PReQuaL does not balance CPU load, but instead selects servers according to estimated latency and active requests-in-flight So, still load balancing
质疑质疑业界是否真以简单 CPU 利用率作为均衡依据
人们真的在用简单的 CPU 利用率为非平凡服务做负载均衡吗？这让我很惊讶，但论文却把这当作当前的最佳实践来呈现。
lokar查看英文原文
Are people really balancing load based on simple cpu utilization for non-trivial services? That seems really surprising to me, but they present it as the current best practice?
补充补充：AWS S3 早已弃用传统负载均衡，但从未公开其方法
我很惊讶 S3/AWS 还没发博客或白皮书介绍他们的方法。他们放弃标准负载均衡已经大约 7 年了。想想对象存储平台，和 YouTube 一样，传统负载均衡非常不合适——没有任何两个请求在资源需求和持续时间上是相同的。
Twirrim查看英文原文
I'm surprised that S3/AWS hasn't blogged or done a white paper about their approach yet. It's been something like 7 years now since they moved away from standard load balancing. If you think about an object storage platform, much like with YouTube, traditional load balancing is a really bad fit. No two requests are even remotely the same in terms of resource requirements, duration etc.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖173 分 · 72 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选