開發壹個風控系統，包括壹個規則引擎和壹個計算引擎。主要內容如下:
1.規則的添加、刪除、修改和實時生效，以及規則的分類實施。
2.按照某個緯度計算累計值，比如IP、用戶id、賬號等緯度。
3.需要支持滑動窗口、滾動窗口、長度窗口等。
遇到的主要問題如下:
1.redis太不願意做流量計算了。第壹，根據業務需要，至少有幾億個鍵要統計，最多有幾十億個。另外，redis需要存儲少量的交易信息。估計金額也很可觀。
2.redis中的熱鍵尤為明顯。比如按照商家的緯度，如果商家的密鑰不拆包，像盒馬這種有流量的商家對Redis的壓力會很大。
我們采用redis的集群模式，這樣redis熱鍵會對redis產生更大的影響。這是非常必要的分裂，例如，按小時。？
3.在流計算中，壹個是無序導致累加計算不準確(有負值)，另壹個是消息延遲。當時我們試圖用flink中水印的概念來解決問題，但是發現並不合適。這個坑是我們練完才發現的。
最痛苦的體驗是消息解析的無序和延遲，現在是采取糾正措施來解決。
規則引擎
我們選擇drools作為規則引擎，簡單探討了drools core、drools DRL、drools CEP等。，但是回過頭來看，drools在使用上還是有很多不足的地方，而且顯然，暫時沒有更換的打算。
1.如何用drools CEP做分布式？我們發現drools CEP中的幾個窗口都是在內存中計算的，所以沒有好的辦法應用到分布式緩存中，這幾乎是不可能的，除非drools也集成了redis等分布式緩存。
2.使用drools非常麻煩，因為有很多依賴。第二，我們在drools中只使用雅思等判斷，其他很多函數基本不用，因為1解決不了分布式問題。所以從這個角度來說，drools已經被廢了，沒必要再創造出kiesession這種重量級的東西。
3.Drools中支持的操作符並不是特別充分，比如log、sum、max、avg AVG等操作，都是不支持的。DRL語對商務人士不太友好。
4.另外，drools中的連續和不連續規則也看不出怎麽配置。至少flink cep有這樣的API。
綜上所述，不得不吐出口水，真是無語。可能理解起來很簡單，還有其他方法。另外drools workbench也是無語，復雜。估計口水廠商想通過這種方式賺錢。
壹般來說，如果有其他選擇，最好不要選擇口水。分布式的問題不解決就廢了，因為各種分布式的窗口都需要我們自己去實現。我們做什麽呢
最後，規則引擎采用drools根據具體的業務含義創建不同的kiesession。Drools扮演if else判斷的角色。至於滾動窗口，長度窗口和滑動窗口都是redis計算出來的。頭痛，是的
1.根據不同的統計緯度，粗略計算，redis中需要數十億個鍵進行計算。
2.滑動窗口暫時依賴於redis的zsort的數據結構，性能不是很好。
3.熱鍵問題，尤其是大商家的熱鍵問題，需要拆分，比較復雜。
4.信息延遲和信息混亂。
所以對計算引擎的需求壹般是
1.計算速度快，幾百條規則，很快就能算出準確的結果。
2.計算精度，面對亂序和延遲消息時，如何更精確地計算。
3.計算量，前面說了，十億鍵，除了存儲壹些信息，計算的中間狀態等。，如何在redis中丟失它們會導致計算不準確。
基於以上問題，關鍵是如何做得更好，優化得更好。說實話，我還沒找到答案。我能做的就是不斷優化redis計算(暫時還不能上傳大數據，比如flink，spark等。)並減少redis操作帶來的網絡開銷。
其實最後我想提壹下，如果可以用內存計算代替分布式計算是不是會更快，比如按照業務進行分段，這樣每個實例中統計的中間值就不需要匯總，所以每個實例只需要內存計算，不需要訪問redis，也不需要帶來網絡開銷。但是，這也會帶來架構上的調整，比如如何做容錯，如何做狀態持久，等等壹系列問題。？
從使用redis的結果來看，效果還不算太差。不考慮很熱的鍵，最高TPS 6000多(2臺機器，16核，32G內存)，壹般公司的業務其實也能滿足。對於非常熱的鍵，後續的優化就是繼續拆分。
壹個好的風控系統是很難的，做好筆記，希望不斷成長。