4. 规则执行流程：匹配-解决-执行，Rete算法与议程管理
规则引擎到底是怎么跑起来的？很多初学者以为就是「条件满足就触发」，其实没那么简单。我做了这么多年性能调优，见过太多因为不理解执行流程而写出低效规则集的案例。今天咱们就把这个流程彻底拆开看看。
规则引擎的核心执行流程，说白了就三个阶段：匹配（Match）→ 解决（Resolve）→ 执行（Execute）。这三个阶段循环往复，直到没有规则可触发为止。嗯，咱们一个一个来看。
4.1 Rete算法：匹配阶段的加速引擎
匹配阶段要解决的核心问题是：当事实（Fact）发生变化时，哪些规则的条件被满足了？ 最朴素的方案是遍历所有规则，逐条检查条件——但规则数量一多，性能就崩了。
Rete算法的思路很巧妙：把规则条件编译成一个有向无环图（DAG），节点之间共享公共子条件。这样当事实变化时，只需要沿着图传播变化，而不是全量重新匹配。
Rete的核心优势：
- 状态保存：每个节点缓存了当前匹配的中间结果，事实变化时只做增量更新
- 条件共享：多条规则如果有相同的条件子句，共享同一个节点，避免重复计算
- 时间冗余消除：事实变化只影响相关路径，不触发全量重算
我在项目中遇到过这样一个场景：一个金融风控系统有 2000+ 条规则，用朴素匹配时单次触发耗时 800ms 以上。换成 Rete 算法后，同样的规则集降到 30ms 以内。差距就是这么明显。
下面这张图展示了 Rete 网络的核心结构：
性能调优小技巧：Rete 网络中的 AlphaNode 是性能瓶颈的高发区。我建议你把高频过滤条件（比如「状态=已支付」这种）放在 Alpha 网络的浅层，让不满足条件的事实尽早被剪枝掉，减少后续节点的计算压力。
4.2 议程（Agenda）管理：谁先执行？
匹配阶段结束后，所有满足条件的规则会被放入一个叫「议程」的地方。议程本质上是一个优先级队列，里面装着待触发的规则实例（Activation）。
你想想看，如果同时有 10 条规则都满足了条件，先执行谁？后执行谁？这就是议程管理要解决的问题。
| 议程概念 | 说明 | 我的经验 |
|---|---|---|
| Activation（激活） | 一条规则 + 一组匹配的事实，打包成一个待执行单元 | 同一个规则可能因为不同事实组合产生多个 Activation |
| Agenda Group（议程组） | 将规则分组，同一组内的规则按优先级排序 | 我习惯把「前置校验」和「后置处理」分到不同组 |
| Focus（焦点） | 当前正在执行的议程组，引擎只执行焦点组内的规则 | 用 focus 切换可以实现规则执行的阶段化控制 |
| Rule Priority（规则优先级） | 数值越大优先级越高，默认值为 0 | 建议优先级跨度大一些（如 10、20、30），方便后续插入新规则 |
4.3 规则冲突解决策略
当多条规则同时满足条件，而且它们之间可能存在互斥或覆盖关系时，就产生了冲突。冲突解决策略决定了引擎如何从议程中挑选下一条要执行的规则。
常见的冲突解决策略有这几种：
- 优先级优先（Salience）：数值高的先执行。最直观，也是我推荐的首选策略。
- 最近更新优先（Recency）：最近被修改的事实所触发的规则优先执行。适合需要「最新状态」的场景。
- 复杂度优先（Complexity）：条件更复杂的规则优先执行。嗯，这个策略用得少，因为复杂度评估本身就有开销。
- 加载顺序优先（LIFO/FIFO）：按规则定义的先后顺序。不推荐，因为规则顺序一变，行为就变了。
我曾经踩过的坑：在一个交易系统中，我同时用了「优先级优先」和「最近更新优先」两种策略混合排序。结果规则执行顺序完全不可控，同一个测试用例每次跑出来的结果都不一样。后来我统一只用优先级策略，把排序逻辑完全显式化，问题才解决。
建议：除非你有非常明确的理由，否则只用一种冲突解决策略。混合策略的调试成本远高于它带来的收益。
4.4 规则执行的生命周期
一条规则从「被匹配」到「执行完毕」，经历了完整的生命周期。理解这个周期，对排查「规则为什么不触发」或者「规则为什么重复触发」这类问题特别有帮助。
这里有个容易忽略的点：副作用传播。规则执行时如果修改了事实，会触发 Rete 网络的重新匹配，可能产生新的 Activation。这些新 Activation 会被加入议程，继续参与后续的冲突解决和执行。这个过程会一直持续，直到议程为空——也就是所谓的「不动点（Fixed Point）」。
无限循环的陷阱：如果规则 A 修改了事实 X，而规则 B 又因为 X 的变化被触发，接着规则 B 又把 X 改回去……这就形成了死循环。我建议你在规则设计阶段就做好「修改事实」的审计，或者在引擎层面设置最大执行轮次（如 Drools 的 fireUntilHalt() 配合 halt() 控制）。
4.5 实战：如何利用生命周期做性能优化
理解了执行流程，优化思路就清晰了。我总结了几条实战经验：
- 减少不必要的 Activation：在规则条件中加入更严格的过滤，让议程中的待执行项尽可能少。议程越大，冲突解决的开销越大。
- 合理设置优先级：把「过滤性规则」（比如黑名单检查）设高优先级，让它们先执行。如果黑名单命中，后面的规则就不用执行了。
- 控制副作用范围：规则执行时尽量只修改必要的事实字段。修改整个对象会触发更多节点的重新评估。
- 使用议程组隔离：把不同阶段的规则分到不同议程组，用 focus 控制执行顺序。这样能避免「前置校验」和「后置处理」互相干扰。
一个小技巧：在调试阶段，我习惯在议程的 Activation 上打日志，记录每条规则被触发时的「事实快照」。这样当执行结果不符合预期时，可以回放整个匹配-解决-执行的过程，快速定位问题。
好了，规则执行流程的核心内容就这些。记住这个三阶段模型——匹配、解决、执行——以及它们之间的循环关系。下次遇到规则不触发或者执行顺序不对的问题，先别急着改规则，回头看看议程里发生了什么，往往能找到答案。