本文由喜馬拉雅技術(shù)團(tuán)隊(duì)李乾坤原創(chuàng)，原題《推送系統(tǒng)實(shí)踐》，感謝作者的無私分享。

1、引言

1.1 什么是離線消息推送

對(duì)于IM的開發(fā)者來說，離線消息推送是再熟悉不過的需求了，比如下圖就是典型的IM離線消息通知效果。

1.2 Andriod端離線推送真心不易

移動(dòng)端離線消息推送涉及的端無非就是兩個(gè)——iOS端和Andriod端，iOS端沒什么好說的，APNs是唯一選項(xiàng)。

Andriod端比較奇葩（主要指國內(nèi)的手機(jī)），為了實(shí)現(xiàn)離線推送，各種?；詈诳萍紝映霾桓F，隨著?；铍y度的不斷升級(jí)，可以使用的?；钍侄我彩窃絹碓缴伲信d趣可以讀一讀我整理的下面這些文章，感受一下（文章是按時(shí)間順序，隨著Andriod系統(tǒng)?；铍y度的提升，不斷進(jìn)階的）。

• 《應(yīng)用?；罱K極總結(jié)(一)：Android6.0以下的雙進(jìn)程守護(hù)?；顚?shí)踐》

• 《應(yīng)用?；罱K極總結(jié)(二)：Android6.0及以上的?；顚?shí)踐(進(jìn)程防殺篇)》

• 《應(yīng)用?；罱K極總結(jié)(三)：Android6.0及以上的保活實(shí)踐(被殺復(fù)活篇)》

• 《Android P正式版即將到來：后臺(tái)應(yīng)用?；?、消息推送的真正噩夢(mèng)》

• 《全面盤點(diǎn)當(dāng)前Android后臺(tái)?；罘桨傅恼鎸?shí)運(yùn)行效果（截止2019年前）》

• 《2020年了，Android后臺(tái)?；钸€有戲嗎？看我如何優(yōu)雅的實(shí)現(xiàn)！》

• 《史上最強(qiáng)Android?；钏悸罚荷钊肫饰鲵v訊TIM的進(jìn)程永生技術(shù)》

• 《Android進(jìn)程永生技術(shù)終極揭密：進(jìn)程被殺底層原理、App應(yīng)對(duì)被殺技巧》

• 《Android?；顝娜腴T到放棄：乖乖引導(dǎo)用戶加白名單吧(附7大機(jī)型加白示例)》

上面這幾篇只是我整理的這方面的文章中的一部分，特別注意這最后一篇《Android?；顝娜腴T到放棄：乖乖引導(dǎo)用戶加白名單吧(附7大機(jī)型加白示例)》。是的，當(dāng)前Andriod系統(tǒng)對(duì)App自已保活的容忍度幾乎為0，所以那些曾今的保活手段在新版本系統(tǒng)里，幾乎統(tǒng)統(tǒng)都失效了。

自已做?；钜呀?jīng)沒戲了，保離線消息推送總歸是還得做。怎么辦？按照現(xiàn)時(shí)的最佳實(shí)踐，那就是對(duì)接種手機(jī)廠商的ROOM級(jí)推送通道。具體我就不在這里展開，有興趣的地可以詳讀《Android P正式版即將到來：后臺(tái)應(yīng)用?；?、消息推送的真正噩夢(mèng)》。

自已做?；?、自建推送通道的時(shí)代（這里當(dāng)然指的是Andriod端啦），離線消息推送這種系統(tǒng)的架構(gòu)設(shè)計(jì)相對(duì)簡(jiǎn)單，無非就是每臺(tái)終端計(jì)算出一個(gè)deviceID，服務(wù)端通過自建通道進(jìn)行消息透?jìng)?，就這么點(diǎn)事。

而在自建通道死翹翹，只能依賴廠商推送通道的如今，小米、華為、魅族、OPPO、vivo（這只是主流的幾家）等等，手機(jī)型號(hào)太多，各家的推送API、設(shè)計(jì)規(guī)范各不相同（別跟我提什么統(tǒng)一推送聯(lián)盟，那玩意兒我等他3年了——詳見《萬眾矚目的“統(tǒng)一推送聯(lián)盟”上場(chǎng)了》），這也直接導(dǎo)致先前的離線消息推送系統(tǒng)架構(gòu)設(shè)計(jì)必須重新設(shè)計(jì)，以適應(yīng)新時(shí)代的推送技術(shù)要求。

