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進行封裝都可以作為規則引擎的一種實現方案 。
