背景

IM消息作為閑魚(yú)用戶(hù)重要的交易咨詢(xún)工具，核心目標(biāo)有兩點(diǎn)，第一是保證用戶(hù)的消息不丟失，第二是保證用戶(hù)的消息及時(shí)送達(dá)接收方。IM消息根據(jù)消息的接收方設(shè)備是否在線(xiàn)，分為離線(xiàn)和在線(xiàn)推送，數(shù)據(jù)顯示目前閑魚(yú)每天有超過(guò)一半以上的IM消息是走在線(xiàn)通道的，而在線(xiàn)消息的到達(dá)率、及時(shí)性是直接影響用戶(hù)體驗(yàn)的，本文將著重分析優(yōu)化在線(xiàn)通道的穩(wěn)定性，保證用戶(hù)消息及時(shí)到達(dá)。

面臨哪些問(wèn)題

端內(nèi)長(zhǎng)連接中斷

在IM場(chǎng)景中，用戶(hù)與云端通信頻繁，且為了實(shí)現(xiàn)用戶(hù)的消息及時(shí)到達(dá)，往往采用云端下推消息的方式觸達(dá)用戶(hù)，所以用戶(hù)在線(xiàn)時(shí)設(shè)備與云端會(huì)維持一條TCP長(zhǎng)連接通道，可以更輕量級(jí)的與服務(wù)端進(jìn)行交互，現(xiàn)代IM即時(shí)通訊的下行消息都是通過(guò)長(zhǎng)連下發(fā)的，閑魚(yú)消息使用的是ACCS長(zhǎng)連接，ACCS是淘寶無(wú)線(xiàn)提供的全雙工、低延時(shí)、高安全的通道服務(wù)。但是由于用戶(hù)設(shè)備網(wǎng)絡(luò)狀態(tài)的不確定性，可能會(huì)發(fā)生各種各樣的網(wǎng)絡(luò)異常情況導(dǎo)致長(zhǎng)連接通道中斷，長(zhǎng)連接一旦意外中斷，就會(huì)導(dǎo)致用戶(hù)無(wú)法及時(shí)收到在線(xiàn)消息，所以我們需要盡可能及時(shí)的感知到長(zhǎng)連中斷并嘗試重連。

下推的消息未達(dá)

感知長(zhǎng)連中斷并重連只能在大多數(shù)時(shí)間保證長(zhǎng)連接的有效性，但是在長(zhǎng)連接無(wú)效或不穩(wěn)定期間下推的消息客戶(hù)端可能根本收不到，簡(jiǎn)單說(shuō)就是僅僅有重連機(jī)制無(wú)法保證下行消息必達(dá)，可能有以下場(chǎng)景導(dǎo)致下行消息失敗：

• 服務(wù)端發(fā)送下行消息時(shí)長(zhǎng)連暢通，消息在傳輸路上通道斷掉，客戶(hù)端無(wú)法收到
• 設(shè)備的在線(xiàn)狀態(tài)存在延遲，服務(wù)端下行消息時(shí)認(rèn)為設(shè)備在線(xiàn)，實(shí)際上設(shè)備已經(jīng)離線(xiàn)，無(wú)法收到
• 客戶(hù)端收到了下行消息，但端上后續(xù)處理失敗，比如落庫(kù)失敗，消息沒(méi)有成功展示給用戶(hù)

我們通過(guò)數(shù)據(jù)埋點(diǎn)統(tǒng)計(jì)得出，accs下行成功率在97%左右

有心急的同學(xué)就要問(wèn)了，丟了3%的消息嗎?并沒(méi)有，這3%的消息不會(huì)丟失，只是不保證及時(shí)觸達(dá)給用戶(hù)。我們的消息同步模型是推拉結(jié)合模式，在用戶(hù)拉取消息時(shí)會(huì)拉取到設(shè)備當(dāng)前位點(diǎn)與服務(wù)端最新位點(diǎn)的所有消息，accs下行失敗的消息會(huì)通過(guò)主動(dòng)拉模式獲取到，但客戶(hù)端主動(dòng)拉取消息的觸發(fā)時(shí)機(jī)有限，主要有以下幾個(gè)：