1.3 怎么設(shè)計(jì)合理呢

那么，針對(duì)不同廠商的ROOM級(jí)推送通道，我們的后臺(tái)推送架構(gòu)到底該怎么設(shè)計(jì)合理呢？

本文分享的離線消息推送系統(tǒng)設(shè)計(jì)并非專門針對(duì)IM產(chǎn)品，但無論業(yè)務(wù)層的差別有多少，大致的技術(shù)思路上都是相通的，希望借喜馬拉雅的這篇分享能給正在設(shè)計(jì)大用戶量的離線消息推送的你帶來些許啟發(fā)。

* 推薦閱讀：喜馬拉雅技術(shù)團(tuán)隊(duì)分享的另一篇《長連接網(wǎng)關(guān)技術(shù)專題(五)：喜馬拉雅自研億級(jí)API網(wǎng)關(guān)技術(shù)實(shí)踐》，有興趣也可以一并閱讀。

學(xué)習(xí)交流：

- 即時(shí)通訊/推送技術(shù)開發(fā)交流5群：215477170?[推薦]

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

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

（本文同步發(fā)布于：http://www.52im.net/thread-3621-1-1.html）

2、技術(shù)背景

首先介紹下在喜馬拉雅App中推送系統(tǒng)的作用，如下圖就是一個(gè)新聞業(yè)務(wù)的推送/通知。

離線推送主要就是在用戶不打開App的時(shí)候有一個(gè)手段觸達(dá)用戶，保持App的存在感，提高App的日活。

我們目前主要用推送的業(yè)務(wù)包括：

• 1）主播開播：公司有直播業(yè)務(wù)，主播在開直播的時(shí)候會(huì)給這個(gè)主播的所有粉絲發(fā)一個(gè)推送開播提醒

• 2）專輯更新：平臺(tái)上有非常多的專輯，專輯下面是一系列具體的聲音，比如一本兒小說是一個(gè)專輯，小說有很多章節(jié)，那么當(dāng)小說更新章節(jié)的時(shí)候給所有訂閱這個(gè)專輯的用戶發(fā)一個(gè)更新的提醒：

• 3）個(gè)性化、新聞業(yè)務(wù)等。

既然想給一個(gè)用戶發(fā)離線推送，系統(tǒng)就要跟這個(gè)用戶設(shè)備之間有一個(gè)聯(lián)系的通道。

做過這個(gè)的都知道：自建推送通道需要App常駐后臺(tái)（就是引言里提到的應(yīng)用“?；睢保謾C(jī)廠商因?yàn)槭‰姷仍蚱毡椴扇　凹みM(jìn)”的后臺(tái)進(jìn)程管理策略，導(dǎo)致自建通道質(zhì)量較差。目前通道一般是由“推送服務(wù)商”去維護(hù)，也就是說公司內(nèi)的推送系統(tǒng)并不直接給用戶發(fā)推送（就是上節(jié)內(nèi)容的這篇里提到的情況：《Android P正式版即將到來：后臺(tái)應(yīng)用?；?、消息推送的真正噩夢(mèng)》）。

這種情況下的離線推送流轉(zhuǎn)流程如下：

國內(nèi)的幾大廠商（小米、華為、魅族、OPPO、vivo等）都有自己官方的推送通道，但是每一家接口都不一樣，所以一些廠商比如小米、個(gè)推提供集成接口。發(fā)送時(shí)推送系統(tǒng)發(fā)給集成商，然后集成商根據(jù)具體的設(shè)備，發(fā)給具體的廠商推送通道，最終發(fā)給用戶。

給設(shè)備發(fā)推送的時(shí)候，必須說清楚你要發(fā)的是什么內(nèi)容：即title、message/body，還要指定給哪個(gè)設(shè)備發(fā)推送。

