RTB无状态设计：把复杂计算下放给外部辅助系统，换取自身的快速可靠反馈

RTB引擎本身被设计成不带状态——它自己不存储、不维护任何关于用户画像、点击率历史、反作弊名单这类需要持续积累和更新的复杂数据，而是完全依赖点击率预测、人群定向、反作弊等外部辅助系统提供的现成结果，自己只做”接收请求→查询辅助系统结果→做出决策→返回响应”这样一条轻量级的处理链路。这个设计选择直接服务于[[RTB全链路百毫秒时延约束对架构的强制要求]]描述的极端时延要求：如果RTB引擎自己承担复杂的用户画像计算或模型训练，处理时间必然远超几十毫秒的预算；把这些重计算工作转移给独立的辅助系统去异步完成（离线训练模型、周期性更新画像），RTB引擎在处理每一次具体请求时，只需要做一次轻量的查询和打分，就能在极短时间内给出反馈。这也带来了架构上的一个重要收益：RTB引擎本身因为无状态，天然更容易水平扩展和快速恢复——任何一个RTB实例挂掉，重新拉起一个新实例就能立刻承接流量，不需要额外的状态迁移或数据恢复过程，这和很多高并发场景下”无状态服务层+有状态数据层分离”的经典架构模式是同一个思路。这个案例提示了一条通用的高并发系统设计原则：当某个组件必须满足极端的低延迟要求时，第一步往往不是去优化这个组件内部的算法，而是审视它承担的职责里，有多少是可以剥离出去、转移给专门的独立系统异步完成的——让核心响应链路只保留真正必须同步完成的最小逻辑。