优酷用户触达平台技术大揭秘( 二 )


通过分布式的能力 , 能非常高效的完群的调度 , 但也因此引入了其他的问题 , 内存与线程等问题 , 最终 , 我们在发送效率及服务稳定性之间找到了一个平衡点 。
人群规模不可控 , 经常会有上亿的人群场景 , 人群信息预加载内存后 , 短时间对内存产生了极大的开销 。 为了解决这个问题 , 我们引入了 nosql 进行了人群信息的暂存 , 在子任务执行时 , 再预加载人群数据 。
人群任务触发时 , 执行引擎线程都是满负载运行;最初我们考虑运行效率 , 在触达渠道节点又引入了一层异步线程 , 但事与愿违 , 异步线程池的等待任务队列在短时间打满 , 并又占用大量内存 , 最终取消了异步发送逻辑 。 另一方面 , 除了渠道服务 , 触达的物料素材可能会依赖于外部数据源 , 在高并发服务调用下 , 对下流业务服务产生了极大的压力 。 为此 , 我们引入匀速器模式 , 针对各个业务的预设 qps 执行调用 。
事件
事件的实时性、业务数据能力 , 正好是离线人群的补充 。 事件也是触达平台对外部业务的较为便捷的对接入口 。 同时 , 我们通过事件将会员触达、人群导入等内部的链路拉通 。 通过事件方式接入 , 的触达时机由业务侧控制 , 触达平台业务通过等待节点对发送时机做干预 。
为了能支持各类业务方 , 也为了减少业务方的对接成本 , 触达平台对接入不做任何协议约束;完全依赖触达平台的事件适配能力 。 业务方只需要topic及tag , 以及体样例 。 为了解决的适配 , 触达平台的事件主要了以下能力:
过滤器 , 通过 MVEL 表达式提取目标 。
目标字段映射 , 规范触达内部的格式 。
占位符及参数表达式 , 数据加工 。
通过以上3个能力 , 基本解决了统一适配的问题 。 通过 MVEL 表达式 , 可以灵活的支持各类业务需求的配置 。 总结下 , 事件的处理就是如下的流程:
上面提到 , 离线人群的缺点是无法携带业务内容 , 这对一些千人千面的触达需求不能很好的支持 。 而业务在一些营销场景下也不能很好的支持 , 基于此我们引入了 ODPS 数据导入的能力 。 它有离线人群的业务特性 , 又有事件的业务能力 , 而且技术实现上统一将导入成事件 , 使其与处理逻辑保持一致 。 目前导入是针对一些特有的业务场景 , 使用频次会较低 , 但其自由度较高 。 导入人群实现方案结合了离线人群以及事件人群的能力 , 能在满足业务诉求的同时能有较高的发送效率 。
二策略执行引擎
策略即触达业务逻辑 , 作为统一触达平台 , 我们希望通过编排来替代原先需要硬编码的业务逻辑 。 触达平台通过一种有向无环图的形式 , 来形象的表述这种策略 。 当然上面讲的人群及事件、以及后续会着重解析的物料模块都是策略的一部分 。 但这一部分 , 主要来分析下整体的图形策略编排、以及策略执行引擎 。
首先 , 需要明确节点、边的定义 , 通过对触达关键链路的拆解 , 明确了下如下节点和边的搭建规范 。
优酷用户触达平台技术大揭秘
文章图片
【优酷用户触达平台技术大揭秘】
优酷用户触达平台技术大揭秘
文章图片
按照规范 , 我们产出了如下触达策略 。 实现层面 , 我们用 node , edge 两个列表进行存储 , 通过首尾相连 , 组成一个 Graph 。 节点以及条件边都有对应类型的控制器实现 , 通过解析后的 Graph , 依次执行对应控制器 。
优酷用户触达平台技术大揭秘


推荐阅读