我們以token來標(biāo)識(shí)一個(gè)設(shè)備， 在不同的場(chǎng)景下token的含義是不一樣的，公司內(nèi)部一般用uid或者deviceId標(biāo)識(shí)一個(gè)設(shè)備，對(duì)于集成商、不同的廠商也有自己對(duì)設(shè)備的唯一“編號(hào)”，所以公司內(nèi)部的推送服務(wù)，要負(fù)責(zé)進(jìn)行uid、deviceId到集成商token 的轉(zhuǎn)換。

3、整體架構(gòu)設(shè)計(jì)

如上圖所示，推送系統(tǒng)整體上是一個(gè)基于隊(duì)列的流式處理系統(tǒng)。

上圖右側(cè)：是主鏈路，各個(gè)業(yè)務(wù)方通過推送接口給推送系統(tǒng)發(fā)推送，推送接口會(huì)把數(shù)據(jù)發(fā)到一個(gè)隊(duì)列，由轉(zhuǎn)換和過濾服務(wù)消費(fèi)。轉(zhuǎn)換就是上文說的uid/deviceId到token的轉(zhuǎn)換，過濾下文專門講，轉(zhuǎn)換過濾處理后發(fā)給發(fā)送模塊，最終給到集成商接口。

App 啟動(dòng)時(shí)：會(huì)向服務(wù)端發(fā)送綁定請(qǐng)求，上報(bào)uid/deviceId與token的綁定關(guān)系。當(dāng)卸載/重裝App等導(dǎo)致token失效時(shí)，集成商通過http回調(diào)告知推送系統(tǒng)。各個(gè)組件都會(huì)通過kafka 發(fā)送流水到公司的xstream 實(shí)時(shí)流處理集群，聚合數(shù)據(jù)并落盤到mysql，最終由grafana提供各種報(bào)表展示。

4、業(yè)務(wù)過濾機(jī)制設(shè)計(jì)

各個(gè)業(yè)務(wù)方可以無腦給用戶發(fā)推送，但推送系統(tǒng)要有節(jié)制，因此要對(duì)業(yè)務(wù)消息有選擇的過濾。

過濾機(jī)制的設(shè)計(jì)包括以下幾點(diǎn)（按支持的先后順序）：

• 1）用戶開關(guān)：App支持配置用戶開關(guān)，若用戶關(guān)閉了推送，則不向用戶設(shè)備發(fā)推送；

• 2）文案排重：一個(gè)用戶不能收到重復(fù)的文案，用于防止上游業(yè)務(wù)方發(fā)送邏輯出錯(cuò)；

• 3）頻率控制：每一個(gè)業(yè)務(wù)對(duì)應(yīng)一個(gè)msg_type，設(shè)定xx時(shí)間內(nèi)最多發(fā)xx條推送；

• 4）靜默時(shí)間：每天xx點(diǎn)到xx點(diǎn)不給用戶發(fā)推送，以免打擾用戶休息。

• 5）分級(jí)管理：從用戶和消息兩維度進(jìn)行分級(jí)控制。

針對(duì)第5點(diǎn)，具體來說就是：

• 1）每一個(gè)msg/msg_type有一個(gè)level，給重要/高level業(yè)務(wù)更多發(fā)送機(jī)會(huì)；

• 2）當(dāng)用戶一天收到xx條推送時(shí)，不是重要的消息就不再發(fā)給這些用戶。

5、分庫分表下的多維查詢問題

很多時(shí)候，設(shè)計(jì)都是基于理論和經(jīng)驗(yàn)，但實(shí)操時(shí)，總會(huì)遇到各種具體的問題。

喜馬拉雅現(xiàn)在已經(jīng)有6億+用戶，對(duì)應(yīng)的推送系統(tǒng)的設(shè)備表（記錄uid/deviceId到token的映射）也有類似的量級(jí)，所以對(duì)設(shè)備表進(jìn)行了分庫分表，以?deviceId?為分表列。

但實(shí)際上：經(jīng)常有根據(jù)?uid/token?的查詢需求，因此還需要建立以?uid/token?到?deviceId?的映射關(guān)系。因?yàn)閡id 查詢的場(chǎng)景也很頻繁，因此uid副表也擁有和主表同樣的字段。

因?yàn)槊刻鞎?huì)進(jìn)行一兩次全局推，且針對(duì)沉默用戶（即不常使用App的用戶）也有專門的推送，存儲(chǔ)方面實(shí)際上不存在“熱點(diǎn)”，雖然使用了緩存，但作用很有限，且占用空間巨大。

