实时营销引擎在vivo营销自动化中的实践 | 引擎篇04( 三 ) _生活百科

各方案对比如下：

文章插图
结论：按照当前项目优先级综合评估来看，业务隔离性>可伸缩性>可维护性>接入方友好性。
方案二比较适合。（不同的项目可以根据自己的实际情况按优先级进行合适的选型）
3.1.2 动态消息监听背景：当需要做好业务间风险隔离时，就必须按业务或者事件的维度进行队列拆分。此时若进行新接入事件就可能需要重新创建新的队列。
初期方案：采用公司中间件vivo-rmq, 当接入方需要新增队列时，需要修改代码新增队列监听，重新发版，这样做的问题是重新发版成本较高，按照项目流程管理进行效率低。
优化方案一：修改启动加载类加载指定目录下的配置文件，新增队列时修改配置文件上传。

优点：无需发版。
缺点：仍需要重启服务器，同时需要维护配置文件目录等信息。

优化方案二：保存队列配置信息到数据表中，启用定时任务在服务器运行时动态监听数据库配置，新增或者下线队列配置记录后，自动进行队列变更。

优点：无需发版和重启。
缺点：定时任务实时性稍差，必须确保队列监听成功后在通知业务方接入。

结论：采用方案二，新增事件无需对系统进行重新部署，使用运行时动态方式进行消息队列接入。
3.2 统一分发处理抽象公共分发模板：事件参数和有效性检测 → 分发到事件规则匹配器 EventMatcher → 输出到渠道发送流程

文章插图
可靠平滑启停
1. MQ消费端分发主流程未处理完成，系统重启可能会造成事件消息丢失。
解决方案：配置MQ消费端没有返回ack时，MQ服务端重新发送消息，此时业务消费必须保证幂等性。
2. MQ分发主流程处理完成已返回ack，但是在分发到业务线程池过程中，由于JVM重启而丢失。
解决方案：这种场景时间极短，可以等待分发完成再进行ack 。
3. MQ分发主流程分发到业务线程池处理过后，但是线程池处理渠道发送过程仍可能因为JVM重启而丢失。
【实时营销引擎在vivo营销自动化中的实践 | 引擎篇04】解决方案：

利用JVM ShutdownHook钩子函数设置重启标记flag，MQ取数据时可以根据flag不再取出数据；
业务线程池不再接受新的任务, 同时利用线程池自身的Hook，等待处理线程池完成已有的任务。

3.3 复杂多源数据的处理指标补全
业务接入方可以提前将业务数据加载到统一大数据平台，并补充元数据配置，支持实时事件数据之外的数据补全。
指标统计
对规则配置数据进行，使用Flink CEP负责事件处理，支持时间窗口计算。
交并差运算
基于Presto计算查询引擎，对不同目标用户群进行交并差负责运算，得到处理后的结果数据。
3.4 规则匹配器义传统方案
使用简单直接的硬编码的方式，根据不同的事件条件进行编码处理，适合迭代更新要求低的小型系统。