在程序化音频广告领域，101毫秒意味着零收入。这不是性能问题，而是生存问题。 我们运营着一个音频广告DSP平台， 每一个请求都必须在 如果错过这个时间窗口，竞价就会被取消。如果延迟到101毫秒，我们的平台基本上就无法运作了。 每天处理大约3.5亿个请求，每周约20亿个。 100毫秒内完成接收、评估和响应。 我们仅用一个三人工程团队就实现了这一点，每月云费用控制在 1 万美元以下。同一个团队负责所有工作——竞标基础设施、应用层、数据库和运维。   RTB生态系统 如果你对广告技术不太了解，这里简单概括一下。程序化广告基于实时竞价（RTB）机制运行。 供应方是  。这些平台如 AdsWizz 或 Triton，它们聚合了来自数千个应用程序和发布商（包括播客播放器、流媒体应用程序和其他音频平台）的广告资源。 SSP（供应方平台） 需求方是  ——像我们这样的系统，代表广告商，并实时决定是否对某个广告展示进行竞价。 DSP（需求方平台） 当听众打开播客应用且有广告位可用时，应用会与其供应方平台 (SSP) 通信。SSP 随后会向多个需求方平台 (DSP) 发送竞价请求。我们的系统接收到请求后，会评估用户和正在进行的广告系列，计算出价，并返回响应。所有这些操作都必须在 100 毫秒内完成。 在这里，延迟不仅仅是一个指标，它本身就是结果。 一旦我们接受了这一点，很明显，标准的 Web 应用模式行不通。我们无法承受微服务之间的网络跳转，更无法承担庞大的 Kubernetes 部署带来的高昂云费用。为了生存，我们必须首先针对各种限制条件进行设计。 这种限制并非理论上的。早期，当我们还有云额度时，我们并不太在意效率。但一旦额度用完，每一个架构决策都突然有了实际的成本。那时，我们不得不重新审视并设计系统，以优化延迟、降低成本并简化运维。 接下来介绍的架构可以让一个三人团队大规模运行全球 RTB 系统，而无需花费大量资金或承受失眠之苦。  1. 地理作为第一筛选条件：网络物理设计 我们集成的主要音频SSP平台 分别位于美国、欧洲和东南亚。而我们的应用层（负责处理印度广告主的广告系列逻辑）则位于印度。 ——Triton、AdsWizz、Magnite（原Rubicon）和MCTV—— 仅这些区域之间的原始网络往返时间就约为 ，这还不包括任何应用程序逻辑的运行时间。这已经使我们超出了允许预算的两倍多。 240 毫秒 解决方案很简单，但没得商量。我们将竞价集群部署在 ：美国西部（俄勒冈州）、欧洲中部（法兰克福）和亚太地区（新加坡和香港）。 四个战略性的 AWS 区域 这样就确保了当 SSP 发送竞价请求时，我们与硬件之间的距离可以忽略不计——通常只有几毫秒——从而将 100 毫秒预算的大部分用于实际计算。  2. 单体-微服务混合架构 我们最终采用了一种介于传统单体架构和微服务架构之间的架构。我们没有将服务分散在整个网络中，而是将一 ，然后通过全局负载均衡器对这些虚拟机进行水平扩展。 小群紧密耦合的服务部署在单个虚拟机上 每个虚拟机都被视为一个单独的节点，其内部结构就像一个微型分布式系统：    ：一个充当内部流量控制者的单一入口容器。 Nginx ：在同一台机器上运行 3-5 个 Node.js 竞价服务副本，以充分利用 CPU。 竞价方    ：一个与代码并行运行的本地 Redis 实例。 Redis 这样做的好处是数据本地化是默认的。竞标者无需跨越网络获取数据，而是直接从本地主机读取。这也使我们能够大幅提高 。通过使用更大的虚拟机（例如 c6i.xlarge）并在多个工作节点之间共享单个内存数据集，我们可以获得更好的内存与 CPU 比率，从而在最大限度提高吞吐量的同时最大限度地减少资源浪费。 资源密度  3. 逻辑：快速失败 要达到 100 毫秒的截止时间，仅仅编写快速的代码是不够的。系统必须能够快速决定何时停止执行任务。 大多数收到的竞价请求最终都不会成功。允许这些请求访问状态、数据库或写入路径是耗尽延迟预算的最快方法。我们将竞价器构建成一个决策树，按“失败可能性”排序，优先执行成本最低的检查。 检查大致按以下顺序进行： ：很大一部分出价会在这里失败。这是一个简单的比较，几乎可以立即得出结果。 地理位置检查 ：如果地理位置通过，我们将验证平台和设备限制。 操作系统和设备检查 ：检查应用是否符合我们允许的库存范围。 发布商/应用定位 ：只有当请求通过这些过滤器后，我们才会处理更复杂的路径——用户级数据、预算和节奏逻辑，或任何需要协调的内容。 有状态逻辑 通过快速失败，我们可以在几微秒内拒绝 90% 的流量，从而将 CPU 周期留给真正能带来转化的出价。  4. 数据架构：Redis 用于规则，Aerospike 用于用户画像 我们根据访问模式和“过时”成本将数据架构分为两层。 规则：本地 Redis 每个节点在其本地 Redis 中保存“热门”元数据（活跃活动和预算上限）。一个定时任务使用 ，每 60 秒访问一次我们的中央 API 以下载最新的“真实数据”。 拉取模型 在我们这样的规模下，这 60 秒的数据滞后会带来一个风险： 。如果多个节点同时使用同一份过时的预算数据，它们可能会花费超过客户端分配的金额。 超支 我们通过一种 来解决这个问题：我们将车队规模作为预算控制的输入。随着活跃竞价节点数量的增加，每个节点可动态地减少其预算“份额”。即使节点正在处理过时的数据，其本地限额也已根据当前车队规模进行了限制。支出会平稳下降，而不是出现峰值，系统会在下一个刷新周期到来时收敛。 制动机制 简介：Aerospike（固态硬盘优势） 用户级数据概况查询、频率限制和重定向需要亚毫秒级访问海量可变数据集。传统的RDBMS无法以我们目前的价位处理这种负载。 我们之所以选择 作为这一层，是因为它针对 SSD 作为主存储进行了优化，而不是将整个工作集都保存在 RAM 中。这使我们能够获得可预测的延迟，同时将硬件成本控制在纯 RAM 解决方案（例如 ElastiCache）的一小部分。 Aerospike 为了保持这一层的成本可控，我们对数据卫生要求毫不妥协： 十天规则：我们只保留最近 10 天内活跃用户的数据。  1000万上限：我们主动将数据集精简到最活跃的几百万用户。 如果用户停止活动，其数据将被删除。这种机制确保存储成本保持不变，同时竞标者能够专注于真正重要的用户。  5. “异步”的秘密：解耦负担 我们的第一个版本在技术上尝试了异步操作。我们会立即发送竞价响应，并让 Node.js 函数在后台继续运行，将日志写入 MongoDB。 ：流量并非平稳，而是呈爆发式增长。在高峰期，即使竞价响应已经结束，我们的 Node.js 容器仍然处于“浮空”状态——保持着打开的连接，并消耗大量 CPU 资源试图完成数据库写入。这导致我们的自动扩缩容系统启动更多虚拟机来处理 ，最终导致数据库连接数激增而崩溃。 陷阱 积压的写入操作 ：我们从“异步代码”转向了“ ”。我们引入了 作为竞价方和写入路径之间的缓冲层。现在，竞价方向 Kafka 推送消息后，即可立即释放其资源。“写入”操作则由一个独立的消费者集群以可控的速度处理。 解决方案 异步架构 Kafka  6. 基准测试：衡量，而非猜测 在这种规模下，猜测实例类型成本很高。因此，我们没有依赖理论，而是进行了基准测试。 我们提出了一些假设，例如竞标者是受限于计算能力还是内存资源，每个节点运行多少个工作进程比较合理，以及实例大小如何影响延迟。我们测试了多种 AWS 实例系列和大小，并改变了单个节点上运行的竞标服务数量。 我们对数据层也采用了同样的方法，尝试不同的机器类型，看看哪种最适合 MongoDB 在实际负载下运行，优先考虑稳定的延迟而不是峰值吞吐量。 所有这些都通过负载测试进行了验证，测试中系统承受了类似生产环境的每秒查询量 (QPS)，并测量了响应时间和尾延迟。一些假设成立，但许多假设不成立。 结论很简单： 。 在 100 毫秒的预算下，基准测试结果总是比理论结果更准确  7. 财务运营：我们如何将账单控制在 1 万美元以内 初创公司不会因为流量激增而倒闭，而是会在云服务额度耗尽时倒闭。对我们而言，成本控制并非事后考虑，而是系统设计的一部分。 部分节省来自于谈判。我们通过经销商进行计费，从而获得了固定的批量折扣。带宽方面，我们承诺 数据，这使我们能够将 CDN 的价格谈判降低 60% 以上，远低于按需付费的价格。在我们目前的流量水平下，这一项承诺就带来了显著的成本节约。 每月传输约 1 PB 的 我们还区分了不同的关注点：无状态竞价服务器运行在大幅折扣的竞价容量上，而有状态数据库使用可预测的、长期存在的实例。 在我们这样的规模下，每天存储数亿条记录无异于一颗定时炸弹。详细的竞价日志保留时间很短——以天为单位，而不是以月为单位。我们需要保留的数据会尽早进行汇总——按小时而不是按事件——并迁移到更便宜、更便于查询的存储介质中。任何仅用于合规性或历史审计的数据都会被放入冷存储，与标准存储层相比，成本可降低 80% 到 90%。 不过，最省钱的并非折扣，而是 。 利用率 大多数系统为了“安全起见”会将 CPU 利用率保持在 20% 到 30%。但我们的系统则无需如此。由于我们的架构具有容错能力，并且能够优雅地卸载负载，因此我们可以放心地将 CPU  。我们不会为空闲周期付费。如果我们为某个核心付费，那么该核心就处于竞价状态。 利用率保持在 80% 这种将效率视为首要约束的思维方式，即使交通流量增长，也能使账单保持不变。  8. 三人运营模式：“学费”理念 只有当系统而非人承担所有负载时，三人团队才能在全球范围内高效运营。我们设计的运维流程旨在消除关键路径上的人为干预，并尽可能消除单点故障。此外，我们避免角色孤岛——每位工程师都能掌握全栈技术——因此运维知识绝不会成为单点故障。 基础设施默认是可抛弃的。如果某个节点出现异常，我们不会就地调试，而是直接终止它，并让自动扩缩器替换它。恢复速度比故障排查更快，而且每个实例都来自一个已知且干净的状态。 可观测性固然重要，但仅靠仪表盘对小型团队来说远远不够。我们依赖于可操作的警报（通过 Datadog），这些警报仅在需要人工干预时才会触发。如果区域集群运行缓慢或某个消费者出现延迟，我们会收到通知。其他一切都是自动化的。 然而，自动化并非魔法。我们仍然需要不时缴纳学费。 在早期的一次事件中，负责刷新预算状态的后台任务悄无声息地失败了。竞价方继续使用过时的数据，并在一个本应结束的广告系列上花费了资金——这是一个典型的“僵尸竞价方”案例。我们退还了客户的款项，修复了数据漏洞，并通过Datadog监控的心跳检测机制加强了系统。现在，预算的更新状态是明确显示的，任何静默操作都会触发警报。如果竞价方没有收到有效的更新，则会被判定为失败并关闭。 在小团队中，犯错在所难免，但 重蹈覆辙则是可以选择的。 结语 这个系统中的每一个决策本身都不算奇特。它成功的关键在于这些决策如何叠加作用。 网络物理机制设定了边界。局部性和快速故障逻辑保护着100毫秒的路径。异步边界吸收流量突发。测量取代了直觉。成本控制和高利用率确保了经济效益的合理性。运维设计使得只有在系统无法自行恢复时才需要人工干预。 这并非一篇关于广告技术或特定技术栈的文章。它提醒我们，在规模化应用中， 。当你将延迟、成本和人力成本视为首要需求时，最终形成的架构往往会更简洁，而非更复杂。 限制因素并非障碍，而是设计输入 目标不是建造令人惊叹的东西，而是建造能够经受住时间考验的东西。

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

該音頻是用故事的原始語言製作的！

20亿次请求，100毫秒截止时间，每月1万美元预算：构建精益的全球实时竞价系统

About Author

註釋

標籤

这篇文章刊登在

Related Stories

成功云迁移的完整指南：策略和最佳实践

从论坛到信息流：社交媒体算法如何塑造数字互动

使用这 18 种开发工具来提高你的工作效率 🚀🔥

Floki 的 Valhalla 成为印度环斯里兰卡赛事联合赞助商

成功云迁移的完整指南：策略和最佳实践

从论坛到信息流：社交媒体算法如何塑造数字互动

使用这 18 种开发工具来提高你的工作效率 🚀🔥

Floki 的 Valhalla 成为印度环斯里兰卡赛事联合赞助商

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps