1 背景

轉(zhuǎn)轉(zhuǎn)不同業(yè)務(wù)會根據(jù)各自業(yè)務(wù)特點(diǎn)，經(jīng)常性地向不同用戶推送各種消息。例如：

• 每天向部分圖書新用戶發(fā)放紅包，并推送站內(nèi)卡片消息，以刺激新客增長；
• 每周向部分奢侈品用戶發(fā)送站內(nèi)系統(tǒng)消息，以召回老用戶；
• 在世界圖書日推送站內(nèi)消息，同時發(fā)布圖書微信公眾號消息；
• 在指定日期，向游戲線索商家推送push，并發(fā)送短信提醒等等。

圖片

隨著各業(yè)務(wù)的不斷成熟，“消息推送”類型的需求逐漸累積，我們從中總結(jié)出了如下特點(diǎn)：

• 不同業(yè)務(wù)的推送主體不同，例如：圖書、游戲、奢品等。
• 每次推送面向的用戶群不同，例如：瀏覽過某些頁面的用戶、提交過某種訂單的用戶、新注冊的用戶等。
• 用戶數(shù)據(jù)來源不同，有些是通過執(zhí)行HiveSQL生成的，有些是通過用戶畫像平臺圈定的，有些是產(chǎn)品同學(xué)人工指定的Excel表格。
• 推送渠道多種多樣，包含紅包、push&IM消息、短信、公眾號消息等。此外，還包含組合發(fā)送的情況，例如：先發(fā)紅包再發(fā)push，站內(nèi)消息和短信同時推送等。
• 每個推送對應(yīng)各自的推送內(nèi)容，包含：標(biāo)題文案、落地頁、圖片等。同時，可能會伴隨文案的動態(tài)替換。例如：點(diǎn)擊消息，跳轉(zhuǎn)至訂單詳情頁，需要根據(jù)不同用戶替換不同落地頁鏈接。
• 不同推送有各自的推送頻次，有些是定時周期性推送，有些是臨時一次性推送。此外，周期維度各不相同，有些是每天發(fā)送，有些是指定一周中的某幾天推送。
• 推送需求的業(yè)務(wù)目的不同，有些是為了拉新，有些是為了召回，還有些是為了提醒用戶。

痛點(diǎn)在于，每次面對新的推送，我們都需要針對上述特點(diǎn)，編碼一個新的推送任務(wù)，而每個任務(wù)的實現(xiàn)過程，都伴隨著重復(fù)搬磚：

• 都需要增加一套推送配置，進(jìn)而生成一套消息上下文；
• 為了保證可靠性，都需要做防重頻率校驗；
• 為了提升效率，都需要通過異步方式提升速度；
• 為了保證高數(shù)據(jù)量級下的系統(tǒng)能力，還需要同時進(jìn)行速度控制。
• 都需要統(tǒng)計對成功率、觸達(dá)率、打開率做統(tǒng)計。

上述的重復(fù)能力的實現(xiàn)會造成冗余代碼和人力成本。此外，每個推送配置分散在各個角落，也不方便代碼維護(hù)。因此，需要一個較為通用的推送平臺，將這一類需求進(jìn)行統(tǒng)一管理。

2 設(shè)計思路

整體設(shè)計思路為：將“可變的”配置化，將“不變的”系統(tǒng)化。

2.1 將"可變"的配置化

維護(hù)一張推送配置表，為每一個推送需求創(chuàng)建一條配置記錄。上述背景中提到的“特點(diǎn)”即為“可變的”，將其抽象為配置表中的一個字段。例如：

• “業(yè)務(wù)方”字段：將推送主體抽象成一個枚舉類，每個業(yè)務(wù)方對應(yīng)枚舉類中的一個值。
• “推送類型”字段：將不同推送渠道抽象成不同推送類型，該字段存儲的是渠道列表，允許同一推送需求選擇多個推送渠道。
• 各推送內(nèi)容字段：標(biāo)題、文案、落地頁、圖片、紅包計劃id等。此外，針對上述類似“訂單詳情頁”的推送，需要在配置項中加入占位符，例如：不同用戶根據(jù)訂單id區(qū)分落地頁，則需要在鏈接的相應(yīng)位置中加入${訂單id}占位符。
• 用戶來源相關(guān)字段：若為HiveSQL生成的，則需要填寫“文件id”和“API key”，以觸發(fā)sql任務(wù)執(zhí)行；若來自用戶畫像平臺，則需要填寫“人群id”，以從拉取圈定數(shù)據(jù)；若為人工指定，則需要上傳excel文件，由系統(tǒng)解析。

