阿里IM技術分享(六):閒魚億級IM消息系統的離線推送到達率優化

本文由阿里閒魚技術團隊逸昂分享,原題“消息鏈路優化之弱感知鏈路優化”,有修訂和改動,感謝作者的分享。

1、引言

閒魚的IM消息系統作爲買家與賣家的溝通工具,增進理解、促進信任,對閒魚的商品成交有重要的價值,是提升用戶體驗最關鍵的環節。

然而,隨着業務體量的快速增長,當前這套消息系統正面臨着諸多急待解決的問題。

以下幾個問題典型最爲典型:

  • 1)在線消息的體驗提升;
  • 2)離線推送的到達率;
  • 3)消息玩法與消息底層系統的耦合過強。

經過評估,我們認爲現階段離線推送的到達率問題最爲關鍵,對用戶體驗影響較大。

本文將要分享的是閒魚IM消息在解決離線推送的到達率方面的技術實踐,內容包括問題分析和技術優化思路等,希望能帶給你啓發。

學習交流:

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

- 開源IM框架源碼:https://github.com/JackJiang2011/MobileIMSDK 

2、系列文章

本文是系列文章的第6篇,總目錄如下:

3、通信鏈路類型的劃分

從數據通信鏈接的技術角度,我們根據閒魚客戶端是否在線,將整體消息鏈路大致分爲強感知鏈路和弱感知鏈路。

強感知鏈路由以下子系統或模塊:

  • 1)發送方客戶端;
  • 2)idleapi-message(閒魚的消息網關);
  • 3)heracles(閒魚的消息底層服務);
  • 4)accs(阿里自研的長連接通道);
  • 5)接收方客戶端組成。

整條鏈路的核心指標在於端到端延遲和消息到達率。

強感知鏈路中的雙方都是在線的,消息到達客戶端就可以保證接收方感知到。強感知鏈路的主要痛點在消息的端到端延遲。

弱感知鏈路與強感知鏈路的主要不同在於:弱感知鏈路的接收方是離線的,需要依賴離線推送這樣的方式送達。

因此弱感知鏈路的用戶感知度不強,其核心指標在於消息的到達率,而非延遲。

所以當前階段,優化弱感知鏈路的重點也就是提升離線消息的到達率。換句話說,提升離線消息到達率問題,也就是優化弱感知鏈路本身。

4、消息系統架構概覽

下圖一張整個IM消息系統的架構圖,感受下整體鏈路:

如上圖所示,各主要組件和子系統分工如下:

  • 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、廠商、設備、用戶、承接頁這幾個環節。具體如下圖所示。

從推送的產生到用戶最終進入APP,共分爲如下幾個步驟:

  • 步驟1:Hermes是閒魚的用戶觸達系統,負責人羣管理、內容管理、時機把控,是整個弱感知鏈路的起點。;
  • 步驟2:agoo是阿里內部承接離線推送的中臺,是閒魚離線推送能力的基礎;
  • 步驟3:agoo實現離線推送依靠的是廠商的推送通道(如:蘋果的apns通道、Google的fcm通道、及國內各廠商的自建通道。;
  • 步驟4:通過廠商的通道,推送最終出現在用戶的設備上,這是用戶能感知到推送的前提條件;
  • 步驟5:如果用戶剛巧看到這條推送,推送的內容也很有趣,在用戶的主動點擊下會喚起APP,打開承接頁,進而給用戶展示個性化的商品。

經過以上5個步驟,至此弱感知鏈路就完成了使命。

7、弱感知鏈路面臨的具體問題

弱感知鏈路的核心問題在於:

  • 1)推送的消息是否投遞給了用戶;
  • 2)已投遞到的消息用戶是否有感知。

這對應推送的兩個階段:

  • 1)推送消息是否已到達設備;
  • 2)用戶是否查看推送並點擊。

其中:到達設備這個階段是最基礎的,也是本次優化的核心。

我們可以將每一步的消息處理量依次平鋪,展開爲一張漏斗圖,從而直觀的查看鏈路的瓶頸。

漏斗圖斜率最大的地方是優化的重點,差異小的地方不需要優化:

通過分析以上漏斗圖,弱感知鏈路的優化重點在三個方面:

  • 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,從而避免無效調用。

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)離線推送中如何通過用戶找到對應的設備。

這些問題,我們在以前的文章中有所分享,以後也會陸續分享更多,敬請期待。

附錄:相關資料

[1] Android P正式版即將到來:後臺應用保活、消息推送的真正噩夢

[2] 一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐

[3] 一套億級用戶的IM架構技術乾貨(上篇):整體架構、服務拆分等

[4] 一套億級用戶的IM架構技術乾貨(下篇):可靠性、有序性、弱網優化等

[5] 從新手到專家:如何設計一套億級消息量的分佈式IM系統

[6] 企業微信的IM架構設計揭祕:消息模型、萬人羣、已讀回執、消息撤回等

[7] 融雲技術分享:全面揭祕億級IM消息的可靠投遞機制

[8] 移動端IM中大規模羣消息的推送如何保證效率、實時性?

[9] 現代IM系統中聊天消息的同步和存儲方案探討

[10] 新手入門一篇就夠:從零開發移動端IM

[11] 移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”

[12] 移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結

[13] IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞

[14] IM消息送達保證機制實現(二):保證離線消息的可靠投遞

[15] 零基礎IM開發入門(一):什麼是IM系統?

[16] 零基礎IM開發入門(二):什麼是IM系統的實時性?

[17] 零基礎IM開發入門(三):什麼是IM系統的可靠性?

[18] 零基礎IM開發入門(四):什麼是IM系統的消息時序一致性?

本文已同步發佈於“即時通訊技術圈”公衆號。

同步發佈鏈接是:http://www.52im.net/thread-3748-1-1.html 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章