推荐架构
客户RTA架构图
模块介绍
负载均衡
负载均衡用于承接来自于媒体的RTA请求，并将请求量相对平均的分配到内部的RTA DSP运算资源池。在典型场景中（全站点集下发，缓存1小时），媒体的并发请求量约为20-30W每秒，活跃连接数约5000，带宽约800-1000Mbps。选择更久的缓存时间以及选择合理的下发站点集可以降低对应资源的成本。
负载均衡是观察客户自身业务耗时的观测点，建议重点关注异常比例（非http 200返回数量）、平均耗时（合理值<=8ms），99耗时（合理值<=16ms）。
当客户侧服务质量不佳时，可能会引起媒体侧的大量新建连接涌入。建议负载均衡留有一定的冗余，以应对突发增长的连接量/请求量。
RTA DSP
RTA DSP即客户侧的RTA逻辑层。一般情况下内部主要划分为三类功能：协议适配、策略推荐、缓存访问。为了便于排查RTA投放异常，推荐加入日志记录功能。
协议适配用于接收、解析来自于媒体侧的RTA请求，并将推荐结果打包成对应媒体协议格式进行回复。在设计时要考虑长期规划是否需要对接多个媒体平台的多种协议。为了复用一套工程架构减少开发工作量，建议在协议适配模块将媒体请求转换为客户内部定义的通用信息结构，然后再交由策略推荐模块处理。当新接媒体RTA时可以尽可能小的改动直接复用核心功能。
策略推荐策略推荐是RTA DSP系统的实时决策大脑。根据RTA请求带来的设备信息，实验信息，广告信息(二次)，查询缓存中的人群包及模型数据，并最终计算出每个策略是否接受以及调整权重/出价的推荐结果。
缓存访问在RTA高并发短耗时的场景下，需要在极少的时间获取所需数据以供推荐计算。建议使用Redis或是其它等价性能的缓存系统，以设备号为key，以画像及模型所需数据为value，将整个数据读取过程控制在2ms以内。
日志与归因
日志用于用于回顾历史决策信息，分析异常。日志分为两类：1. 客户内部决策日志，具体格式及内容由客户根据业务需要确定。2. RTA交互日志，建议以RTA Request ID为key记录完整的http请求与回复body原始内容(protobuf binary，或protobuf 反序列化文本)。
由于媒体平台不会持久记录客户的RTA回复内容，当出现异常时媒体协助客户排查分析问题依赖于客户提供的RTA交互日志，以便于从交互层分析可能产生问题的原因。缺乏交互日志，或交互日志内容不完整会给排查工作带来困难。
归因请参阅归因分析
离线计算与缓存存贮
通过离线计算获得的人群包与模型输出到缓存中。注意在推送并写入缓存时控制写入速率，以免写入高负载拖累读取耗时引起媒体侧的自动质量打压。
缓存中的存贮格式由客户自由发挥，实践中建议以设备号为key，以protobuf或HSET作为value。使得单次读取就能获得当次推荐所需的全部数据。