目前，各行業的數智化進程如火如荼，企業對數智化用戶運營的需求日益旺盛；同時，在萬物互聯的5G時代，用戶觸達的渠道也變得更加豐富。企業需要更高效、智能的方式進行用戶觸達管理。基於此，個推將多年來積累的數字化運營經驗和用戶觸達能力相結合，打造了“消息中心”系統產品，能夠幫助企業客戶將APP通知欄消息、短信、微信、釘釘的系統消息、智能人工外呼、5G消息等行業八大主流用戶觸達渠道進行有效整合和管理。

本文從技術角度解讀“個推消息中心”如何實現多渠道消息下發的智能管理。

一、用戶觸達的三大範式

個推在消息推送領域有十餘年的實踐經驗，一直深度服務於企業消息管理的一線，深刻理解各行業客戶在消息管理和用戶觸達方面的差異化需求。通過總結大量的消息下發模版，對數十個行業場景的特徵進行整合，個推最終抽象出消息在多渠道的流轉過程和模式，形成了個推消息中心開展用戶觸達的三大基礎範式：併發消息、補發消息、分發消息。

1、併發消息

併發消息是指實現特定消息在多渠道的並行下發，適用於重要消息的大規模群發。比如，銀行在開展某次運營活動時，採用APP消息推送+微信+短信等多渠道為用戶推送活動優惠通知。

2、補發消息

為了提升消息的到達率，企業會對未觸達的用戶進行消息補發。比如，很多銀行會選擇將手機銀行消息推送作為發送動帳通知的主渠道，在手機銀行推送消息未到達時，再採用短信下發的方式通知客戶。

3、分發消息

根據消息內容和想要觸達的用戶群不同，企業會通過不同渠道下發不同的消息。比如，很多銀行在發送動帳通知時，會通過微信來發送200元以下的小額交易動賬消息，而針對200元以上的大額交易動賬則會選擇短信的方式來通知用戶。

個推消息中心依託用戶觸達的三大範式，打通了消息從產生、過濾、規則匹配、高效下發、海量消息保存以及最終展示的全鏈路，是一個集消息下發、精準匹配、效果追蹤、數據統計等功能於一體的平臺性產品。

個推消息中心能夠根據下發規則對消息、渠道和用戶群進行自動匹配，實現智能推送。相比傳統的單渠道推送，個推消息中心不僅能夠通過併發、分發、補發等方式實現更高的消息到達率；還能夠幫助企業更加科學地管理渠道資源，大幅減少短信費用和外呼成本，提升用戶運營效率。

二、個推消息中心的技術實現

同時，個推消息中心實現了對複雜的目標客群進行有效管理，能夠滿足金融、融媒體等行業客戶對大規模消息實時下發、海量數據存儲等方面的能力要求。

1、複雜目標客群管理

個推消息中心提供了一套統一的客戶通道關係存儲體系，能夠將各個通道的用戶體系和客戶方自身的用戶體系對應起來，實現了複雜目標客群的有效管理。由於客戶方系統的用戶體系和業務形態非常複雜，可能是1對1、1對N、N對1、N對M等對應關係，因此個推消息中心採用“N對M”為基礎存儲結構，並提供靈活配置的客群管理模塊以支持企業進行不同類型的客戶通道關係管理，滿足了絕大多數企業用戶的需求。

2、高併發消息下發

在類似“618”“11.11”等特殊的營銷節點或運營活動期間，企業往往需要在幾分鐘之內完成數百萬甚至千萬量級消息的批量下發。這就要求消息中心繫統必須具備數萬QPS的消息下發能力。我們做了如下處理，以滿足企業客戶對系統性能的要求。

減少Redis操作

個推消息中心中，對客戶通道關係的正向和逆向轉化關係的讀寫需要嚴重依賴於系統的Redis。所以，額外新增的Redis操作邏輯過多會給Redis集群帶來較大壓力，從而對原先單渠道推送的性能產生影響。這就要求我們將業務流程中非必要的Redis操作消除。我們首先整合了Redis存儲value的內容以減少Redis的讀寫次數；同時，用其他設計方案以代替Redis操作，例如：我們去除了依賴於Redis的分佈式token存儲方式，而採用其他的安全方式進行安全校驗，以減少Redis集群的壓力。

隔離

✦1）業務隔離
不同類型的推送任務對系統的資源佔用和要求不同。比如，全推、標籤推、分組推等推送任務要求系統在短時間內下發數百萬甚至數千萬條消息，會佔用較多的資源，給系統帶來較大沖擊，從而對單推、列表推等實時性較高的消息下發任務產生較大影響。所以我們對不同類型的推送任務進行了業務上的隔離，以保證系統及時響應和處理優先級更高的推送任務。

✦2）存儲資源隔離
同時，我們將關係型數據庫裡的數據根據業務特點及數據規模進行分庫，保證核心功能不受邊緣功能的影響；並將Redis集群隔離，劃分多個Redis集群，防止單個Redis故障對整個系統產生重大影響，保障系統的穩定運行。

分佈式任務調度

其次，我們將全推、標籤推、分組推等規模較大的推送任務拆分成一個個小任務，並由分佈式任務調度系統統一調度，由整個推送集群共同處理任務請求，以保證大批量消息的及時下發。

異步處理

消息中心推送流量往往具備流量大、波峰波谷差異巨大等特點，因此我們採用MQ、日誌異步落庫、異步RPC等形式，儘量避免了系統的阻塞，從而達到較高的QPS。

3、海量數據的存儲能力

系統在運行的過程中必然會產生數據，並需要對相關數據進行計算和存儲。個推消息中心繫統需要存儲的數據主要有三大部分：

✦ 客戶通道關係、消息下發計數等數據。在高QPS和高實時性的推送需求下，我們必須將此類數據（數量級在百萬乃至億級）存儲在緩存中以提升系統性能。

✦ 消息下發任務數據。個推消息中心需要對每個任務的詳情以及每個任務下消息的到達、點擊、展示等各類明細數據進行存儲。此類數據目前日增量在百萬及千萬級不等。

✦ 部分業務方要求長時間存儲的消息詳情。這部分數據往往日增量在千萬級到億級不等，存儲時間從半年到永久不等，且要支持較快的查詢及較高的QPS。

我們採用以下方式解決海量數據存儲的問題：

1）Codis集群
針對緩存數據，我們構建了分佈式Codis集群，採用代理+分片的形式對Redis進行擴容。以支持TB級系統緩存數據的存儲。

2）關係型數據庫分庫分表（MySQL和Oracle）
由於客戶的統計需求變化多樣，目前消息中心支持從用戶、模版、通道、任務等多維度對推送任務進行統計。我們以日維度+分庫分表的形式存儲了所有推送任務信息的詳情，支持了從用戶、模版、通道、任務等維度較為實時的統計。

3）HBase
HBase是一個分佈式的、面向列的開源數據庫。具備高可靠、高性能、存儲空間幾乎可以無限擴展的特點。我們採用HBase來存儲歷史消息，使系統可以支持PB級數據的存儲及數萬QPS的用戶維度消息查詢併發能力。

總結
本文對個推消息中心的技術實現進行了介紹。個推消息中心能對下發的消息進行統一調度、精細化管理，尤其是對於未觸達的用戶可以進行多渠道的補發、併發，協助客戶形成高轉化的投放策略。同時個推消息中心具備高併發、高可靠等性能，能夠很好地滿足行業客戶的運營需求。

個推“消息中心”採用私有化部署，可根據客戶具體需求進行個性化定製，已經服務於銀行、融媒體等多家行業客戶。