Flink CEP 怎么做复杂事件检测？
面试怎么回答
我会先按用户或设备 KeyBy，再用 Pattern 定义事件条件、次数和顺序。next、followedBy、followedByAny 分别代表严格、宽松和非确定宽松连续；用 within 限制匹配时间，用 skip strategy 控制重叠结果。在 Event Time 下还要设计 Watermark 和迟到事件 Side Output，并监控模式状态和共享缓冲区，避免候选组合膨胀。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
单条登录失败并不可疑。
但“连续失败、异地登录、短时间转账”组成序列后，风险等级完全不同。
Flink CEP 的价值，是从无界事件流中匹配有顺序、有条件、有时间范围的复杂事件序列。
先按业务实体 KeyBy
复杂事件通常属于同一个用户、设备、订单或账户。进入 CEP 前先按业务主键 KeyBy，才能让同一实体的事件进入同一份模式状态。
如果对非 Keyed 流直接应用 CEP，官方文档明确提示任务会以并行度 1 运行，吞吐和状态都会集中。
Pattern 不只是多个过滤条件
一个模式由多个具名状态组成，每个状态定义事件条件、出现次数以及与前后状态的关系。
next 表示严格连续；followedBy 允许忽略中间不匹配事件；followedByAny 会产生更多可能组合。三者看起来只差一个 API，实际匹配数量和状态规模可能差很多。
必须限制时间范围
生产模式通常要用 within 限制整个事件序列必须在多长时间内完成。
没有时间范围，部分匹配可能长期留在状态中；如果再叠加 oneOrMore、followedByAny 等宽松规则，候选组合会快速膨胀。
还要选择 After Match Skip Strategy，决定匹配成功后从哪里继续，避免同一批事件生成大量重叠告警。
事件时间依赖 Watermark
在 Event Time 下，CEP 会根据时间戳排序水位线之前的事件，并假设 Watermark 是可信的。
时间戳小于最近 Watermark 的事件会被视为迟到事件，不再参与正常模式匹配，可以通过 Side Output 单独处理。因此 Watermark 太激进会漏匹配，太保守又会增加等待和状态。
一个典型场景
风控规则要识别十分钟内三次失败登录后的一次成功登录。最初使用 followedByAny 且没有跳过策略，同一组失败事件组合出多条重复告警。
调整为符合业务语义的连续方式，增加 within，并在匹配后跳过已使用事件，告警数量才与业务预期一致。
CEP 设计的重点，是把业务语言里的“连续、任意、重复、超时”翻译成准确的模式边界。