多分表以及緩存導(dǎo)致數(shù)據(jù)存在三四個(gè)副本，不同邏輯使用不同副本，經(jīng)常出現(xiàn)不一致問題（追求一致則影響性能）， 查詢代碼非常復(fù)雜且性能較低。

最終我們選擇了將設(shè)備數(shù)據(jù)存儲(chǔ)在tidb上，在性能夠用的前提下，大大簡(jiǎn)化了代碼。

6、特殊業(yè)務(wù)的時(shí)效性問題

6.1 基本概念

推送系統(tǒng)是基于隊(duì)列的，“先到先推”。大部分業(yè)務(wù)不要求很高的實(shí)時(shí)性，但直播業(yè)務(wù)要求半個(gè)小時(shí)送達(dá)，新聞業(yè)務(wù)更是“欲求不滿”，越快越好。

若進(jìn)行新聞推送時(shí)：隊(duì)列中有巨量的“專輯更新”推送等待處理，則專輯更新業(yè)務(wù)會(huì)嚴(yán)重干擾新聞業(yè)務(wù)的送達(dá)。

6.2 這是隔離問題？

一開始我們認(rèn)為這是一個(gè)隔離問題：比如10個(gè)消費(fèi)節(jié)點(diǎn)，3個(gè)專門負(fù)責(zé)高時(shí)效性業(yè)務(wù)、7個(gè)節(jié)點(diǎn)負(fù)責(zé)一般業(yè)務(wù)。當(dāng)時(shí)隊(duì)列用的是rabbitmq，為此改造了 spring-rabbit 支持根據(jù)msytype將消息路由到特定節(jié)點(diǎn)。

該方案有以下缺點(diǎn)：

• 1）總有一些機(jī)器很忙的時(shí)候，另一些機(jī)器在“袖手旁觀”；

• 2）新增業(yè)務(wù)時(shí)，需要額外配置msgType到消費(fèi)節(jié)點(diǎn)的映射關(guān)系，維護(hù)成本較高；

• 3）rabbitmq基于內(nèi)存實(shí)現(xiàn)，推送瞬時(shí)高峰時(shí)占用內(nèi)存較大，進(jìn)而引發(fā)rabbitmq 不穩(wěn)定。

6.3 其實(shí)是個(gè)優(yōu)先級(jí)問題

后來我們覺察到這是一個(gè)優(yōu)先級(jí)問題：高優(yōu)先級(jí)業(yè)務(wù)/消息可以插隊(duì)，于是封裝kafka支持優(yōu)先級(jí)，比較好的解決了隔離性方案帶來的問題。具體實(shí)現(xiàn)是建立多個(gè)topic，一個(gè)topic代表一個(gè)優(yōu)先級(jí)，封裝kafka主要是封裝消費(fèi)端的邏輯（即構(gòu)造一個(gè)PriorityConsumer）。

備注：為描述簡(jiǎn)單，本文使用?consumer.poll(num)?來描述使用?consumer?拉取?num?個(gè)消息，與真實(shí) kafka api 不一致，請(qǐng)知悉。

PriorityConsumer實(shí)現(xiàn)有三種方案，以下分別闡述。

1）poll到內(nèi)存后重新排序：java 有現(xiàn)成的基于內(nèi)存的優(yōu)先級(jí)隊(duì)列PriorityQueue 或PriorityBlockingQueue，kafka consumer 正常消費(fèi)，并將poll 到的數(shù)據(jù)重新push到優(yōu)先級(jí)隊(duì)列。

• 1.1）如果使用有界隊(duì)列，隊(duì)列打滿后，后面的消息優(yōu)先級(jí)再高也put 不進(jìn)去，失去“插隊(duì)”效果；

• 1.2）如果使用無界隊(duì)列，本來應(yīng)堆在kafka上的消息都會(huì)堆到內(nèi)存里，OOM的風(fēng)險(xiǎn)很大。

2）先拉取高優(yōu)先級(jí)topic的數(shù)據(jù)：只要有就一直消費(fèi)，直到?jīng)]有數(shù)據(jù)再消費(fèi)低一級(jí)topic。消費(fèi)低一級(jí)topic的過程中，如果發(fā)現(xiàn)有高一級(jí)topic消息到來，則轉(zhuǎn)向消費(fèi)高優(yōu)先級(jí)消息。

