5.3 复杂事件处理CEP：模式识别武器库

5.3 复杂事件处理CEP：模式识别武器库

本节摘要：当需求从"统计聚合"升级为"识别事件序列"——十分钟内连续三次失败支付、先领券后下单再退款、一小时内异地登录——聚合算子立刻失灵。CEP 用模式语言把这类需求写成声明式的状态机。本节拆解它的模式表达、底层的自动机原理与状态代价，并用一个风控规则跑通全流程。

聚合写不出来的那类需求

风控同学提了个新规则："同一张卡在十分钟内连续三次支付失败，第四笔直接拦截。"你试图用上一节的 SQL 聚合表达"连续"——发现根本无从下手：聚合能数出"十分钟内失败了三次"，但数不出"连续且未成功穿插"。这类需求的关键不在数值累计，而在事件的顺序、间隔与组合，它们是另一门手艺：复杂事件处理（CEP）。

CEP 的核心心智是：把一段模式声明交给引擎，引擎为每个键维护一台小型状态机，事件到来时驱动状态机转移，一旦走出完整匹配就输出。你写的是"什么算匹配"，引擎管的是"怎么记住中间状态"。

模式语言速成

用风控规则翻译一遍 CEP 的表达要素：

Pattern<PayEvent, ?> failThree = Pattern.<PayEvent>begin("f1")
    .where(new SimpleCondition<PayEvent>() {
        @Override
        public boolean filter(PayEvent e) { return "fail".equals(e.getStatus()); }
    })
    .next("f2").where(new SimpleCondition<PayEvent>() {       // next: 严格紧跟
        @Override
        public boolean filter(PayEvent e) { return "fail".equals(e.getStatus()); }
    })
    .next("f3").where(new SimpleCondition<PayEvent>() {
        @Override
        public boolean filter(PayEvent e) { return "fail".equals(e.getStatus()); }
    })
    .within(Time.minutes(10));                                 // 时间约束：整套匹配限时

CEP.pattern(payStream.keyBy(PayEvent::getCardNo), failThree);
​

表达要素就五件：命名阶段（begin 与 next 的阶段名）、阶段条件（where 的谓词）、阶段间关系（next 严格紧跟；followedBy 允许中间夹无关事件；notNext 不得出现某事件）、循环量词（times 恰好几次、oneOrMore 一次以上、greedy 贪婪到不能再匹配）、时间约束（within 限定整套匹配的时长，与事件时间水位线联动）。风控里最常见的误报来源是"next 与 followedBy 选错"：前者要求事件严格相接，后者容忍穿插——选哪个，取决于业务对"连续"的定义，写之前跟风控同学逐字确认。

底下的状态机：为什么它贵

CEP 的执行核心是非确定性有限自动机。每个键一台自动机，事件到来时按当前状态与条件转移；复杂之处在"分支"——当 followedBy 允许穿插、或循环量词允许不同切分时，同一事件可能让自动机同时处于多个候选状态，每个候选都是一份要保存的中间序列。于是 CEP 的状态成本公式浮出水面：状态 = 活跃键数 × 每键的候选匹配数 × 匹配序列长度。风控流量高峰、模式带宽松量词、within 设得长，三件事叠一起，状态轻松爆表。

控制成本的三板斧：第一，时间约束收紧，within 从小时压到分钟，候选序列的存活期直接缩短；第二，条件前置，让每个阶段尽可能挑剔（加上金额、渠道等过滤条件），尽早淘汰不可能是匹配的事件；第三，键的粒度选对，按卡号比按用户粒度细，单键的候选数天然更少。三板斧的原理统一：让自动机尽早死掉不可能的分支。

图 5-3 一次匹配的自动机旅程：三次失败支付

超时匹配与告警落地

withIn 除了限制匹配，还带来一个实用产物：超时侧输出。到时限仍未走完的候选匹配（比如两次失败后没等来第三次）会进超时通道。别小看它——风控策略迭代时，"差一次就命中"的近失样本是最有价值的分析素材，超时通道天然帮你收集好了。命中输出与超时输出各自接下游：命中进拦截决策或告警，超时进分析归档。

⚠️ 常见坑：把 CEP 当聚合用。需求只是"数次数"时，窗口聚合的状态成本远低于一台台挂着候选序列的自动机；CEP 只在"顺序与间隔本身是业务语义"时才值得上场。

一次误报风暴的治理实录

CEP 上线后的头号敌人往往不是性能而是误报。拿一起真实误报风暴做教学案例。规则背景：银行卡"十分钟内连续三次失败加一次成功"触发风控。上线后误报量远超预期，排查发现三个叠加成因。成因一：量词宽松。模式里失败次数写的是"一次以上"，两次失败加一次成功的老用户也被匹配——语义与风控的本意（恰好三次）不符，量词从 oneOrMore 收紧为 times(3)。成因二：阶段关系选错。next 要求三次失败严格相邻，风控的本意是"失败序列中间可以夹查询行为"，改用 followedBy 加负条件（中间不得出现成功支付）。成因三：键粒度太粗。按用户聚合把多张卡的行为混在一起，改成按卡号后候选数骤降、误报同步下降。三处改完，误报率掉到千分之一以下。

复盘这个案例，CEP 的工程纪律浮出水面：模式语言的每个字都要与业务方逐词对齐——"连续"是 next 还是 followedBy、"多次"是 times 还是 oneOrMore、"同一用户"按什么粒度。模糊词进代码，误报与漏报就在字缝里滋生。CEP 规则的评审比代码评审更像法条审校，这是它与其他表达层最大的不同。

本节要点

• CEP 治理"顺序型需求"：阶段命名、阶段条件、阶段关系（next 严格、followedBy 容穿插）、循环量词、within 时间约束五件套。
• 底层是按键维护的非确定性自动机，分支产生候选状态，状态成本 = 键数 × 候选数 × 序列长。
• 省钱三板斧：收紧 within、条件前置、细化键粒度，本质是尽早淘汰不可能的分支。
• 超时侧输出收集"近失匹配"，是策略迭代的高价值素材；数次数的活别交给状态机。

三种表达层走完，写代码的功课齐了。下一章换帽子：作业上生产之后，部署、高可用与监控如何让工程师睡个整觉。