2.2 將"不變"的系統(tǒng)化

將上述“重復(fù)編程”的工作內(nèi)容，抽取成一套代碼，沉淀為通用的系統(tǒng)能力。例如：

• 維護(hù)一張推送用戶表，記錄用戶id、對應(yīng)的配置id、推送結(jié)果、失敗原因等。
• 將配置表中的配置項和用戶表中的用戶信息，根據(jù)不同推送渠道，映射成推送上下文實體。
• 執(zhí)行推送前，進(jìn)行用戶維度的防重和頻率校驗，若系統(tǒng)判斷重復(fù)推送，則直接將失敗結(jié)果寫回。
• 執(zhí)行推送時，開啟線程池異步，并限制遠(yuǎn)程服務(wù)接口調(diào)用QPS。
• 推送后，記錄推送結(jié)果，并分批將結(jié)果回寫至用戶表。

整體設(shè)計

按照上述思路，將開發(fā)后的推送工具可視化之后，當(dāng)新增一個推送需求時，產(chǎn)品同學(xué)只需在后臺添加一個配置，將推送需求填充至各配置項即可。若用戶來源為HiveSQL生成，研發(fā)同學(xué)只需編寫SQL語句圈定用戶群，添加至用戶表。接下來的工作全部交給系統(tǒng)，即可滿足新的推送需求。一方面，將研發(fā)同學(xué)從重復(fù)搬磚中解放出來，省時省力；另一方面，所有推送配置集中交給后臺管理，方便維護(hù)。

3 實現(xiàn)細(xì)節(jié)

3.1 速度控制

• 異步化：由一個主線程順序執(zhí)行推送，顯然效率低下。為保證推送速度，我們使用線程池開啟異步推送：主線程只負(fù)責(zé)從庫表讀取推送數(shù)據(jù)，分批將推送任務(wù)提交至線程池任務(wù)隊列。

異步推送過程

• 分片：當(dāng)面對百萬甚至千萬級數(shù)據(jù)量時，推送任務(wù)集中在單節(jié)點(diǎn)上，一方面容易造成單機(jī)過載，另一方面容易達(dá)到性能上限。為進(jìn)一步提升系統(tǒng)效率，并實現(xiàn)負(fù)載均衡，我們使用分片廣播調(diào)度：將推送任務(wù)分布至集群中各機(jī)器上，分片執(zhí)行。分片策略：各機(jī)器分批從用戶表中讀取相同數(shù)據(jù)量的用戶，表主鍵id%機(jī)器數(shù)，若命中當(dāng)前機(jī)器號，則執(zhí)行推送。

分片調(diào)度

• 斷點(diǎn)重試：用lastId記錄上一批次推送數(shù)據(jù)的結(jié)束位置，每臺機(jī)器將各自的lastId緩存至redis，用來標(biāo)識執(zhí)行進(jìn)度。若任務(wù)異常中斷，將根據(jù)lastId進(jìn)行斷點(diǎn)重試，避免全表掃描。
• 接口限速：消息推送依賴平臺能力，因此在提升效率的同時，會在RPC接口調(diào)用處通過架構(gòu)組件設(shè)置全局QPS限制。

3.2 資源分配策略

無論線程池、機(jī)器數(shù)還是配置的QPS限速為多少，單時段的推送資源都有上限。因此，在面對同一時段多個配置執(zhí)行推送時，必然要解決資源分配問題。主要考慮如下幾種策略：

• 按優(yōu)先級順序

按優(yōu)先級順序

這樣分配的好處在于，策略比較簡單，只需配置優(yōu)先級即可解決資源分配問題。但同時會引入新的問題，例如：設(shè)置優(yōu)先級時應(yīng)該考慮哪些因素？當(dāng)優(yōu)先級相同時該如何處理等。此外，優(yōu)先級低的配置可能始終沒機(jī)會被執(zhí)行。

• 按數(shù)據(jù)量大小

每個時段執(zhí)行推送前，先計算當(dāng)前時段各命中配置的數(shù)據(jù)量大小，按比例分配可執(zhí)行的推送量。

