Maggie H说到返利优惠券机器人，很多人的第一反应是“不就是定时发券嘛”，但真正落地过的人都知道，难点从来不在“发券”这个动作上，而在于搞清楚“该给谁发、什么时间发、用哪种姿势发才能不让人反感”。我做过几个类似的项目，踩了不少坑，也沉淀了一套基于Java和Flink的实时计算方案，核心是动态规则引擎。这篇就把整个构建思路、关键设计和实战中的坑一次性讲清楚。
刚接手这个项目时，运营给的需求很简单粗暴：用户只要加购了商品但没下单，就要给用户发一张优惠券。等代码上线后问题马上来了——领取率倒是上去了，但核销率极低，ROI完全算不过账。后来仔细看数据才明白，不加区分地把所有“加购未购”的用户都当成同一种人，本身就是错的：有人是比价阶段，有人是等大促，有人就是手滑点了一下加购。不同动机的用户，需要的券种、面额、触达时机完全不一样。这就需要一个能基于实时行为动态判断用户意图的系统，而不是一套写死的if-else规则。
1. 为什么返利优惠券场景必须上实时计算
先说结论：不是所有优惠券场景都需要实时计算，但凡是涉及“行为触发”的精准触达，用离线批处理或者定时任务，体验上一定会有明显的断层。
拿我之前一个项目举例，业务方希望用户“连续三天浏览同一品类但未下单”时触发一张品类券。如果走离线数仓，T+1才能算出来，等用户看到这张券，可能已经去别的平台买了，券就白发了。而且离线任务算的是“昨天的状态”，跟用户当下的意图是脱节的。
但实时计算不是银弹，它解决的是“在正确的时间窗口内感知用户行为变化”的问题。Flink在这里承担的核心职责有两块：
- 在事件流上做滑动窗口聚合，识别用户短时间内的行为序列
- 将聚合结果与规则引擎中配置的动态阈值比对，命中后立即触发触达
为什么选Flink而不是Spark Streaming？对于这类场景，Flink的架构设计本质上更贴合需求：真正的流式处理（每条数据逐条处理，延迟更低）、原生的事件时间语义（处理乱序到达的埋点数据时不用自己写一堆补偿逻辑）、强大的状态管理机制（跨窗口保存用户行为状态，而不只是算完就丢）。Spark Streaming本质上是微批次，最短也要几百毫秒的攒批延迟，在需要“秒级感知用户行为变化”的返利场景下会显得迟钝。
还要回应一个常见的疑问：既然规则引擎可以把规则抽象成SQL，那能不能直接用Flink SQL做？如果业务规则只有两三条，可以，一旦规则数量超过几十条、且需要频繁调整阈值，纯SQL方案会变成一个噩梦。SQL的优势在于声明式表达，换来的是对引擎内部的控制力下降——类似“用户最近5分钟浏览超过10次且加购超过2次”这种规则，用SQL写没问题，但“IF用户触发A事件, THEN在90秒内观察是否出现B事件, 否则推送补偿券”这类有状态、有时序逻辑的规则，SQL就不太舒服了。所以我在项目中选用的是“Flink做实时计算底座 + 自研轻量规则引擎做决策”的混合架构。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体技术方案与架构拆解
整个系统的数据链路分为五层，每一层都有明确的职责边界。我把架构图画在脑子里是这样的：
2.1 数据接入层：从埋点到Kafka
用户行为数据从App、H5、小程序端采集后，统一上报到数据网关，经过格式校验和字段补全，写入Kafka。Topic按业务域拆分，核心的两个是：
user_action_topic：用户的浏览、点击、加购、下单、支付行为user_profile_topic：用户的基础属性变更、会员等级变化
Kafka的分区键按userId哈希，保证同一个用户的行为数据落到同一个分区，这是Flink端做状态操作的前提条件。如果不这样做，同一个用户的行为分布在多个分区，后续做会话窗口和状态更新时就要跨分区合并数据，延迟和复杂度都会上升。
注意：埋点的数据质量直接决定实时计算的下限。我在项目中专门加了一层数据校验算子，过滤掉缺失关键字段的脏数据，同时把过滤掉的记录输出到旁路日志，方便后续排查埋点问题。这一步看起来不起眼，少了它，后面所有规则的准确性都无从谈起。
2.2 计算引擎层：Flink集群的核心职责
Flink集群消费Kafka中的用户行为数据，主要做三类计算：
- 会话拆分：将用户的连续行为按时间间隔切分成一个个会话（比如30分钟内无新行为则切分新会话）
- 窗口聚合：对会话内的行为按滑动窗口做计数、金额求和、品类统计
- 特征拼接：将窗口聚合结果和用户基础画像拼接，形成一条完整的“用户当前状态向量”
这里有一个关键技术点：状态的生命周期管理。Flink的状态默认是永久保留的，但用户行为特征有很强的时效性，过期的状态不仅占用内存，还会导致规则误判。比如“最近15分钟加购了3件商品”这个规则，如果30分钟前的加购行为还残留在状态里，计算就会失真。我在状态上配置了TTL（Time To Live），按规则关注的最大时间窗口设置过期时间，既保证计算精确度，又控制状态大小。
2.3 规则决策层：动态规则引擎的定位
规则引擎不直接消费Kafka数据，而是挂在Flink计算链路之后，接收当前用户的行为特征向量，输出命中的规则列表和对应的优惠策略。这样做的好处是把“算状态”和“做决策”两个关注点拆开：Flink只负责实时维护“用户现在处于什么状态”，规则引擎只负责判断“当前状态下应该做什么动作”。
这样的解耦带来一个操作上的便利：修改规则不需要重启Flink任务。规则引擎是独立部署的服务，规则变更通过RPC接口或配置中心下发，实时生效。Flink任务本身不感知规则内容，它只负责提供特征——这正好呼应了标题里“动态规则引擎”的核心含义。
2.4 触达执行层：收到指令后的动作编排
规则引擎命中规则后，会生成一个触达指令，包含：用户ID、触达渠道（Push/短信/站内信）、优惠券模板ID、期望触达时间。执行层拿到指令后做三件事：
- 幂等去重：检查同一个用户、同一个规则、同一个券模板在最近N小时内是否已经触发过
- 频控校验：用户当天收到的推送次数是否超限，防止极端情况下变成打扰
- 发送：调用消息网关下发，同时回流触达结果（送达/点击/转化），形成数据闭环
起先觉得这层没什么技术含量，实际做下来发现，去重和频控的逻辑远比想象中复杂。由于Flink的At-Least-Once语义，同一个事件可能被重复处理，指令就会重复下发，如果没有幂等兜底，用户可能在几分钟内收到两条一模一样的优惠券Push。
2.5 监控与治理层：实时任务的血常规
Flink任务的监控不能只看CPU和内存，更要关注：
- Checkpoint失败率：连续失败说明状态后端或数据源有问题
- 端到端延迟：从埋点上报到触达指令生成，正常应该在秒级
- 规则命中分布：哪个规则命中量远超预期，可能规则本身有逻辑漏洞
- 状态大小变化：状态异常增长往往是数据倾斜的前兆
这一层经常被忽视，但上线后运营的第一个问题就是“为什么你们规则没生效”。如果没有监控面板，排查这类问题只能靠猜。我在项目中用Grafana搭了一套实时看板，把核心指标全部可视化，定位问题的时间从小时级缩短到分钟级。
3. 动态规则引擎的建模与执行设计
规则引擎是这个项目里最核心也最需要沉淀的部分。我把它拆成“规则模型”和“执行机制”两个子问题来设计。
3.1 规则模型的抽象：从JSON到可执行的决策树
先看一条业务规则的原始描述：
用户在过去10分钟内，加购了至少2件品类为“数码”的商品，且用户等级为VIP，则推送一张8折数码品类券，但同一用户当天最多触发一次。
这条规则看起来简单，换成可被引擎理解的结构化描述，分为四部分：
| 组成部分 | 本规则中的内容 | 抽象字段 |
|---|---|---|
| 触发条件 | 10分钟内加购数码商品≥2件 | conditions |
| 用户属性约束 | 用户等级=VIP | profileFilters |
| 动作 | 推送8折数码品类券 | action |
| 频控约束 | 同一用户当天最多1次 | rateLimit |
整体规则模型定义为一个JSON结构，包含了条件组、过滤器、动作、限流策略、优先级、有效期这些字段。条件之间支持AND和OR嵌套，满足复杂业务表达。
一个关键的经验：规则条件不要写死在代码里，但也不要设计成完全通用的DSL，否则写规则的人会疯掉。折中方案是把常用的原子条件固化成算子，比如addToCartCount、categoryBrowseCount、orderAmountSum、activeDuration等，这些原子条件对应Flink侧已经算好的特征字段，规则配置里直接引用特征名+比较符+阈值即可。新业务来了以后，先看能不能用已有原子条件组合出来，组合不了再新增原子条件，这样既保证灵活性，又控制理解成本。
3.2 规则评估的执行机制：顺序匹配的问题
规则多了以后，一个用户的特征向量进来，引擎需要判断命中哪些规则。最简单的方式是遍历所有规则逐一评估。规则量少时确实够用，规则涨到几百条后，每次都全量遍历，单条触达指令的决策耗时就会显著增加。
后来按照“RETE算法”的核心思想对匹配过程做了优化：把用户特征按类型分组，每个分组只触发相关规则的评估。例如用户产生的特征向量中包含“加购数码品类商品数=3”这个字段，引擎先去查哪些规则的触发条件里包含对这个字段的约束，只评估这些规则，跟数码品类无关的规则直接跳过。这样规则再多，单次决策实际评估的规则数量也会被约束在一个很小的范围内。
去重逻辑放在规则引擎的输出端做了第一道拦截，规则A和规则B都命中了同一张券模板时，系统按“优先级高者胜出、同优先级的只保留一条”的方式收敛，避免同一个用户在一次刷新中被同样的券轰炸。
3.3 规则版本管理：为了动态上线的妥协
规则引擎上线后必然会遇到一个问题：线上规则有问题，需要立即下线或调整。如果规则是代码写死的，只能改代码、走发布流程、重启服务，整个过程至少需要分钟级，碰到大促前的紧急调整，根本来不及。
我的方案是引入规则版本的概念。规则有draft、active、disabled三种状态，改动规则时先起草新版本，评估无误后发布，新版本生效时旧版本自动失效。规则和版本的多对一关系解决了两个问题：
- 规则先只改一处，对某个优先级数值做微调，不会影响其他规则
- 发布后如果指标变差，可以一键回滚到上一个版本
这里要特别提醒一个坑：规则引擎的灰度验证不能只看领取率，必须拆到细分人群看。有一次我把某个高门槛规则的阈值调低了5%，整体领取率上升了10%，看起来效果不错。结果拆到用户分层看，发现提升主要来自本来就容易转化的高活跃用户，低活跃用户几乎没变化。也就是说，这次调整根本没有起到应有的刺激作用，只是给本来就会买的用户送了一波福利。后来我在规则发布流程里固定加了一道人肉检查清单：调整这条规则想影响的人群是谁，他们在这个指标上的前后变化是多少。
4. Flink端用户行为特征计算的实操细节
规则引擎做得再好，如果Flink侧的特征算得不准，一切都是空转。这一部分直接决定规则引擎能不能做出正确判断。
4.1 事件时间、水印与乱序处理
用户行为数据从客户端上报到服务端，再到Kafka，存在不可控的网络延迟，所以Flink任务里处理事件时间必须基于事件自带的时间戳，用Watermark来处理乱序数据。
以下是实际配置的关键参数，可以直接参考：
java复制// 使用事件时间语义
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);
// 从事件中提取业务时间戳，并允许5秒的乱序延迟
DataStream<UserAction> streamWithTimestamps = actions
.assignTimestampsAndWatermarks(
WatermarkStrategy
.<UserAction>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((action, timestamp) -> action.getActionTime())
);
乱序延迟设置的选择是个权衡：延迟设得太大，窗口计算要等更长时间才能触发，实时性受损；设得太小，大量的迟到事件会被丢弃，特征计算会丢失一部分数据。5秒是我在线上环境验证过比较中庸的值，如果你的埋点链路中有某个环节会引入长尾延迟（比如App端使用了批量上报），可能需要适当调大。
4.2 滑动窗口聚合的流量控制
规则里最常见的条件是“过去N分钟内发生了X次某行为”，对应到Flink就是滑动窗口聚合。滑动窗口有一个经典的性能问题：窗口滑动步长小、窗口长度大时，同一个事件会被重复计算多次。比如“10分钟窗口、30秒滑动一次”，一条事件会被计算20次。
场景里用户量级上来后，这个重复计算的影响会被放大。为了解决这个问题，我用增量聚合函数AggregateFunction替代全量聚合，每条事件进入窗口时立即更新中间结果，窗口触发时直接输出累计值，窗口内的历史数据不需要重新遍历。这个优化把单窗口的CPU消耗降了一个量级。
java复制DataStream<UserActionCount> aggregated = streamWithTimestamps
.keyBy(action -> action.getUserId())
.window(SlidingEventTimeWindows.of(Time.minutes(10), Time.seconds(30)))
.aggregate(new ActionCountAggregate());
还有一种更灵活的做法：直接用Flink的ProcessFunction加定时器自己管理窗口，优势是可以对每个用户维护一个独立的“事件计数Map”，窗口滑动时只是简单调整计数，不用反复注册窗口。缺点是代码复杂度更高，需要对状态清理和定时器管理有足够的掌控力。对于规则条件经常变化的场景，这种自管理窗口的方式更灵活——调整时间窗口只需要改配置，不用改窗口算子的参数。
4.3 关键状态的设计与清理策略
Flink的KeyedState是承载用户行为特征的核心。我在代码中维护了两个状态变量：
java复制// 用户最近的行为列表，用于生成特征向量
ValueState<RecentActions> recentActionsState;
// 用户当天已触发的规则与券模板，用于频控
MapState<String, Long> triggeredRulesState;
第二个状态极其重要，它解决了“规则引擎做了频控，但频控状态是分散在触达执行层的，跨规则查重麻烦”的问题。把“这个用户今天收到过哪些优惠券”作为状态放在Flink侧，规则引擎在判断是否命中某些“新人专享”“首单券”这类全局限制规则时，Flink侧直接给出答案，不需要再去远程查表，省了一次RPC调用，也避免了一次分布式事务的一致性难题。
状态TTL的设置也有讲究。行为列表类状态TTL设置为最大关注窗口的1.5倍，比如核心规则关注的是10分钟滑动窗口，状态TTL就设15分钟，给窗口边界留出余量。频控状态TTL设置为24小时，在每天零点前自然过期，避免跨天的频控误伤。这两处的配置参数我写在这里（Flink 1.14+版本写法），在1.13及之前版本中需要采用StateTtlConfig.newBuilder的传统构造方式：
java复制StateTtlConfig behaviorTtl = StateTtlConfig
.newBuilder(org.apache.flink.api.common.time.Time.minutes(15))
.setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
.setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
.build();
配置TTL时最容易踩的一个坑是：默认的OnReadAndWrite更新策略会在每次读取状态时都刷新过期时间，导致“一直读就一直不过期”，状态变成永不清理的“僵尸数据”。你需要根据业务对“过期”的定义来决定用哪种策略。行为特征选OnCreateAndWrite，只在写入时刷新过期时间，到了时间就坚决清理。
4.4 动态规则的广播流实现
这个模块是动态规则引擎和Flink结合的桥梁。规则引擎维护的规则集合变化后，需要通知Flink任务调整计算行为。用Flink的BroadcastStream机制可以优雅地解决这个通知问题：
java复制// 规则变更流，来自配置中心或规则引擎服务
DataStream<Rule> ruleUpdateStream = ...;
// 将规则变更流广播给下游所有算子实例
BroadcastStream<Rule> broadcastRules = ruleUpdateStream
.broadcast(ruleStateDescriptor);
// 行为流连接广播流，在ProcessFunction中动态判断当前规则集合
DataStream<TriggerResult> result = behaviorStream
.connect(broadcastRules)
.process(new DynamicRuleEvaluator());
这套机制运转起来后，运营调整规则的操作路径就变成：在配置平台改规则参数 → 发布新版本 → 规则引擎推送变更到Flink集群 → 下一个行为事件进来时立即用新规则评估。整个过程秒级生效，不需要重启任务，也不需要等状态重新加载。
5. 精准触达策略：Flink算出来之后怎么办
规则引擎输出了命中结果，但“给用户推什么券、什么时候推”这两个问题，直接左右最终的转化效果。这是很多技术方案里最容易一带而过、却真正决定业务价值的部分。
5.1 触达时机的选择逻辑
实时计算的一个隐含假设是“越及时越好”，但对于优惠券触达，这个假设并不总是成立。
一个用户的加购行为，背后的意图分好几种：可能是明确想买，正在等合适的价格；可能是随便逛逛，被商品详情页吸引点了一下加购；也可能是帮别人看的。对于“明确想买”的用户，越早推券越容易转化；对于“随便逛逛”的用户，立刻推券反而会显得急功近利，关掉推送的概率大幅上升。
所以触达时机的判断不能只看“是否命中规则”，还要结合用户的历史购物习惯。我在触达层加了一个“延迟触达”机制：规则引擎命中后，指令先进入一个延时队列，如果用户在过去30天内有“加购后2小时内下单”的行为习惯，则立即触达；否则延迟15分钟再触达，给用户一段自己思考和比价的时间。实测下来，后者的推送关闭率比立即触达低了约四分之一，而延迟后的券核销率没有明显下降。
5.2 券模板与用户偏好的匹配优先级
优惠券库存是有限的（尤其是大额券），把券发给最可能用的人而不是最可能需要的人，是运营ROI的关键。我在这里借鉴了推荐系统的思路：给每个用户维护一个“券偏好权重”，权重由三个维度加权计算：
| 维度 | 权重 | 说明 |
|---|---|---|
| 历史核销率 | 0.5 | 用户过去30天对同类券的核销比例 |
| 品类偏好 | 0.3 | 用户近7天浏览和加购最多的品类 |
| 折扣敏感度 | 0.2 | 用户对折扣力度的敏感程度，从历史订单中提取 |
规则引擎输出“命中某条规则”后，触达执行层并不会直接下发，而是从该规则关联的多个券模板中，选择用户偏好权重最高的那一张下发。比如A用户历史上下单最多的品类是图书，B用户是数码，同一个“加购未购”规则命中两个人，系统下发的是不同品类的券。这看起来像一个很小的调整，但上线后整体核销率提升了近10个百分点。
5.3 触达频控的完整方案
频控是返利机器人最容易翻车的地方。一个用户如果短时间内收到太多次优惠券推送，不仅不会促进转化，反而会直接卸载App或屏蔽通知。我踩过一次很惨的教训：某次大促前上线了一批新规则，没有做好跨规则的统一频控，结果一个高活跃用户在半天内收到了9条不同品类的优惠券Push，当天就流失了。
后来把频控做成了三层：
- 用户级频控：当天最多收到N条优惠券触达（N按用户历史互动频率分档，活跃用户上限可以放宽）
- 规则级频控：同一规则对同一用户每天最多触发一次
- 渠道级频控：Push、短信、站内信分开计数，避免多通道叠加骚扰
这三层频控的数据都落在Flink的状态中，规则引擎评估时会传入当前频控计数的上下文，命中规则后先过频控检查，再进入触达队列。
6. 实时计算链路的性能调优与常见问题排查
这一部分是我最想分享的，因为方案设计的坑大多数可以在代码审查阶段发现，而性能问题和数据正确性问题，往往要等到线上出故障才能暴露出来。这里把我在实战中遇到的三个典型问题和排查思路记录下来。
6.1 状态后端选型：大状态场景下的性能瓶颈
项目初期使用的状态后端是RocksDB，因为用户量预计会很大，状态不可能全部塞进内存。但上线后发现一个诡异的现象：规则命中率在白天正常，晚上高峰时段却明显下降，同时Flink任务的CPU居高不下。
排查过程花了大半天。先看Checkpoint监控，发现每次Checkpoint耗时从正常的秒级飙到了分钟级。再查算子级别的指标，发现瓶颈在有大量KeyedState访问的KeyedProcessFunction上。RocksDB的读写是磁盘IO操作，虽然RocksDB有内存缓存，但高频的随机读写仍然会导致严重的性能问题。
最终优化措施拆成三步：
- 加大RocksDB的
block cache和write buffer配置，让热点数据尽量驻留内存 - 将高频访问的频控状态从RocksDB迁移到Heap状态后端，减少磁盘IO
- 优化状态访问模式，把同一用户多次状态读写合并成一次“读-改-写”
其实还有一个更本质的方案：把“跨规则频控”从Flink状态中抽出来，放到Redis中。用Redis的INCRBY和EXPIRE实现计数，天然支持分布式访问，而且访问延迟比RocksDB低一个数量级。但这是一个牺牲一致性换性能的取舍——用Redis做频控后，Flink的状态里就不再有频控计数，如果规则引擎需要基于频控状态做“当日已发券数量>3则不参与高门槛规则判断”这种复合条件，就必须依赖Redis的实时查询。Redis挂了会影响触达的实时性，但没有Redis的兜底方案在性能和准确性之间很难三全其美。我的选择是线上用Redis，同时保留Flink状态作为降级方案，Redis不可用时自动切回Flink侧频控。
6.2 数据倾斜：热门用户拖垮整个窗口计算
还有一次线上故障，深夜时某个头部主播带货，一个突发流量引入了几十万用户的集中行为。问题爆发时表现是：Kafka消费延迟从几百毫秒涨到了十几分钟，部分规则完全不触发了。
根因定位到数据倾斜。按照userId做KeyBy后，个别超级活跃用户（比如在那场直播里频繁点击、加购、分享的用户）每分钟产生上千条行为事件，它们全部落在同一个子任务上，导致该子任务的处理能力被击穿，这个用户对应的所有状态更新和窗口计算都被阻塞，后继的规则评估全部延迟。
排查方法是通过Flink Web UI观察各个子任务的recordsIn和busyTime指标，发现某个子任务的busyTime接近100%，而其他子任务都在20%以下，倾斜非常明显。
针对倾斜的优化方案有两个思路：
- 加盐拆分：对于热点用户，将行为事件按事件类型进一步拆分到多个子任务并行处理，处理完后再合并结果
- 窗口预聚合：在KeyBy之前先做一次按事件类型的预聚合，减少下游处理的数据量
思路一效果显著，但工程复杂度较高——拆分、合并、乱序处理都要额外处理。我当时的落地选择是先做方案二（预聚合），把加购、浏览、点击分别聚合成分钟级汇总，再交给下游状态算子，热线用户的单条事件量下降了一个量级，倾斜问题基本缓解。
注意：热点用户的识别是动态的，不能写死。我在代码里实现了一个“热点探测”算子：统计每个用户每分钟的事件量，超过阈值就动态标记为热点，后续的事件走预聚合分支，其他用户走常规分支。这样既不增加常规用户路径的延迟，又能兜住突发热点。
6.3 实时与离线数据对不上：不可忽视的对账机制
实时计算上线后，运营迟早会问一个问题：“为什么实时看板显示这个用户7天前领过券，离线数仓显示他今天还能领？”这类实时和离线口径不一致的问题，几乎每个实时项目都会遇到。
根本原因是两条链路采用了不同的计算口径：实时侧基于事件流做无界窗口，可能因为乱序丢弃了部分迟到事件；离线侧基于有界批次做全量重算，数据是完的。两边算出来的结果自然可能不一致。
我的做法是建立“实时-离线对账任务”：每天凌晨离线任务跑完后，将当天的实时指标和离线指标做对比，差异超过阈值产生告警。这个对账不需要逐用户级精确匹配，按业务域和日期聚合后对比命中量、触达量、核销率几个核心指标即可，超过5%的差异就说明实时链路大概率丢了数据或者算错了逻辑，需要人工介入。
这类对账不是实时计算的核心功能，但如果没有它，会在后续的数据质量争议中耗费大量不必要的沟通成本。早点把对账基建搭好，后面做任何规则变更都有据可依。
6.4 Flink SQL与DataStream API的边界取舍
刚才提到，不要用纯Flink SQL实现复杂规则引擎。在实际项目中，我通常的做法是：能简单的用SQL，复杂决策逻辑用DataStream API。
比如“用户最近10分钟加购次数”这类纯粹的窗口聚合，用Flink SQL写就是几行：
sql复制SELECT userId,
COUNT(*) AS addToCartCnt
FROM user_action_topic
WHERE actionType = 'ADD_TO_CART'
GROUP BY TUMBLE(ts, INTERVAL '10' MINUTE), userId
如果整条链路的规则都是这种“纯计数型”的，用SQL就够了。但一旦出现“用户触发了A事件后90秒内是否观察到了B事件”这种有状态、有前后时序逻辑的规则，SQL写起来就别扭了，甚至不可能用SQL表达。此时必须用ProcessFunction自己管理定时器和状态。
我建议的参数化选型标准是：
- 规则只依赖简单的聚合计数、阈值比较：优先用Flink SQL，省代码、好维护
- 规则依赖用户行为序列、事件间隔、复合条件嵌套：用DataStream API + 自研规则引擎
- 混合场景（大多数项目是这样）：外层用SQL做粗粒度过滤，内层交给DataStream API做细粒度判断，减少引擎需要评估的规则数量
7. 项目验收与上线后的经验沉淀
系统上线后，我整理了一份检查清单，供后来者对照：
功能和稳定性验证清单：
- [ ] 规则变更能否在1分钟内生效，且不重启Flink任务
- [ ] 同一用户被同一规则重复命中的次数是否为0
- [ ] Checkpoint连续运行24小时无失败，RocksDB状态增长在预期范围内
- [ ] 端到端延迟P95在5秒以内（埋点上报到触达指令生成）
- [ ] 压测时用2倍预期流量灌入，观察Flink背压和Kafka堆积情况
- [ ] 模拟乱序事件，确认水印和迟到数据处理符合预期
- [ ] 任意一个下游组件（Redis、消息网关）挂掉后，系统能自动降级且不丢核心数据
我个人的体会是，这套架构里“动态规则引擎”和“Flink实时计算”其实是互相成就的：没有Flink的实时状态管理，规则引擎的动态化就没有数据支撑；没有规则引擎的抽象封装，Flink的计算能力就很难被运营人员直接使用。两者的结合点，就是标题里反复强调的“精准触达”——技术不是为了炫技，而是让每一张优惠券都能在对的时间、以对的方式、出现在对的人面前。
最后再分享一个小技巧：上线初期不要一次接入全部规则，先挑两条覆盖人群最广、逻辑最简单的规则跑通全链路，验证数据准确性、延迟、频控都符合预期后，再逐步增加复杂规则。这个节奏可以帮你在问题还小的时候就暴露出来，而不是等规则全部上线后，各种问题交织在一起，排查时脑袋都要炸了。