融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制
本文由融云技術(shù)團(tuán)隊(duì)原創(chuàng)分享，原題“IM 消息同步機(jī)制全面解析”，為使文章更好理解，對(duì)內(nèi)容進(jìn)行了重新歸納和細(xì)節(jié)修訂。
1、內(nèi)容概述
即時(shí)通訊（IM）系統(tǒng)最基礎(chǔ)、最重要的是消息的及時(shí)性與準(zhǔn)確性，及時(shí)體現(xiàn)在延遲，準(zhǔn)確則具體表現(xiàn)為不丟、不重、不亂序。
綜合考慮業(yè)務(wù)場(chǎng)景、系統(tǒng)復(fù)雜度、網(wǎng)絡(luò)流量、終端能耗等，我們的億級(jí)分布式IM消息系統(tǒng)精心設(shè)計(jì)了消息收發(fā)機(jī)制，并不斷打磨優(yōu)化，形成了現(xiàn)在的消息可靠投遞機(jī)制。
整體思路就是：
1）客戶端、服務(wù)端共同配合，互相補(bǔ)充；
2）采用多重機(jī)制，從不同層面保障；
3）拆分上下行，分別處理。
本文根據(jù)融云億級(jí)IM消息系統(tǒng)的技術(shù)實(shí)踐，總結(jié)了分布式IM消息的可靠投遞機(jī)制，希望能為你的IM開發(fā)和知識(shí)學(xué)習(xí)起到拋磚引玉的作用。
學(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-3638-1-1.html）
2、推薦閱讀
以下是相關(guān)文章匯總，有興趣可以一并閱讀：
《零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？》
《零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？》
《零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？》
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》
《IM開發(fā)干貨分享：如何優(yōu)雅的實(shí)現(xiàn)大量離線消息的可靠投遞》
《理解IM消息“可靠性”和“一致性”問(wèn)題，以及解決方案探討》
《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《從客戶端的角度來(lái)談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》
《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》
《從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)》
《淺談移動(dòng)端IM的多點(diǎn)登錄和消息漫游原理》
《完全自已開發(fā)的IM該如何設(shè)計(jì)“失敗重試”機(jī)制？》
《IM開發(fā)干貨分享：我是如何解決大量離線消息導(dǎo)致客戶端卡頓的》
以下是融云技術(shù)團(tuán)隊(duì)分享的其它文章：
《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》
《融云技術(shù)分享：基于WebRTC的實(shí)時(shí)音視頻首幀顯示時(shí)間優(yōu)化實(shí)踐》
《融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路?；罴夹g(shù)實(shí)踐》
《即時(shí)通訊云融云CTO的創(chuàng)業(yè)經(jīng)驗(yàn)分享：技術(shù)創(chuàng)業(yè)，你真的準(zhǔn)備好了？》
3、客戶端與服務(wù)端消息交互整體原理
3.1 概述
一個(gè)完整的IM消息交互邏輯，通常會(huì)為兩段：
1）消息上行段：即由消息發(fā)送者通過(guò)IM實(shí)時(shí)通道發(fā)送給服務(wù)端；
2）消息下行段：由服務(wù)端按照一定的策略送達(dá)給最終的消息接收人。
3.2 消息上行段
消息上行段主要就是依賴IM的實(shí)時(shí)通道將消息傳遞給服務(wù)端。
這個(gè)階段的消息可靠投遞，需要從協(xié)議層進(jìn)行保證，協(xié)議層需要提供可靠、有序的雙向字節(jié)流傳輸，我們是通過(guò)自研的通信協(xié)議 RMTP（即 RongCloud Message Transfer Protocol）實(shí)現(xiàn)的。
客戶端與服務(wù)端之間使用長(zhǎng)連接，基于 RMTP 協(xié)議傳輸數(shù)據(jù)。
RMTP協(xié)議交互示意圖：
如上圖所示，協(xié)議層通過(guò) QoS、 ACK 等機(jī)制，保證IM消息上行段數(shù)據(jù)傳輸?shù)目煽啃浴?/p>
3.3 消息下行段
經(jīng)過(guò)總結(jié)，消息下行段主要有三種行為。
1）客戶端主動(dòng)拉取消息，主動(dòng)拉取有兩個(gè)觸發(fā)方式：
① 拉取離線消息：與 IM 服務(wù)新建立連接成功，用于獲取不在線的這段時(shí)間未收到的消息；
② 定時(shí)拉取消息：在客戶端最后收到消息后啟動(dòng)定時(shí)器，比如 3-5 分鐘執(zhí)行一次。主要有兩個(gè)目的，一個(gè)是用于防止因網(wǎng)絡(luò)、中間設(shè)備等不確定因素引起的通知送達(dá)失敗，服務(wù)端客戶端狀態(tài)不一致，一個(gè)是可通過(guò)本次請(qǐng)求，對(duì)業(yè)務(wù)層做狀態(tài)機(jī)?；睢?/p>
2）服務(wù)端主動(dòng)-發(fā)送消息（直發(fā)消息）：
這是在線消息發(fā)送機(jī)制之一，簡(jiǎn)單理解為服務(wù)端將消息內(nèi)容直接發(fā)送給客戶端，適用于消息頻率較低，并且持續(xù)交互，比如二人或者群內(nèi)的正常交流討論。
3）服務(wù)端主動(dòng)-發(fā)送通知（通知拉取）：
這是在線消息發(fā)送機(jī)制之一，簡(jiǎn)單理解為服務(wù)端給客戶端發(fā)送一個(gè)通知，通知包含時(shí)間戳等可作為排序索引的內(nèi)容，客戶端收到通知后，依據(jù)自身數(shù)據(jù)，對(duì)比通知內(nèi)時(shí)間戳，發(fā)起拉取消息的流程。
這種場(chǎng)景適用于較多消息傳遞：比如某人有很多大規(guī)模的群，每個(gè)群內(nèi)都有很多成員正在激烈討論。通過(guò)通知拉取機(jī)制，可以有效的減少客戶端服務(wù)端網(wǎng)絡(luò)交互次數(shù)，并且對(duì)多條消息進(jìn)行打包，提升有效數(shù)據(jù)載荷。既能保證時(shí)效，又能保證性能。
客戶端服務(wù)端下行段消息交互示意圖：
4、客戶端與服務(wù)端消息交互具體實(shí)現(xiàn)
正如上節(jié)所言，我們將消息的交互流程進(jìn)行了拆分：即拆分出上下行。
4.1 上行
在上行過(guò)程保證發(fā)送消息順序，為了保證消息有序， 最好的方式是按照 userId 區(qū)分，然后使用時(shí)間戳排序。那么分布式部署情況下，將用戶歸屬到固定的業(yè)務(wù)服務(wù)器上（PS：指的是同一賬號(hào)的不同端固定連接到相同的業(yè)務(wù)服務(wù)器上），會(huì)使得上行排序變得更容易。同時(shí)歸屬到同一個(gè)服務(wù)器，在多端維護(hù)時(shí)也更容易。
客戶端連接過(guò)程：
1）客戶端通過(guò) App server ，獲取到連接使用的 token；
2）客戶端使用 token 通過(guò)導(dǎo)航服務(wù)，獲取具體連接的 IM 接入服務(wù)器(CMP)，導(dǎo)航服務(wù)通過(guò) userId 計(jì)算接入服務(wù)器，然后下發(fā)，使得某一客戶端可以連接在同一臺(tái)接入服務(wù)器(CMP)。
示意圖如下：
小結(jié)一下就是：客戶端發(fā)出消息后，通過(guò)接入服務(wù)，按照 userId 投遞到指定消息服務(wù)器，生成消息 Id， 依據(jù)最后一條消息時(shí)間，確認(rèn)更新當(dāng)前消息的時(shí)間戳（如果存在相同時(shí)間戳則后延）。然后將時(shí)間戳，以及消息 Id，通過(guò) Ack 返回給客戶端 ; 然后對(duì)上行消息使用 userId + 時(shí)間戳進(jìn)行緩存以及持久化存儲(chǔ)，后續(xù)業(yè)務(wù)操作均使用此時(shí)間戳。
以上業(yè)務(wù)流程我們稱為上行流程，上行過(guò)程存儲(chǔ)的消息為發(fā)件箱消息。
PS：關(guān)于消息ID，需要補(bǔ)充說(shuō)明一下：
我們采用全局唯一的消息 ID 生成策略。保證消息可通過(guò) ID 進(jìn)行識(shí)別，排重。消息ID的結(jié)構(gòu)如下圖所示。
如何實(shí)現(xiàn)分布式場(chǎng)景下唯一 ID 生成，具體請(qǐng)閱讀：《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》。
4.2 下行
消息節(jié)點(diǎn)在處理完上行流程后，消息按照目標(biāo)用戶投遞到所在消息節(jié)點(diǎn)，進(jìn)入下行流程。
下行過(guò)程，按照目標(biāo) userId 以及本消息在上行過(guò)程中生成的時(shí)間戳，計(jì)算是否需要更新時(shí)間戳（正向）。
如果需要更新則對(duì)時(shí)間戳進(jìn)行加法操作，直到當(dāng)前用戶時(shí)間戳不重復(fù)。
如此處理后，目標(biāo)用戶的存儲(chǔ)以及客戶端接收到消息后的排重可以做到一致，并且可以做到同一個(gè)會(huì)話內(nèi)的時(shí)間戳是有序的。從而保證同一個(gè)接收用戶的消息不會(huì)出現(xiàn)亂序。
至此：我們已經(jīng)介紹完了消息的下行交互過(guò)程，消息下行過(guò)程中的具體實(shí)現(xiàn)方式并不簡(jiǎn)單，以下將詳細(xì)展開。
1）直發(fā)消息：
即服務(wù)端主動(dòng)發(fā)送（給目標(biāo)客戶端）的消息：
1）客戶端 SDK 依據(jù)本地存儲(chǔ)的最新消息時(shí)間戳判斷，用來(lái)做排序等邏輯；
2）對(duì)同一個(gè)用戶直發(fā)消息1條，其他轉(zhuǎn)通知。通知拉取時(shí)候客戶端選擇本地最新一條消息時(shí)間戳作為開始拉取時(shí)間；
3）在消息發(fā)送過(guò)程中，如果上一條消息發(fā)送流程未結(jié)束，下一條消息則不用直發(fā)(s_msg)，而是用通知(s_ntf)。
直發(fā)邏輯示意圖：
2）通知拉?。?/strong>
即服務(wù)端主動(dòng)發(fā)送通知（給目標(biāo)客戶端）：
1）服務(wù)端在通知體中攜帶當(dāng)前消息時(shí)間戳。投遞給客戶端；
2）客戶端收到通知后，比對(duì)本地消息時(shí)間戳，選擇是否發(fā)拉取消息信令；
3）服務(wù)端收到拉取消息信令后，以信令攜帶的時(shí)間戳為開始，查詢出消息列表(200 條或者 5M)，并給客戶端應(yīng)答；
4）客戶端收到后，給服務(wù)端 ack，服務(wù)端維護(hù)狀態(tài)；
5）客戶端拉取消息時(shí)使用的時(shí)間戳，是客戶端本地最新一條消息的時(shí)間戳。
示意圖：
在上圖中，3-7 步可能需要循環(huán)多次，有以下考慮：
a、客戶端一次收到的消息過(guò)多，應(yīng)答體積過(guò)于龐大，傳輸過(guò)程對(duì)網(wǎng)絡(luò)質(zhì)量要求更高， 因此按照數(shù)量以及消息體積分批次進(jìn)行；
b、一次拉取到的消息過(guò)多，客戶端處理會(huì)占用大量資源，可能會(huì)有卡頓等，體驗(yàn)較差。
3）服務(wù)端直發(fā)消息與通知拉取切換邏輯：
主要涉及到的是狀態(tài)機(jī)的更新。
下面示意圖集成直發(fā)消息與通知拉取過(guò)程針對(duì)狀態(tài)機(jī)的更新：
至此，消息收發(fā)的整個(gè)核心流程介紹完畢，余下的內(nèi)容將介紹多端在線的消息同步處理。
5、多端在線的消息同步
多端按照消息的上下行兩個(gè)階段，同樣區(qū)分為發(fā)送方多端同步以及接收方多端同步。
5.1 發(fā)送方多端同步
在前面客戶端連接 IM 服務(wù)過(guò)程中（見本文 4.1節(jié)），我們已經(jīng)將同一個(gè)用戶的多個(gè)客戶端匯聚在了同一臺(tái)服務(wù)，那么維護(hù)一個(gè) userId 的多端就會(huì)變得很簡(jiǎn)單。
具體邏輯是：
1）用戶多個(gè)終端鏈接成功后，發(fā)送一條消息，這個(gè)消息到達(dá) CMP(IM 接入服務(wù)) 后，CMP 做基礎(chǔ)檢查，然后獲此用戶的其他終端連接；
2）服務(wù)把客戶端上行的消息，封裝為服務(wù)端下行消息，直接投遞給用戶的其他客戶端。這樣完成了發(fā)送方的多端抄送，然后將這條消息投遞到 IM 服務(wù)。進(jìn)入正常發(fā)送投遞流程。
針對(duì)上面的第2）點(diǎn)，發(fā)送方的多端同步?jīng)]有經(jīng)過(guò) IM Server，這么做的好處是：
1）比較快速；
2）經(jīng)過(guò)越少的服務(wù)節(jié)點(diǎn)，出問(wèn)題的幾率越小。
5.2 接收方多端同步
具體邏輯是：
1）IM 服務(wù)收到消息后，先判斷接收方的投遞范圍，這個(gè)范圍指的是接收方用戶的哪些的終端要接收消息；
2）IM 服務(wù)將范圍以及當(dāng)前消息，發(fā)送到 CMP，CMP 依據(jù)范圍，匹配接收方的終端，然后投遞消息。
接收方多端消息同步范圍的應(yīng)用場(chǎng)景，一般都是針對(duì)所有終端。
但有一些特殊業(yè)務(wù)：比如我在 A 客戶端上，控制另外某個(gè)端的狀態(tài)，可能需要一些命令消息， 這時(shí)候需要這個(gè)作用范圍，針對(duì)性的投遞消息。
到此，我們分享完了有關(guān) IM 消息核心處理流程，通過(guò)層層拆解邏輯，提供了可靠的消息投遞機(jī)制。
附錄：更多IM架構(gòu)設(shè)計(jì)的文章
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡(jiǎn)述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》
《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》
《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐》
《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》
《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》
《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對(duì)2020年春節(jié)紅包的技術(shù)實(shí)踐》
《社交軟件紅包技術(shù)解密(十一)：解密微信紅包隨機(jī)算法(含代碼實(shí)現(xiàn))》
《即時(shí)通訊新手入門：一文讀懂什么是Nginx？它能否實(shí)現(xiàn)IM的負(fù)載均衡？》
《即時(shí)通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》
《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》
《從游擊隊(duì)到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》
《從游擊隊(duì)到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實(shí)踐總結(jié)》
《從游擊隊(duì)到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實(shí)踐》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫(kù)用NoSQL還是SQL？讀這篇就夠了！》
《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)（整理自現(xiàn)場(chǎng)演講，有配套PPT）》
《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》
《微信后臺(tái)基于時(shí)間序的新一代海量數(shù)據(jù)存儲(chǔ)架構(gòu)的設(shè)計(jì)實(shí)踐》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(九)：想開發(fā)IM集群？先搞懂什么是RPC！》
《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場(chǎng)景下的技術(shù)實(shí)踐》
《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等》
《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》
《從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)》
《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等》
《融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制》
>>?更多同類文章 ……
本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。
▲ 本文在公眾號(hào)上的鏈接是：點(diǎn)此進(jìn)入。同步發(fā)布鏈接是：http://www.52im.net/thread-3638-1-1.html