• 用戶(hù)冷啟動(dòng)app，主動(dòng)同步消息
• 用戶(hù)主動(dòng)下拉刷新
• app后臺(tái)切換前臺(tái)

收到一條推送消息，客戶(hù)端發(fā)現(xiàn)新消息的位點(diǎn)跟本地最新的位點(diǎn)有g(shù)ap，觸發(fā)同步

可見(jiàn)上述主動(dòng)同步消息的觸發(fā)很大程度上依賴(lài)用戶(hù)行為或者有沒(méi)有收到新消息，難以保證消息及時(shí)到達(dá)。如果是用戶(hù)高頻打開(kāi)的IM軟件，這樣也不會(huì)有太大的問(wèn)題，但是閑魚(yú)app的活躍度較低，有時(shí)候甚至依賴(lài)IM消息拉活，而且一條延遲的消息觸達(dá)可能導(dǎo)致用戶(hù)錯(cuò)過(guò)一筆交易，閑魚(yú)消息不允許有這樣的延遲發(fā)生。基于上述分析，我們先描述一個(gè)數(shù)據(jù)指標(biāo)來(lái)反映現(xiàn)狀，通過(guò)上面的描述可知，accs消息并不全都是推下來(lái)的，也可能是主動(dòng)拉下來(lái)的，如果是推，必定可以及時(shí)到達(dá)，如果是拉，則受限于用戶(hù)行為。拉的這部分消息，我們定義為accs消息補(bǔ)償?shù)竭_(dá)，然后計(jì)算accs消息補(bǔ)償?shù)竭_(dá)耗時(shí)，消息范圍限定為服務(wù)端accs成功下行但是客戶(hù)端通過(guò)主動(dòng)拉取同步到的消息，以往的版本這個(gè)數(shù)據(jù)在60分鐘左右。需要注意這個(gè)數(shù)據(jù)并不是消息觸達(dá)到用戶(hù)的耗時(shí)，因?yàn)槿绻诰€(xiàn)轉(zhuǎn)離線(xiàn)觸達(dá)，拉取到消息的時(shí)間取決于用戶(hù)行為(用戶(hù)何時(shí)打開(kāi)了app)，但這個(gè)數(shù)據(jù)也能大致反映在線(xiàn)消息的到達(dá)延遲狀況。

接下來(lái)本文將從長(zhǎng)連接的重連和未達(dá)消息重發(fā)兩個(gè)方面詳細(xì)講述我們是如何優(yōu)化在線(xiàn)通道穩(wěn)定性的。

長(zhǎng)連接重連

長(zhǎng)連接為什么會(huì)中斷?

百因必有果，我們先來(lái)分析下有哪些原因會(huì)導(dǎo)致連接中斷，可能有以下原因：

• 用戶(hù)設(shè)備斷網(wǎng)
• 設(shè)備發(fā)生了網(wǎng)絡(luò)切換
• 設(shè)備處于弱網(wǎng)環(huán)境，網(wǎng)絡(luò)不穩(wěn)定
• 設(shè)備網(wǎng)絡(luò)正常，TCP連接由于NAT超時(shí)導(dǎo)致連接被運(yùn)營(yíng)商中斷

如果是用戶(hù)操作導(dǎo)致網(wǎng)絡(luò)狀態(tài)變化的情況，會(huì)有網(wǎng)絡(luò)狀態(tài)變化事件通知，這種情況可以監(jiān)聽(tīng)事件并主動(dòng)嘗試重連，但現(xiàn)實(shí)中的大多數(shù)情況都是“意料之外”。那么如何有效感知到各種異常狀況呢?

心跳檢測(cè)

