阿里IM技術分享(六):閒魚億級IM訊息系統的離線推送到達率優化
本文由阿里閒魚技術團隊逸昂分享,原題“訊息鏈路優化之弱感知鏈路優化”,即時通訊網有修訂和改動,感謝作者的分享。 文中部分連結如無法點選, 請從社群原文中開啟: http://www.52im.net/thread-3748-1-1.html ,或點選下文的“ 閱讀原文 ”!
1、引言
閒魚的IM訊息系統作為買家與賣家的溝通工具,增進理解、促進信任,對閒魚的商品成交有重要的價值,是提升使用者體驗最關鍵的環節。
然而,隨著業務體量的快速增長,當前這套訊息系統正面臨著諸多急待解決的問題。
以下幾個問題典型最為典型:
1) 線上訊息的體驗提升;
2) 離線推送的到達率;
3) 訊息玩法與訊息底層系統的耦合過強。
經過評估,我們認為現階段離線推送的到達率問題最為關鍵,對使用者體驗影響較大。
本文將要分享的是閒魚IM訊息在解決離線推送的到達率方面的技術實踐,內容包括問題分析和技術優化思路等,希望能帶給你啟發。
2、系列文章
本文是系列文章的第6篇,總目錄如下:
《 阿里IM技術分享(一):企業級IM王者——釘釘在後端架構上的過人之處 》
《 阿里IM技術分享(二):閒魚IM基於Flutter的移動端跨端改造實踐 》
《 阿里IM技術分享(三):閒魚億級IM訊息系統的架構演進之路 》
《 阿里IM技術分享(四):閒魚億級IM訊息系統的可靠投遞優化實踐 》
《 阿里IM技術分享(五):閒魚億級IM訊息系統的及時性優化實踐 》
《阿里IM技術分享(六):閒魚億級IM訊息系統的離線推送到達率優化》( * 本文 )
3、通訊鏈路型別的劃分
從資料通訊連結的技術角度,我們根據閒魚客戶端是否線上,將整體訊息鏈路大致分為強感知鏈路和弱感知鏈路。
強感知鏈路由以下子系統或模組:
1) 傳送方客戶端;
2) idleapi-message(閒魚的訊息閘道器);
3) heracles(閒魚的訊息底層服務);
4) accs(阿里自研的長連線通道);
5) 接收方客戶端組成。
整條鏈路的核心指標在於端到端延遲和訊息到達率。
強感知鏈路中的雙方都是線上的,訊息到達客戶端就可以保證接收方感知到。強感知鏈路的主要痛點在訊息的端到端延遲。
弱感知鏈路與強感知鏈路的主要不同在於: 弱感知鏈路的接收方是離線的,需要依賴離線推送這樣的方式送達。
因此弱感知鏈路的使用者感知度不強,其核心指標在於訊息的到達率,而非延遲。
所以當前階段,優化弱感知鏈路的重點也就是提升離線訊息的到達率。換句話說, 提升離線訊息到達率問題,也就是優化弱感知鏈路本身。
4、訊息系統架構概覽
下圖一張整個IM訊息系統的架構圖,感受下整體鏈路:
![](http://mdimg.wxwenku.com/getimg/ccdf080c7af7e8a10e9b88444af98393caca5c94bb56b158304be173f4567882a3231d8a62b2d50a95a407502f6df59c.jpg)
如上圖所示,各主要元件和子系統分工如下:
1) HSF是一個遠端服務框架,是dubbo的內部版本;
2) tair是阿里自研的分散式快取框架,支援 memcached、Redis、LevelDB 等不同儲存引擎;
3) agoo是阿里的離線推送中臺,負責整合不同廠商的離線推送通道,向集團使用者提供一個統一的離線推送服務;
4) accs是阿里自研的長連線通道,為客戶端、服務端的實時雙向互動提供便利;
5) lindorm是阿里自研的NoSQL產品,與HBase有異曲同工之妙;
6) 域環是閒魚訊息優化效能的核心結構,用來儲存使用者最新的若干條訊息。
強感知鏈路和弱感知鏈路在通道選擇上是不同的:
1) 強感知鏈路使用accs這個線上通道;
2) 弱感知鏈路使用agoo這個離線通道。
5、弱感知鏈路到底怎麼定義
通俗了說,弱感知鏈路指的就是離線訊息推送系統。
相比較於線上訊息和端內推送( 也就是上面說的強感知鏈路 ),離線推送難以確保被使用者感知到。
典型的情況包括:
1) 未傳送到使用者裝置 :即推送未送達使用者裝置,這種情況可以從通道的返回分析;
2) 傳送到使用者裝置但沒有展示到系統通知欄 :閒魚曾遇到通道返回成功,但是使用者未看到推送的案例;
3) 展示到通知欄,並被系統摺疊 :不同安卓廠商對推送的摺疊策略不同,被摺疊後,需使用者主動展開才能看到內容,觸達效果明顯變差;
4) 展示到通知欄,並被使用者忽略 :離線推送的點選率相比於線上推送更低。
針對“1)未傳送到使用者裝置”,原因有:
1) 離線通道的token失效;
2) 引數錯誤;
3) 使用者關閉應用通知;
4) 使用者已解除安裝等。
針對“3)展示到通知欄,並被系統摺疊”,原因有:
1) 通知的點選率;
2) 應用在廠商處的權重;
3) 推送的數量等。
針對“4)展示到通知欄,並被使用者忽略”,原因有:
1) 使用者不願意檢視推送;
2) 使用者看到了推送,但是對內容不感興趣;
3) 使用者在忙別的事,無暇處理。
總之: 以上這些離線訊息推送場景,對於使用者來說感知度不高,我們也便稱之為弱感知鏈路。
6、弱感知鏈路的邏輯構成
我們的弱感知鏈路分為3部分,即:
1) 系統;
2) 通道;
3) 使用者。
共包含了Hermes、agoo、廠商、裝置、使用者、承接頁這幾個環節。具體如下圖所示。
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4bbeed46907ad06645af31f00aea8afb35bd4c55e1938d71929929d51a3e5a1afc.jpg)
從推送的產生到使用者最終進入APP,共分為如下幾個步驟:
步驟1 :Hermes是閒魚的使用者觸達系統,負責人群管理、內容管理、時機把控,是整個弱感知鏈路的起點。;
步驟2 :agoo是阿里內部承接離線推送的中臺,是閒魚離線推送能力的基礎;
步驟3 :agoo實現離線推送依靠的是廠商的推送通道(如:蘋果的apns通道、Google的fcm通道、及國內各廠商的自建通道。;
步驟4 :通過廠商的通道,推送最終出現在使用者的裝置上,這是使用者能感知到推送的前提條件;
步驟5 :如果使用者剛巧看到這條推送,推送的內容也很有趣,在使用者的主動點選下會喚起APP,開啟承接頁,進而給使用者展示個性化的商品。
經過以上5個步驟,至此弱感知鏈路就完成了使命。
7、弱感知鏈路面臨的具體問題
弱感知鏈路的核心問題在於:
1) 推送的訊息是否投遞給了使用者;
2) 已投遞到的訊息使用者是否有感知。
這對應推送的兩個階段:
1) 推送訊息是否已到達裝置;
2) 使用者是否檢視推送並點選。
其中: 到達裝置這個階段是最基礎的,也是本次優化的核心。
我們可以將每一步的訊息處理量依次平鋪,展開為一張漏斗圖,從而直觀的檢視鏈路的瓶頸。
漏斗圖斜率最大的地方是優化的重點,差異小的地方不需要優化:
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229bfc62427c6bac88f1541f140b42d6419a626af2da91f831efb06704ecae4d29cd.jpg)
通過分析以上漏斗圖,弱感知鏈路的優化重點在三個方面:
1) agoo受理率 :是指我們傳送推送請到的數量到可以通過agoo(阿里承接離線推送的中臺)轉發到廠商通道的數量之間的漏斗;
2) 廠商受理率 :是指agoo中臺受理的量到廠商返回成功的量之間的漏斗;
3) Push點選率 :也就通過以上通道最終已送到到使用者終端的訊息,是否最終轉化為使用者的主動“點選”。
有了優化方向,我們來看看優化手段吧。
8、我們的技術優化手段
跟隨推送的視角,順著鏈路看一下我們是如何進行優化的。
8.1 agoo受理率優化
使用者的推送,從 Hermes 站點搭乘“班車”,駛向下一站: agoo 。
這是推送經歷的第一站。到站一看,傻眼了,只有不到一半的推送到站下車了。這是咋回事嘞?
這就要先說說 agoo 了,呼叫 agoo 有兩種方式:
1) 指定裝置和客戶端 ,agoo直接將推送投遞到相應的裝置;
2) 指定使用者和客戶端 ,agoo根據內部的轉換表,找到使用者對應的裝置,再進行投遞。
我們的系統不儲存使用者的裝置資訊。因此,是按照使用者來呼叫agoo的。
同時: 由於沒有使用者的裝置資訊,並不知道使用者是 iOS 客戶端還是 Android 客戶端。工程側不得不向 iOS 和 Android 都發送一遍推送。雖然保證了到達,但是,一半的呼叫都是無效的。
為了解這個問題: 我們使用了agoo的裝置資訊。將使用者轉換裝置這一階段提前到了呼叫 agoo 之前,先明確使用者對應的裝置,再指定裝置呼叫 agoo,從而避免無效呼叫。
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4bbc5fd8188685bf04396e358fcd775d0d2f54defc04d8e5d8ae5c311636ea36f3.jpg)
agoo呼叫方式優化後,立刻剔除了無效呼叫,agoo受理率有了明顯提升。
至此: 我們總算能對 agoo 受理失敗的真正原因做一個高大上的分析了。
根據統計: 推送被 agoo 拒絕的主要原因是——使用者關閉了通知許可權。同時,我們對 agoo 呼叫資料的進一步分析發現——有部分使用者找不到對應的裝置。優化到此,我們猛然發現多了兩個問題。
那就繼續優化唄:
1) 通知體驗優化,引導開啟通知許可權;
2) 與agoo共建裝置庫,解決裝置轉換失敗的問題。
這兩個優化方向又是一片新天地,我們擇日再聊。
8.2 廠商推送通道受理率優化
推送到達 agoo ,分機型搭乘廠商“專列”,駛向下一站:使用者裝置。
這是推送經歷的第二站。出站查票,發現竟然超員了。
於是乎: 我們每天有大量推送因為超過廠商設定的限額被攔截。
為什麼會這樣呢?
實際上: 提供推送通道的廠商( 沒錯, 各手機廠商的自家推送通道良莠不齊 ),為了保證使用者體驗,會對每個應用能夠推送的訊息總量進行限制。
對於廠商而言,這個限制會根據推送的型別和應用的使用者規模設定——推送主要分為產品類的推送和營銷類的推送。
廠商推送通道對於不同型別訊息的限制是:
1) 對於產品類推送 ,廠商會保證到達;
2) 對於營銷類推送 ,廠商會進行額度限制;
3) 未標記的推送 ,預設作為營銷類推送對待。
我們剛好沒有對推送進行標記,因此觸發了廠商的推送限制。
這對我們的使用者來說,會帶來困擾。閒魚的交易,很依賴買賣家之間的訊息互動。這部分訊息是需要確保到達的。
同樣: 訂單類的訊息、使用者的關注,也需要保證推送給使用者。
根據主流廠商的介面協議,我們將推送的訊息分為以下幾類,並進行相應標記:
1) 即時通訊訊息;
2) 訂單狀態變化;
3) 使用者關注內容;
4) 營銷訊息這幾類。
同時,在業務上,我們也進行了推送的治理——將使用者關注度不高的訊息,取消推送,避免打擾。
經過這些優化,因為超過廠商限額而被攔截的推送實現了清零。
8.3 Push點選率優化
通過優化agoo受理率、廠商受理率,我們解決了推送到達量的瓶頸。但即使訊息被最終送達,使用者到底點選了沒有?這才是訊息推送的根本意義所在。
於是,在日常的開發測試過程中,我們發現了推送的兩個體驗問題:
1) 使用者點選Push有開屏廣告;
2) 營銷Push也有許可權校驗,更換使用者登陸後無法點選。
對於開屏廣告功能,我們增加了Push點選跳過廣告的能力。
針對Push的許可權校驗功能,閒魚根據場景做了細分:
1) 涉及個人隱私的推送,保持許可權校驗不變;
2) 營銷類的推送,放開許可權校驗。
以上是點選體驗的優化,我們還需要考慮使用者的點選意願。
使用者點選量與推送的曝光量、推送素材的有趣程度相關。推送的曝光量又和推送的到達量、推送的到達時機有關。
具體的優化手段是:
1) 在推送內容上 :我們需要優化的是推送的時機和相應的素材;
2) 在推送時機上 :演算法會根據使用者的偏好和個性化行為資料,計算每個使用者的個性化推送時間,在使用者空閒的時間推送(避免在不合適的時間打擾使用者,同時也能提升使用者看到推送的可能性)。
3) 在推送素材上 :演算法會根據素材的實時點選反饋,對素材做實時賽馬。只發使用者感興趣的素材,提高使用者點選意願。
9、實際優化效果
通過以上我們的分析和技術優化手段,整體弱推送鏈路鏈路有了不錯的提升,離線訊息的到達率相對提升了兩位數。
10、寫在最後
本篇主要和大家聊的是隻是IM訊息系統鏈路中的一環——弱感知鏈路的優化,落地到到具體的業務也就是離線訊息送達率問題。
整體IM訊息系統,還是一個比較複雜的領域。
我們在訊息系統的發展過程中,面臨著如下問題:
1) 如何進行訊息的鏈路追蹤;
2) 如何保證IM訊息的快速到達(見《閒魚億級IM訊息系統的及時性優化實踐》);
3) 如何將訊息的玩法和底層能力分離;
4) 離線推送中如何通過使用者找到對應的裝置。
這些問題,我們在以前的文章中有所分享,以後也會陸續分享更多,敬請期待。
- 基於Netty,搭建高效能IM叢集(含技術思路 原始碼)
- 實時音影片入門學習:開源工程WebRTC的技術原理和使用淺析
- 百萬人線上的直播間實時聊天訊息分發技術實踐
- 跟著原始碼學IM(九):基於Netty實現一套分散式IM系統
- 探探的IM長連線技術實踐:技術選型、架構設計、效能優化
- 手把手教你實現網頁端社交應用中的@人功能:技術原理、程式碼示例等
- 阿里IM技術分享(六):閒魚億級IM訊息系統的離線推送到達率優化
- 大型IM系統有多難?萬字長文,搞懂異地多活!
- IM開發乾貨分享:萬字長文,詳解IM“訊息“列表卡頓優化實踐
- 阿里IM技術分享(五):閒魚億級IM訊息系統的及時性優化實踐
- 萬字長文,一篇吃透WebSocket:概念、原理、易錯常識、動手實踐
- 阿里IM技術分享(四):閒魚億級IM訊息系統的可靠投遞優化實踐
- 阿里IM技術分享(三):閒魚億級IM訊息系統的架構演進之路
- 搞懂現代Web端即時通訊技術一文就夠:WebSocket、socket.io、SSE
- 融雲IM技術分享:萬人群聊訊息投遞方案的思考和實踐
- 零基礎入門:基於開源WebRTC,從0到1實現實時音影片聊天功能
- IM開發技術學習:揭祕微信朋友圈這種資訊推流背後的系統設計
- IM開發乾貨分享:網易雲信IM客戶端的聊天訊息全文檢索技術實踐
- 融雲技術分享:全面揭祕億級IM訊息的可靠投遞機制
- 直播系統聊天技術(五):微信小遊戲直播在Android端的跨程序渲染推流實踐