該方案實(shí)現(xiàn)較為復(fù)雜，且在晚高峰等推送密集的時(shí)間段，可能會(huì)導(dǎo)致低優(yōu)先級(jí)業(yè)務(wù)完全失去推送機(jī)會(huì)。

3）優(yōu)先級(jí)從高到低，循環(huán)拉取數(shù)據(jù)：

一次循環(huán)的邏輯為：

consumer-1.poll(topic1-num);

cosumer-i.poll(topic-i-num);

consumer-max.priority.poll(topic-max.priority-num)

如果topic1-num=topic-i-num=topic-max.priority-num，則該方案是沒有優(yōu)先級(jí)效果的。topic1-num 可以視為權(quán)重，我們約定：topic-高-num=2 * topic-低-num，同一時(shí)刻所有topic 都會(huì)被消費(fèi)，通過一次消費(fèi)數(shù)量的多少來變相實(shí)現(xiàn)“插隊(duì)效果”。具體細(xì)節(jié)上還借鑒了“滑動(dòng)窗口”策略來優(yōu)化某個(gè)優(yōu)先級(jí)的topic 長期沒有消息時(shí)總的消費(fèi)性能。

從中我們可以看到，時(shí)效問題先是被理解為一個(gè)隔離問題，后被視為優(yōu)先級(jí)問題，最終轉(zhuǎn)化為了一個(gè)權(quán)重問題。

7、過濾機(jī)制的存儲(chǔ)和性能問題

在我們的架構(gòu)中，影響推送發(fā)送速度的主要就是tidb查詢和過濾邏輯，過濾機(jī)制又分為存儲(chǔ)和性能兩個(gè)問題。

這里我們以xx業(yè)務(wù)頻控限制“一個(gè)小時(shí)最多發(fā)送一條”為例來進(jìn)行分析。

第一版實(shí)現(xiàn)時(shí)：redis kv 結(jié)構(gòu)為?<deviceId_msgtype,已發(fā)送推送數(shù)量>。

頻控實(shí)現(xiàn)邏輯為：

• 1）發(fā)送時(shí)，incr key，發(fā)送次數(shù)加1；

• 2）如果超限（incr命令返回值>發(fā)送次數(shù)上限），則不推送；

• 3）若未超限且返回值為1，說明在msgtype頻控周期內(nèi)第一次向該deviceId發(fā)消息，需expire key設(shè)置過期時(shí)間（等于頻控周期）。

上述方案有以下缺點(diǎn)：

• 1）目前公司有60+推送業(yè)務(wù)， 6億+ deviceId，一共6億*60個(gè)key ，占用空間巨大；

• 2）很多時(shí)候，處理一個(gè)deviceId需要2條指令：incr+expire。

為此，我們的解決方法是：

• 1）使用pika（基于磁盤的redis）替換redis，磁盤空間可以滿足存儲(chǔ)需求；

• 2）委托系統(tǒng)架構(gòu)組擴(kuò)充了redis協(xié)議，支持新結(jié)構(gòu)ehash。

ehash基于redis hash修改，是一個(gè)兩級(jí)map <key,field,value>，除了key 可以設(shè)置有效期外，field也可以支持有效期，且支持有條件的設(shè)置有效期。

頻控?cái)?shù)據(jù)的存儲(chǔ)結(jié)構(gòu)由<deviceId_msgtype,value>變?yōu)?<deviceId,msgtype,value>，這樣對(duì)于多個(gè)msgtype，deviceId只存一次，節(jié)省了占用空間。

incr 和 expire 合并為1條指令：incr(key,filed,expire)，減少了一次網(wǎng)絡(luò)通信：

• 1）當(dāng)field未設(shè)置有效期時(shí)，則為其設(shè)置有效期；

• 2）當(dāng)field還未過期時(shí)，則忽略有效期參數(shù)。