像大多數(shù)探活場(chǎng)景一樣，最有效的檢測(cè)手段就是心跳檢測(cè)，客戶(hù)端通過(guò)定時(shí)發(fā)送心跳包，可以感知到連接中斷，從及時(shí)性效果來(lái)看，心跳間隔越短越好，而頻繁的心跳檢測(cè)勢(shì)必會(huì)帶來(lái)用戶(hù)流量以及電量的損耗，所以我們的目標(biāo)是如何盡可能少的心跳檢測(cè)而又盡量及時(shí)地感知到長(zhǎng)連中斷的意外情況。

狀態(tài)機(jī)+消息心跳隊(duì)列：

在心跳協(xié)議設(shè)計(jì)上，要注意心跳包的核心目標(biāo)是檢測(cè)長(zhǎng)連通道是否暢通，客戶(hù)端主動(dòng)上行心跳包且能收到服務(wù)端回包，就認(rèn)為長(zhǎng)連通道健康，所以上行消息以及回包的數(shù)據(jù)包應(yīng)盡可能小，一般來(lái)說(shuō)，通過(guò)協(xié)議頭標(biāo)識(shí)心跳包及響應(yīng)即可

心跳策略

心跳策略是實(shí)現(xiàn)我們上述目標(biāo)的核心機(jī)制，但關(guān)于心跳策略的詳細(xì)設(shè)計(jì)甚至可以單獨(dú)寫(xiě)一篇文章，本文僅簡(jiǎn)單列舉幾種心跳策略，有興趣的同學(xué)可以閱讀文末推薦的文章繼續(xù)深入研究。

• 短心跳檢測(cè) 初始狀態(tài)連續(xù) ping 3次 收到 ack 后，可以認(rèn)為進(jìn)入穩(wěn)定狀態(tài)
• 常規(guī)固定時(shí)長(zhǎng)心跳(根據(jù)app狀態(tài)不同，頻率可調(diào)Mid+,Mid-, Long)
• 自適應(yīng)心跳 根據(jù)設(shè)備網(wǎng)絡(luò)狀態(tài)變化自動(dòng)適應(yīng)的心跳間隔
• 冗余心跳，app后臺(tái)切前臺(tái)，主動(dòng)心跳一次

消息ack與重發(fā)

為了解決上面的問(wèn)題，引入消息ack與重發(fā)機(jī)制，整體思路是客戶(hù)端在收到accs消息并處理成功后，給服務(wù)端回一個(gè)ack，服務(wù)端下行accs消息時(shí)將消息加入重試隊(duì)列，收到ack后更新消息到達(dá)狀態(tài)，并終止重試。

整體設(shè)計(jì)流程圖：

該方案的難點(diǎn)即重試處理器的實(shí)現(xiàn)設(shè)計(jì)，接下來(lái)我們將重點(diǎn)講述這部分的詳細(xì)設(shè)計(jì)

重試隊(duì)列存儲(chǔ)設(shè)計(jì)

我們采用阿里云表格存儲(chǔ)TimeLine模型來(lái)存儲(chǔ)下行消息的到達(dá)狀態(tài)，阿里云表格存儲(chǔ)是阿里云自研的多模型結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)，提供海量結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)以及快速的查詢(xún)和分析服務(wù)。表格存儲(chǔ)的分布式存儲(chǔ)和強(qiáng)大的索引引擎能夠支持PB級(jí)存儲(chǔ)、千萬(wàn)TPS以及毫秒級(jí)延遲的服務(wù)能力。而Timeline 模型是針對(duì)消息數(shù)據(jù)場(chǎng)景所設(shè)計(jì)的數(shù)據(jù)模型，它能滿(mǎn)足消息數(shù)據(jù)場(chǎng)景對(duì)消息保序、海量消息存儲(chǔ)、實(shí)時(shí)同步的特殊需求，在IM、Feed流等消息場(chǎng)景應(yīng)用廣泛。

