腾讯内容千亿级实时计算和规则引擎实践优化之路( 七 ) 作者|王冬、杨浩、李文斌、王

预编译技术：进行规则匹配时，首先将规则编译成机器能理解的字节码，然后将上游信号作为数据输入进行匹配运算。该过程主要耗时在将规则编译成字节码阶段，我们将规则对应的字节码进行缓存，可以节省上千倍的算力开销。
3.3.4信号去重分发
信号去重
经过规则执行引擎后，仍然能召回大量信号，针对审核等场景，一个内容触发后，短时间内不需要再次输出，以免重复审核。为此，我们进行了个性化去重模块，支持灵活的去重周期，如永久去重、天级去重等，为不同的业务场景召回所需的信号。
信号分发
下游有多个业务系统，基于规则和业务场景的关系，将信号分发给对应的业务模块。分发方式支持消息队列投递以及接口回调，业务可以根据需要进行定制。
3.4服务质量
3.4.1端到端全链路服务可观测性
实时流服务对接的数据源多、加工链路长，会导致如下问题：问题发现慢：因为很难衡量端到端时效性，导致很难感知整体延迟，往往业务反馈后才知道。定位时间长：需一步一步联系上游环节，以确认数据延迟源头。
我们构建了全链路端到端端的可观测性系统，可以监控端到端延迟并快速定位问题环节，主要分位以下4个模块：数据染色：如图3-15所示，本模块集成到各个加工程序中，将本环节和上游各个环节的时效性信息染色到输出数据中，如事件时间、输出时间等。

文章图片
图3-15数据染色示意图时效性统计：因为每个环节的输出包含自身以及上游各个环节的时间信息，可基于某个环节的输出数据，统计从数据源到当前环节端到端分环节、分数据源的时效性信息。延迟监控：基于统计模块计算的数据，监控端到端的延迟。可观测分析工具：基于统计产生的数据，可以构建全链路实时拥堵分析工具，快速定位问题源头。

文章图片
图3-16全链路实时拥堵分析
3.4.2旁路系统保障状态高可用
内容生态中，计算内容的累计值、首次时间等场景，强依赖于Flink自身状态，但是因为依赖组件异常等原因，导致Flink有概率丢失状态，无法满足对数据一致性要求非常高的场景的需求。
我们构建了旁路系统，保障Flink状态异常丢失后，作业重启后核心状态的高可用。架构如图所示，主要由2个模块构成

文章图片
图3-17旁路系统保障状态高可用旁路系统：程序外起一个异步作业，将核心状态从输出中实时同步到Redis中。 Flink应用内状态恢复模块：为访问State的前置逻辑，如果Key在应用内状态中丢失，则从远程Redis中恢复。
4.信号应用
4.1内容质量智能审核
创作者文章发布后，需要进行相关必要审核，以保障线上内容的安全、优质、健康。因此，我们构建了智能审核机制，可以保障内容更高效的分发，更快地触达用户。

文章图片
图4-1内容质量智能审核流程
整体流程如上图所示，主要有2个模块：模型训练：每个个性化审核流程对应一个规则，需要为不同规则训练各自的模型。实时审核：接入内容的消费流水后，计算其1天、30天等滑动窗口指标，然后基于规则引擎进行匹配，将匹配的内容转换成信号输出，送入审核系统进行个性化审核。