例如：共有3個配置，總數(shù)據(jù)量分別為：40、20、20，每個時段最大推送量為：30。

時段1：命中配置為前2個，則按比例劃分的數(shù)據(jù)量分別為：20、10。推送結(jié)束后，3個配置的余量分別為：20、10、20。

時段2：待推配置為3個，將余量按比例劃分后的數(shù)據(jù)量為：12、6、12。推送結(jié)束后剩余：8，4，8。

時段3：將剩余數(shù)據(jù)推送完畢。

按數(shù)據(jù)量大小

按數(shù)據(jù)量分配的好處在于，可以根據(jù)推送進(jìn)度，實時動態(tài)分配占比，保證每個配置都有機(jī)會推送數(shù)據(jù)，更加公平。但是策略相對復(fù)雜，每次推送前需要重新掃表計算數(shù)據(jù)量，一定程度上影響推送性能。

• 均勻分配

每個時段推送前，根據(jù)當(dāng)前命中的配置數(shù)，均勻分配推送量。例如：共有3個配置，總數(shù)據(jù)量分別為：40、20、20，每個時段最大推送量為：30。

時段1：待推配置為前2個，則均勻分配的數(shù)據(jù)量分別為：15、15。推送結(jié)束后，3個配置的余量分別為：25、5、20。

時段2：待推配置為3個，將余量均分30后的推送量為：10、5、10。推送結(jié)束后，第2個配置的5條數(shù)據(jù)全部推送完畢，其他配置的余量分別為：20、10。

時段3：剩余配置均分30后的推送量：15，10。剩余配置1的5條數(shù)據(jù)。

時段4：將配置1的數(shù)據(jù)全部推送。

均勻分配

綜上，對比優(yōu)先級策略，均勻分配可以保證公平性，每個配置都有機(jī)會執(zhí)行一定數(shù)據(jù)量的推送，此外，均勻分配有一個默認(rèn)優(yōu)先級：數(shù)據(jù)量越小越先推送完成，符合業(yè)務(wù)場景要求；相比按數(shù)據(jù)量策略推送，均勻分配不需要二次讀表計算數(shù)據(jù)量，效率更高。因此，我們最終選擇均勻分配策略。

3.3 問題解決

• 現(xiàn)象

系統(tǒng)上線后，面對千萬級的推送量，持續(xù)Full GC。

異常監(jiān)控

• 原因

主線程不斷讀取庫表，獲取用戶信息，分批提交至線程池執(zhí)行推送。由于執(zhí)行推送的耗時大于數(shù)據(jù)讀取，導(dǎo)致線程池任務(wù)隊列累積，進(jìn)而造成內(nèi)存積壓。

• 改進(jìn)

改用生產(chǎn)者-消費(fèi)者模式

圖片

維護(hù)一個固定長度的阻塞隊列，隊列不空時，由消費(fèi)者從隊列中取數(shù)并執(zhí)行推送；隊列不滿時，由生產(chǎn)者掃表取數(shù)并放入隊列。當(dāng)生產(chǎn)者速度過快，即隊滿時，生產(chǎn)者線程阻塞，等待消費(fèi)者推送數(shù)據(jù)完成后，隊列不滿時，再次喚醒。

• 效果

1. Full GC問題不復(fù)存在。
2. 老年代使用明顯下降。

4 上線效果

目前，已將上述功能可視化至業(yè)務(wù)后臺，開放給多業(yè)務(wù)方。

圖片

至此，每產(chǎn)生一個推送需求，產(chǎn)品同學(xué)只需在后臺新建一條推送配置，并根據(jù)需要填寫各配置項，即可完成推送。

圖片

上線至今，已支持轉(zhuǎn)轉(zhuǎn)多業(yè)務(wù)方日常及活動推送，日均達(dá)百萬級推送量，最高可達(dá)兩千萬推送量。

5 總結(jié)

本文介紹了轉(zhuǎn)轉(zhuǎn)一體化推送平臺的實現(xiàn)，現(xiàn)已成為多業(yè)務(wù)日常推送的通用工具。未來會在諸如推送目標(biāo)轉(zhuǎn)化率、推送結(jié)果定向通知等方面繼續(xù)完善和豐富系統(tǒng)能力。

關(guān)于作者

陳曦，轉(zhuǎn)轉(zhuǎn)訂單業(yè)務(wù)研發(fā)工程師。