我們給每個(gè)用戶(hù)設(shè)備定義一個(gè)TimeLine，timeline-id定義為userId_deviceId，sequenceId自定義為消息位點(diǎn)，存儲(chǔ)結(jié)構(gòu)如下：

每通過(guò)accs成功下行一條消息，則插入到接收用戶(hù)設(shè)備的TimeLine中，收到ack后根據(jù)消息id更新消息到達(dá)狀態(tài)，同時(shí)由于重試動(dòng)作只發(fā)生在下行消息后較短的一段時(shí)間內(nèi)，所以我們?cè)O(shè)置一個(gè)比較短的全局過(guò)期時(shí)間即可，避免數(shù)據(jù)膨脹。

延遲重試設(shè)計(jì)

• 每通過(guò)accs下發(fā)一條消息，先插入到Timeline中，初始狀態(tài)為未達(dá)，然后生產(chǎn)一條延遲N秒的延遲消息
• 每次消費(fèi)到延遲消息后，讀取tablestore中該消息的到達(dá)狀態(tài)，如到達(dá)則終止延遲，否則繼續(xù)
• 每次重試先判斷設(shè)備是否在線(xiàn)，如果設(shè)備不在線(xiàn)，轉(zhuǎn)發(fā)離線(xiàn)通道并終止重試，如果設(shè)備在線(xiàn)，則重推未到達(dá)的消息，并再次延遲N秒消費(fèi)
• 每條消息的重試生命周期中用的同一條延遲消息，最多重試消費(fèi)M次，超過(guò)次數(shù)不再重試并打日志埋點(diǎn)，后續(xù)可以監(jiān)控這種情況并基于這個(gè)數(shù)據(jù)進(jìn)行優(yōu)化

延遲重發(fā)策略

延遲重發(fā)策略是指在重發(fā)流程中，如何選擇合適的延遲時(shí)間來(lái)使得重發(fā)的效率最高。不同用戶(hù)在不同時(shí)間、地點(diǎn)所處的網(wǎng)絡(luò)環(huán)境差別較大，網(wǎng)絡(luò)恢復(fù)到穩(wěn)定態(tài)所需要的時(shí)間也有差異，需要選用合適的延遲策略來(lái)保證重發(fā)效率，最優(yōu)的延遲策略的目標(biāo)是在最短的時(shí)間內(nèi)，使用最少的重發(fā)次數(shù)將消息投遞成功。

固定延遲時(shí)間

要想找到最優(yōu)的延遲策略，必須從數(shù)據(jù)中通過(guò)分析得到答案，天馬行空的想象往往離實(shí)際相差甚遠(yuǎn)，我們先采用固定的延遲時(shí)間(10s)最大重試6次來(lái)分析一波數(shù)據(jù)

我們通過(guò)這組數(shù)據(jù)可以看到，有約85%的消息在40s內(nèi)重發(fā)可以投遞成功，還有12%的消息在達(dá)到最大重試次數(shù)后依舊沒(méi)有收到ack，在4次重試之后，第5次成功只有2.03%，第6次只有0.92%，繼續(xù)重發(fā)的收益已經(jīng)變得很低，6次以后還有部分消息沒(méi)有收到ack，這部分消息如果用固定延遲時(shí)間策略，性?xún)r(jià)比很低，頻繁重發(fā)浪費(fèi)系統(tǒng)資源，我們繼續(xù)改進(jìn)策略。

固定延遲+固定步長(zhǎng)遞增

考慮到部分用戶(hù)的網(wǎng)絡(luò)短時(shí)間無(wú)法恢復(fù)，頻繁的短間隔重發(fā)價(jià)值不大，我們采用4次固定短間隔延遲N秒后，之后每次延遲時(shí)間都是上一次延遲時(shí)間遞增固定步長(zhǎng)M秒的策略，直到收到ack、用戶(hù)設(shè)備離線(xiàn)或者達(dá)到了最大延遲時(shí)間MAX(N)。這種策略一定程度上可以解決固定延遲時(shí)間重發(fā)策略的問(wèn)題，但如果用戶(hù)短時(shí)間網(wǎng)絡(luò)無(wú)法恢復(fù)，每次重發(fā)都要重新遞增，也不是一種最優(yōu)解。