因?yàn)橥扑拖到y(tǒng)重度使用?incr?指令，可以視為一條寫指令，大部分場(chǎng)景還用了pipeline?來實(shí)現(xiàn)批量寫的效果，我們委托系統(tǒng)架構(gòu)組小伙伴專門優(yōu)化了pika?的寫入性能，支持“寫模式”（優(yōu)化了寫場(chǎng)景下的相關(guān)參數(shù)），qps達(dá)到10w以上。

ehash結(jié)構(gòu)在流水記錄時(shí)也發(fā)揮了重要作用，比如<deviceId,msgId,100001002>，其中?100001002?是我們約定的一個(gè)數(shù)據(jù)格式示例值，前中后三個(gè)部分（每個(gè)部分占3位）分別表示了某個(gè)消息（msgId）針對(duì)deviceId的發(fā)送、接收和點(diǎn)擊詳情，比如頭3位“100”表示因發(fā)送時(shí)處于靜默時(shí)間段所以發(fā)送失敗。

附錄：更多消息推送技術(shù)文章

《iOS的推送服務(wù)APNs詳解：設(shè)計(jì)思路、技術(shù)原理及缺陷等》

《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》

《Android端消息推送總結(jié)：實(shí)現(xiàn)原理、心跳保活、遇到的問題等》

《掃盲貼：認(rèn)識(shí)MQTT通信協(xié)議》

《一個(gè)基于MQTT通信協(xié)議的完整Android推送Demo》

《IBM技術(shù)經(jīng)理訪談：MQTT協(xié)議的制定歷程、發(fā)展現(xiàn)狀等》

《求教android消息推送：GCM、XMPP、MQTT三種方案的優(yōu)劣》

《移動(dòng)端實(shí)時(shí)消息推送技術(shù)淺析》

《掃盲貼：淺談iOS和Android后臺(tái)實(shí)時(shí)消息推送的原理和區(qū)別》

《絕對(duì)干貨：基于Netty實(shí)現(xiàn)海量接入的推送服務(wù)技術(shù)要點(diǎn)》

《移動(dòng)端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》

《為何微信、QQ這樣的IM工具不使用GCM服務(wù)推送消息？》

《極光推送系統(tǒng)大規(guī)模高并發(fā)架構(gòu)的技術(shù)實(shí)踐分享》

《從HTTP到MQTT：一個(gè)基于位置服務(wù)的App數(shù)據(jù)通信實(shí)踐概述》

《魅族2500萬長連接的實(shí)時(shí)消息推送架構(gòu)的技術(shù)實(shí)踐分享》

《專訪魅族架構(gòu)師：海量長連接的實(shí)時(shí)消息推送系統(tǒng)的心得體會(huì)》

《深入的聊聊Android消息推送這件小事》

《基于WebSocket實(shí)現(xiàn)Hybrid移動(dòng)應(yīng)用的消息推送實(shí)踐(含代碼示例)》

《一個(gè)基于長連接的安全可擴(kuò)展的訂閱/推送服務(wù)實(shí)現(xiàn)思路》

《實(shí)踐分享：如何構(gòu)建一套高可用的移動(dòng)端消息推送系統(tǒng)？》

《Go語言構(gòu)建千萬級(jí)在線的高并發(fā)消息推送系統(tǒng)實(shí)踐(來自360公司)》

《騰訊信鴿技術(shù)分享：百億級(jí)實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》

《百萬在線的美拍直播彈幕系統(tǒng)的實(shí)時(shí)推送技術(shù)實(shí)踐之路》

《京東京麥商家開放平臺(tái)的消息推送架構(gòu)演進(jìn)之路》

《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》

《基于APNs最新HTTP/2接口實(shí)現(xiàn)iOS的高性能消息推送(服務(wù)端篇)》

《解密“達(dá)達(dá)-京東到家”的訂單即時(shí)派發(fā)技術(shù)原理和實(shí)踐》

《技術(shù)干貨：從零開始，教你設(shè)計(jì)一個(gè)百萬級(jí)的消息推送系統(tǒng)》

《長連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實(shí)時(shí)推送網(wǎng)關(guān)技術(shù)實(shí)踐》

《喜馬拉雅億級(jí)用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)踐》

>>?更多同類文章 ……

本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。

▲ 本文在公眾號(hào)上的鏈接是：點(diǎn)此進(jìn)入。同步發(fā)布鏈接是：http://www.52im.net/thread-3621-1-1.html