作者| 阿里文娛高級開發工程師 臻龍
責編 | 屠敏
頭圖 | CSDN 下載自視覺中國
背景介紹
隨著在線視頻行業數十年的發展，各家的會員業務，尤其是會員規模都已進入成熟期，呈現飽和狀態。會員營銷，不論是針對現有市場的精細化營銷，還是針對下沉市場的定向營銷，都需要更加針對性的打法。在這複雜需求背後，是強大營銷系統的支撐。下面，我將分享優酷營銷系統的技術實踐經驗。
面臨的挑戰
1.場景複雜多變
會員營銷的場景複雜多變，具體歸納總結是四類：折扣，買贈，領取，發放，支撐起優酷站內，（阿里生態）二三方，優酷OTT等多個業務方的營銷需求。
營銷場景一：折扣類。在商品維度，可以是簡單的普通活動的折扣，也可以是可選優惠券與普通普通折扣，支付渠道與普通活動折扣的疊加折扣。訂單維度，可以是單個訂單的折扣優惠，也可以是多個子訂單的組合折扣優惠；
營銷場景二：買贈類。贈送的權益，有虛擬的會員權益，也有阿里生態二三方合作方的聯合會員權益，比如88VIP，當然也可以是實物類的商品；
營銷場景三：領取類。不同的業務需求方，會根據自身業務訴求和業務目標，配置不同營銷領取能力的營銷策略。因業務而異，因目標而變換；
營銷場景四：發放類。符合業務邏輯，主動給用戶發放一定權益。業務邏輯也呈現多樣化，比如預約影片，可以給用戶發放觀影體驗特權；觀影過程中，滿足觀影時長，發放用戶成長值等等。
從以上四類場景出發，每年每季度都會出現新的玩法創新。比如，折扣的疊加，折扣買贈類的疊加、多個折扣能力互斥、折扣並領取的組合式營銷等等。反饋到後端的營銷系統上，不能一味的定製化開發，而是需要提供給運營同學，靈活的編排優惠的能力，並且實現複雜業務需求組合，快速拿到實驗結果數據，幫助運營及時調整策略，最終實現業務價值的最大化。
2.系統要求高可用，低延時
除了單獨的系統能力，營銷系統還擔負著與交易系統核心節點的優惠實現的使命，高可用，低延時的系統接口必不可少。如果優惠透出與下單場景的系統接口性能差，優惠透出問題凸顯，會影響用戶的下單意願和交易的訂單與支付；如果接口耗時大，會帶來交易渲染與下單的價格不一致，用戶無法得到看到的優惠，引發嚴重的客訴行為，更甚會造成很大的法務風險。
業務的特殊性，要求營銷系統業務核心接口，必須高可用，高性能，低延時，穩定性才能保證用戶良好的營銷體驗。
優酷會員營銷系統的架構實現
1.活動規則化，QL語言實現
活動規則化，即將業務條件抽象成業務規則，依據業務邏輯對流程進行編排。
營銷活動的業務規則抽象，即符合一個流程中所有節點中的規則條件，才能符合該活動。基於對業務的劃分，最常見的規則有人群規則，會員身份規則，次數規則，商品規則，庫存規則等等。
同一個活動模型下，通過對活動最小單元的規則選取和流程的編排，可以擴展出適用於不同業務場景的優惠活動，真正實現靈活快速的支撐業務。
如何實現業務規則抽象能力？如何將規則的實現侵入性降到最低？優酷會員營銷系統採用阿里集團推薦的QL語言，一個輕量級的類java語法規則引擎，嵌入式規則引擎更加靈活。
該技術選型支持標準的JAVA語法，自定義操作符號重載，支持函數定義、宏定義，弱腳本語言，使用靈活，整個運算過程通過 ThreadLocal 來保證線程安全，資源消耗少，不會new新的對象，是使用緩存池技術實現。
QLExpress腳本引擎詳解
2. 統一營銷架構升級，核心引擎實現
上節的營銷系統，能滿足90%以上的營銷需求。接下來的難點是單一優惠形式向複雜的組合優惠形式的轉變。單一優惠形式問題凸顯，無法支持優惠疊加，優惠價格體系薄弱，核心引擎比較弱，複雜場景難以支撐，維護成本太高。
基於以上的問題點，我們作出了架構升級以及核心營銷節點的優化。以新的優惠券能力擴展為契機，抽象出統一營銷的能力，實現各種優惠能力的統一。在統一營銷的管理下，實現各種優惠能力的互斥與疊加，通過核心引擎的價格等優惠計算，最終輸出給交易系統。
有了這樣一個統一營銷架構之後，不僅僅是針對優惠券的疊加優惠能力，更加可以靈活的擴展增加其他優惠能力，最終數據合理的數據結構，能夠描述多種優惠能力的組合，給用戶帶來更加豐富的營銷體驗。
統一營銷架構示意圖
一個複雜的，具備多種優惠能力的統一營銷系統，其核心引擎是怎樣實現的呢？引擎核心實現如下：
-
優惠請求上下文，優惠請求信息獲取
-
優惠模型定義，不同優惠類型的模型定義
-
優惠分類引擎，根據優惠類型進行數據分類，業務規則生成優惠組合序列
-
優惠計算上下文，將優惠組合序列的計算上下文透傳給計算引擎
-
優惠計算引擎，對優惠組合序列，進行順序的價格計算，並支持多幣種
-
優惠計算結果，針對不同的優惠組合序列，輸出不同的計算結果，生成以組合、文案、優惠、價格等信息組合的優惠數據結構
-
計算結果排序，多重維度排序後，輸出優惠信息
核心引擎實現示意圖
3. 服務如何做到低延時，高可用
3.1 多緩存存儲實現
採用LocalCache本地緩存與KV存儲的分布式緩存相結合的方式。
首先將活動基礎數據，規則數據，收穫數據等數據量小，且訪問非常頻繁的活動數據，緩存到本地緩存中。分布式集群中每個JVM都有緩存，需要有實時的廣播消息監聽，感知活動數據的更新，實現增量的更新機制。同時我們也完善了全量數據的更新機制，保證全量數據的一致性。
其次將用戶參與活動次數等用戶維度數據，進行分布式緩存的存儲並落盤。作為DB的數據緩存，提供給分布式集群查詢校驗次數的快速高性能的查詢服務，減少對DB的查詢依賴。DB的實時變更的binlog消息提供給KV存儲做准實時數據同步。
營銷緩存體系架構示意圖
3.2 多線程匹配實現
以交易營銷核心節點為細分，將渲染，下單，發放收穫等核心節點分類，各自業務節點都採用多線程實現，依據業務類型不同，設置各自的線程池大小，併合理規定線程任務隊列，多餘線程的超時自動銷毀，保證系統最優化。
多線程實現使用ExecutorService、Callable、Future實現有返回結果。執行Callable任務，獲取到一個Future的對象。在該Future對象上調用get就可以獲取到Ca任務返回的Object。值得注意的是get方法是阻塞的，直到等待全部線程返回結果。
線程池該設置多少個線程合適，如何設置才能使得系統性能最優，在這裡不做詳細展開，可以搜索相關資料學習。其中線程池核心參數如下：
-
corePoolSize：線程池核心線程數量
-
maximumPoolSize：線程池最大線程數
-
keepAliveTime：線程數大於核心線程數時，多餘的空閒線程存活的最長時間
-
unit：單位時間
-
workQueue：任務隊列，用來儲存等待執行任務的隊列
-
threadFactory：線程工廠，用來創建線程，一般默認即可
活動多線程匹配示意圖
3.3 異步化收穫實現
優惠活動收穫的發放是與交易系統的支付成功調用緊密聯繫在一起。支付的成功在交易發放會員權益的同時告知營銷發放阿里生態二三方贈送權益。由於二三方權益接口性能不一，為了實現高性能接口服務能力，採用異步化發放權益+重試失敗的機制實現。
交易支付成功後，通知營銷發放權益，發放通知進入業務消息，營銷平台訂閱消息，將權益發放出去，針對失敗的處理告知消息later，為下一次重試做準備，並設定重試次數限制。以冪等ID為標識，保證權益發放唯一性。
收穫異步重試示意圖
3.4 分布式事務實現
複雜的業務邏輯，高並發的業務場景，尤其是交易營銷類業務節點，要保證業務的一致性，缺少不了鎖的實現。
交易營銷的下單流程，針對限制次數的高價值優惠能力，要保證業務處理的運行中用戶數據的一致性，需要對業務節點加鎖。活動的下單節點採用的是分布式鎖，通過業務規則確定鎖的唯一標識，同時是可重入鎖。鎖的實現注意了業務加鎖與業務解鎖，並設置了鎖的超時時間，保證鎖高可用。
為了保證業務流程的一致性，還有庫存鎖的實現。了解MySQL的讀者都清楚，MySQL是插件式存儲引擎結構，分為兩層：一層是MySQL Server層；另一層是存儲引擎層。我們採用QUEUE_ON_PK在Server層排隊，減少kernel_mutex在並發場景下對資源的競爭；依賴DB的行級鎖，避免使用樂觀鎖在高並發場景下導致業務的失敗，提升了業務處理成功率。
總結建議
以上是營銷平台如何高效支撐營銷需求的實踐方案，總結下來有主要兩點：
一是系統架構設計要通用，靈活，擴展，才能高效支撐業務多變；
系統架構設計要充分考慮通用性和擴展性，尤其是支撐複雜多變的業務系統。在設計系統的同時考慮到未來業務的方向，反覆推敲系統架構的合理性。至於靈活性，對系統模塊進行詳細的拆解與劃分，靈活運用適合業務的設計模式，做到可復用。
二是複雜的業務邏輯背景下，高可用低延時的服務設計要多維度合理化實現；
簡單的業務實現考慮合適的設計模式，複雜的業務實現考慮整體的性能優化實現。緩存，多線程，協程，異步，重試，鎖實現，分布式最終一致性等等要結合業務處理本身，而不是硬懟上去，更多的是考慮其實現的合理性。