3.2 统一分发处理抽象公共分发模板：事件参数和有效性检测 → 分发到事件规则匹配器 EventMatcher → 输出到渠道发送流程
文章插图
可靠平滑启停
1. MQ消费端分发主流程未处理完成，系统重启可能会造成事件消息丢失 。
解决方案 ：配置MQ消费端没有返回ack时，MQ服务端重新发送消息 ， 此时业务消费必须保证幂等性 。
2. MQ分发主流程处理完成已返回ack，但是在分发到业务线程池过程中，由于JVM重启而丢失 。
解决方案 ：这种场景时间极短，可以等待分发完成再进行ack 。
3. MQ分发主流程分发到业务线程池处理过后， 但是线程池处理渠道发送过程仍可能因为JVM重启而丢失 。
解决方案 ：
- 利用JVM ShutdownHook钩子函数设置重启标记flag，MQ取数据时可以根据flag不再取出数据；
- 业务线程池不再接受新的任务, 同时利用线程池自身的Hook，等待处理线程池完成已有的任务 。
业务接入方可以提前将业务数据加载到统一大数据平台，并补充元数据配置，支持实时事件数据之外的数据补全 。
指标统计
对规则配置数据进行，使用Flink CEP负责事件处理，支持时间窗口计算 。
交并差运算
基于Presto计算查询引擎，对不同目标用户群进行交并差负责运算，得到处理后的结果数据 。
3.4 规则匹配器义传统方案
使用简单直接的硬编码的方式，根据不同的事件条件进行编码处理，适合迭代更新要求低的小型系统 。
传统方案存在的问题
- 硬编码开发成本高 ， 交付时间长，难以应对需求变化 。
- 业务规则重复累赘，难以维护 。
- 业务规则发生变化需要修改代码 ， 重启服务后才能生效 。
狭义上的规则引擎是业务规则管理系统，英文名为BRMS(即Business Rule Management System)，指一整套的规则管理解决方案 。
而广义上的规则引擎是指一个可以将业务决策从应用程序代码中分离出来的输入输出组件 ， 接收业务数据输入，并根据业务规则输出决策 。
规则引擎重点关注的是：规则配置的通用性和扩展性，以及规则匹配的性能 。
规则引擎优点
- 业务规则与系统代码分离 ， 实现业务规则的集中管理 。
- 在不重启服务的情况下可随时对业务规则进行扩展和维护 。
- 可以动态修改业务规则，从而快速响应需求变更 。
- 规则引擎是相对独立的 ， 只关心业务规则 ， 使得业务分析人员也可以参与编辑、维护系统的业务规则 。
- 减少了硬编码业务规则的成本和风险 。
- 使用规则引擎提供的规则编辑工具，使复杂的业务规则实现变得的简单 。
目前开源规则引擎 Drools、Easy Rules、表达式引擎Aviator，还有动态语言Groovy、甚至直接使用SpEL进行封装都可以作为规则引擎的一种实现方案 。
