问题的历史
早期的广告投放依赖于静态瀑布配置，出版商依次优先考虑需求合作伙伴，造成延迟瀑布和收入泄漏。转向Header Bidding和OpenRTB协议使库存访问民主化，但也带来了极端的工程约束：竞拍必须在100毫秒内完成，以防止页面放弃，预算执行必须防止在数千个边缘节点上超支，欺诈检测必须在线进行而不增加网络跳数。这个问题的出现源于需要用能够自主做出财务决策的边缘计算架构替代集中式Apache Kafka管道，同时保持严格的可审计性和数据驻留要求。
问题
传统架构依赖于集中式PostgreSQL或Redis集群作为预算计数器和特征存储，在流量高峰（如黑色星期五）期间创建跨区域延迟，违反100毫秒的服务水平协议。对预算减少的天真的乐观锁定造成了雷鸣般的效应和投标丢失，而异步欺诈检测则允许机器人在检测触发之前消耗活动预算。此外，跨DSP（需求方平台）的账单调解由于网络分区而受到影响，尽管展示像素触发，但确认消息却掉落，导致收入泄漏或重复收费，破坏了广告主信任。
解决方案
在边缘PoPs（接入点）中部署带有WebAssembly过滤器的Envoy Proxy边车，以在距离最终用户10毫秒内运行竞拍逻辑。使用Redis和Gossip协议实现基于CRDT（无冲突的复制数据类型）计数器来进行预算节奏，允许边缘节点本地接受投标，同时通过最终收敛确保全局预算一致性。在边缘层中嵌入轻量级的TensorFlow Lite模型，以利用行为指纹（如鼠标速度模式和导航熵）进行实时机器人检测。使用带有Geo-Replication和BookKeeper的Apache Pulsar创建不可变审计日志，通过幂等生产者和去重复窗口确保精确一次的语义。为了遵循GDPR合规，实施K-匿名性检查和通过Anycast DNS进行数据驻留路由，同时保持EDNS客户端子网感知。
在2023年黑色星期五活动期间，我们的平台经历了40倍的流量激增，饱和了我们集中式的Redis预算存储在us-east-1，导致12%的竞拍超时，威胁到200万美元的潜在收入损失。工程团队面临一次关键的架构决策：维持强一致性并接受延迟违规，还是优先考虑速度并冒着灾难性的预算超支风险。
解决方案A: Redis集群与Redlock
我们考虑在五个独立的Redis主节点上实施Redlock算法以执行严格的预算一致性。理论上，这种方法可以确保没有活动超出其每日上限，因为每次减少都需要多数同意。然而，边缘节点与Redis集群之间的往返时间平均为35毫秒，在负载下，锁争用导致8%的请求重试多次，超出了我们的100毫秒服务水平协议。尽管这提供了完美的预算准确性，但不可接受的延迟和操作复杂性使其不适用于实时竞标。
解决方案B: 本地内存缓存与异步同步
另外，我们评估允许每个边缘节点维持纯本地预算计数器，每30秒异步同步到中央账本。这实现了低于5毫秒的竞拍延迟，并在没有外部依赖的情况下优雅地处理了流量激增。不幸的是，在激增期间，多个边缘节点共计超售了80万美元的高价值活动，导致广告主信任问题和合同处罚。速度是最佳的，但财务风险对于支付相关系统而言是灾难性的。
解决方案C: 混合CRDT架构与分层节奏
我们实施了一种混合方法，使用Delta-State CRDTs在Redis的三个层次（边缘、区域和全球）中。这些边缘节点使用本地的PN-Counters（正负计数器）接收投标，并设置在全球预算的95%的保守本地阈值。当本地预算耗尽时，节点向区域缓存查询以获得Read-Your-Writes一致性。剩余的5%缓冲由全球账本使用CRDT合并在gossip同步期间管理。为了防范欺诈，我们在边缘节点上部署了训练用于检测机器人模式的TinyML模型，而无需网络调用。我们选择这个解决方案，因为它在保持99.9%预算准确率的同时，维持了45毫秒的p99延迟。
结果
平台在峰值期间处理了每秒1200万条查询，确保未超支限制活动的预算。欺诈检测延迟从150毫秒降至8毫秒，拦截了3.4%的恶意流量。在不同区域之间的CRDT调解实现了200毫秒内的最终一致性，完全在账单调解窗口内，同时GDPR合规通过边缘本地数据处理得以维持。
当多个边缘节点同时减少相同活动预算而不获取全局锁时，如何防止预算超支？
大多数候选人建议在Redis中使用分布式锁或原子减少操作，这在网络分区或高延迟的情况下会失败。正确的方法是使用实现为CRDTs的PN-Counters（正负计数器）。每个边缘节点维护一个本地的支出递增计数器和一个退款递减计数器。当节点接受投标时，它会增加其本地支出计数器。在gossip同步期间，节点交换其计数器状态并使用Join操作（取每个计数器组件的最大值）合并它们。为了防止临时超支，在本地实施令牌桶算法，设置保守的上限。如果所有本地支出的总和接近全局限制，则节点进入“节俭模式”，向区域协调器查询剩余的5%预算。这确保在分区期间虽然理论上可能发生1-2%的临时超支，但系统从未超过105%的预算，这对于数字广告服务水平协议是可以接受的，和传统银行系统恰好不同。
当用户浏览器的展示跟踪像素触发但网络故障阻止确认送达拍卖服务器时，如何确保精确计费？
候选人通常建议Kafka的幂等性或数据库的更新，而忽视了端到端的问题。解决方案需要在边缘生成的幂等键，使用UUIDv7（时间排序）嵌入在创意标记中。当浏览器触发展示像素时，它包含该键。边缘Nginx层以启用去重复的方式写入Apache Pulsar，使用24小时的窗口。Pulsar的BookKeeper存储确保具有相同键的重复写入在代理层级被丢弃，而不是消费者层级。此外，向按幂等键进行分区的BigQuery暂存表实施至少一次传递，使用合并语句在ETL过程中去重复。这种双层保护确保即使浏览器由于500错误重试50次像素触发，广告主仍仅被收取一次费用。
当根据响应时间确定竞拍获胜者时，如何处理地理分布投标者之间的时钟偏差？
这个问题很微妙。候选人通常建议使用NTP或TrueTime（来自Spanner），但这些会增加延迟。正确的架构消除了竞拍逻辑中的墙钟依赖性。与其比较DSP响应的时间戳，不如在边缘使用逻辑时钟（Lamport时间戳）或简单的FIFO队列。当竞拍开始时，边缘节点启动一个高分辨率计时器（Performance.now()在V8或C++ chrono中）。DSP响应根据到达顺序在网络接口中进行排名，而不是根据时间戳头。为了处理滞后者，实施一个使用自适应超时算法的可调超时，根据每个DSP的历史p99延迟进行调整。为了后续分析和账单争议，记录单调时钟读数和带有不确定性区间的UTC时间戳，将其存储在CockroachDB中，该系统可以自动处理不确定性窗口。这确保了即使一个DSP的服务器时钟比另一台快200毫秒，也能保证公平。