自適應(yīng)延遲

設(shè)計(jì)流程圖：

如上圖，我們最終衍生出了自適應(yīng)延遲策略，自適應(yīng)延遲是指根據(jù)用戶(hù)的網(wǎng)絡(luò)狀況，采取自動(dòng)調(diào)整的延遲時(shí)間，以期望達(dá)到最高的重發(fā)效率，新消息先通過(guò)4次固定N秒的短延遲來(lái)探測(cè)設(shè)備的網(wǎng)絡(luò)狀況，一旦網(wǎng)絡(luò)恢復(fù)，我們將設(shè)備的N值清空，設(shè)備N(xiāo)值是指根據(jù)上幾次重發(fā)經(jīng)驗(yàn)，當(dāng)前設(shè)備網(wǎng)絡(luò)能回復(fù)ack所需要的最短時(shí)間，默認(rèn)情況該值為空，代表用戶(hù)設(shè)備網(wǎng)絡(luò)正常。4次重發(fā)后依舊收不到ack，我們嘗試讀取設(shè)備N(xiāo)值，如果為空，則取初始值，以后每次延遲都遞增固定步長(zhǎng)M，并在重發(fā)后更新當(dāng)前設(shè)備的N值，直到消息收到ack或者達(dá)到了最大延遲時(shí)間MAX(N)。

新老版本兼容性

需要注意的是老版本的app是不會(huì)回ack的，如果下發(fā)給老版本設(shè)備的消息也加入重試隊(duì)列，那此類(lèi)消息將一直重試到最大次數(shù)才會(huì)終止，無(wú)端消耗資源，所以我們?cè)O(shè)計(jì)在accs長(zhǎng)連建立之后，客戶(hù)端主動(dòng)上行一條設(shè)備信息，其中包含app的版本號(hào)，服務(wù)端存儲(chǔ)一定時(shí)間，在將消息加入重試隊(duì)列之前，先校驗(yàn)接收者設(shè)備app的版本號(hào)，符合要求再加入重試隊(duì)列。

方案效果

消息重連重發(fā)方案上線(xiàn)后，我們上面定義的指標(biāo)accs補(bǔ)償?shù)竭_(dá)時(shí)間從60分鐘大幅降低至15分鐘，降幅達(dá)75%，從而印證了我們的技術(shù)分析，同時(shí)用戶(hù)有關(guān)消息延遲的輿情反饋每周不超過(guò)2個(gè)，可見(jiàn)消息重發(fā)機(jī)制對(duì)保證用戶(hù)消息及時(shí)到達(dá)成效顯著。

未來(lái)展望

消息在線(xiàn)通道穩(wěn)定性?xún)?yōu)化至此已告一段落，未來(lái)我們將繼續(xù)優(yōu)化閑魚(yú)消息的使用體驗(yàn)，包括基礎(chǔ)功能的完善以及基礎(chǔ)體驗(yàn)的提升。

• 基礎(chǔ)功能方面，我們?cè)诮诘陌姹局幸呀?jīng)支持了消息撤回、草稿功能，后續(xù)將逐步支持發(fā)送定位，會(huì)話(huà)分組、備注，消息搜索等功能;
• 基礎(chǔ)體驗(yàn)方面，我們對(duì)閑魚(yú)消息的UI樣式做了優(yōu)化升級(jí)，并優(yōu)化了app消息tab頁(yè)的cpu及內(nèi)存使用，后續(xù)將繼續(xù)從流量、電量、性能方面繼續(xù)優(yōu)化消息的使用體驗(yàn)。