個人博客地址:http://www.ltang.me/2019/10/22/dynamic-limits-for-rights/
前幾天讀了《規則引擎：大廠營銷系統資格設計全解》，裏面對於靜態資格、動態資格的設計，雖然叫法名稱不同，但與我們目前在做的營銷管理系統設計從業務以及邏輯流程上很相似，然而做得更優雅更抽象。
具體而言
靜態資格的判斷
在進行靜態資格判斷時，我們系統目前是將每一個活動的靜態資格做成一個drools腳本，對於一個觸發用戶，需要使用他的標籤數據去執行每一個活動的規則腳本來判斷是否滿足靜態資格條件，也就是我們所定義的客羣入主條件。而在作者所在的公司做的營銷系統，將所有活動的規則組合成一個具有分支的drools腳本，一個用戶只需要執行一個腳本就能知道他滿足哪些活動條件。
從業務角度來看，其實我們目前的做法不能說不好，更符合我們公司目前活動模式以及比較複雜的規則配置，並且，將所有活動的客羣規則組合成一個規則腳本，其實是對規則做了限制，要求活動的規則是有順序性，不如我們目前的做法靈活。但是，可以參考這種思路做一個資格服務，上游系統直接使用用戶ID即可查出該用戶有資格參與的所有活動，那就補充了我們系統中遺漏的一塊，用戶可以在參與活動前就查詢自己是否有資格參與，而不是被動的等待系統觸達。
動態資格的判斷
文章中的動態資格，在我們的系統中被認爲是一個權益的脫頻設計。
相對而言，我們目前的脫頻設計會更粗糙，僅僅針對某個活動下人維度+時間維度的脫頻，沒有針對活動維度以及權益自身的資格限制。也就是說，我可以配置一個人在活動A中，每週、每月、每年、整個活動週期中最多能獲取的權益數目，但是不能配置整個活動A每週、每月、每年、整個活動週期內最多能發放的權益數目。
同時，沒有做緩存，每次需要對用戶發放權益時，都需要實時計算他已經發放了多少，再算出他還能發放多少（從權益角度而言我們的設計會更復雜，不僅需要考慮數量，還需要考慮限制金額）。雖然目前的數據量情況下影響不大，但是這是一個需要優化的點，需要將動態資格（按維度已經領取的，最多能領取的）數據緩存到redis。
此外，代碼寫得太醜，沒有層級，沒有抽象，僅僅滿足業務需求。
所以，最近幾天在思考如何對脫頻（也就是動態資格）的實現再做設計和優化。目前想到的優化點：
- 權益的動態資格限制可以按維度、週期和總額來多次限制。維度分爲活動、計劃、人、以及權益自身；週期分爲自然日、周、月、年、用久。那麼我在配置一個權益的時候，比如騰訊視頻會員，可以限制它每個活動一年最多發放1000個，總共加起來一年不能超過10000個，每個人每個月不能超過一個…等等；
- 可以將每個維度、週期當前已經發放的權益寫進redis，這樣不需要在發放的時候再通過流水實時計算已經發放了多少，直接從redis獲取並更新數量。
由於業務的複雜性，針對上面的兩點優化，還是有很多難點。比如：
- 權益所屬月份、或自然天、自然年，由於實際活動中，會有當前月發放的權益卻要求它屬於上一個月（或其他月）的場景，那麼我們在判斷動態資格的時候，還要先根據配置以及系統時間（或觸發時間）來計算實際權益所屬週期
- 由於有人的維度，所以人維度key的數量 = 用戶數 * 週期數，以天來算，100萬用戶，一年下來，每個用戶都要保存365天每一天的數據，key的數量會很嚇人。這裏考慮幾個點：
- 用redis做緩存的話，有效期設爲多少？會不會有需求發放的權益是一年前的，結果要我去找一年前某一天這個用戶發放了多少然後再做資格判斷？這種情況怎麼處理；
- 如果緩存數據需要落到數據庫，那麼選hbase還是mysql?數據量如何評估？分別有什麼優缺點？
- 假如業務在剛開始的時候，沒有對某個維度某個週期的數量做限制，然後後期突然又要加上限制了，那麼之前已經發放的數據是否還要計算在內呢。如果不計在內從代碼實現上來說比較簡單，數據量也會大大減少，但是業務不一定接受；如果要計算在內，那麼，不管是否有配置，都需要把每個維度、每個週期的發放數量記錄下來，這樣就有大量的數據冗餘，也許業務永遠都用不上…
真是個複雜的問題，容我再好好想想。