本文由位元組跳動技術團隊開發工程師王浩分享，有較多修訂。
1、引言
對於移動網際網路時代的使用者來說，短視訊應用再也不是看看視訊就完事，尤其抖音這種頭部應用，已經是除了傳統IM即時通訊軟體以外的新型社交產品了。
對於中國人一年一度最重的節日——春節來說，紅包是必不可少的節日特定社交元素，而抖音自然不會被錯過。在2022年的春節活動期間，抖音將視訊和春節紅包相結合，使用者可以通過拍視訊發紅包的方式來給粉絲和好友送祝福。
本文將要分享的是春節期間海量紅包社交活動為抖音所帶來的各種技術挑戰，以及抖音技術團隊是如何在實踐中一一解決這些問題的。
學習交流：
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架原始碼：https://github.com/JackJiang2...（備用地址點此）
（本文已同步釋出於：http://www.52im.net/thread-39...）
2、系列文章
《社交軟體紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟體紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟體紅包技術解密(三)：微信搖一搖紅包雨背後的技術細節》
《社交軟體紅包技術解密(四)：微信紅包系統是如何應對高併發的》
《社交軟體紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟體紅包技術解密(六)：微信紅包系統的儲存層架構演進實踐》
《社交軟體紅包技術解密(七)：支付寶紅包的海量高併發技術實踐》
《社交軟體紅包技術解密(八)：全面解密微博紅包技術方案》
《社交軟體紅包技術解密(九)：談談手Q春節紅包的設計、容災、運維、架構等》
《社交軟體紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐》
《社交軟體紅包技術解密(十一)：最全解密微信紅包隨機演算法(含演示程式碼)》
《社交軟體紅包技術解密(十二)：解密抖音春節紅包背後的技術設計與實踐》（* 本文）
3、先看看紅包業務玩法
抖音的整個紅包活動玩法分為 B2C 和 C2C 兩種玩法，下面對這兩個玩法的流程簡單介紹下，也方便讀者理解後續的技術問題和解決思路。
3.1 B2C 紅包
在 B2C 紅包玩法中，使用者需要先來抖音或者抖 Lite 參加春節紅包雨活動，有一定概率在春節紅包雨活動中獲得紅包補貼。
使用者可以在獲得補貼後直接跳轉到相機頁面，或者在之後拍攝視訊跳轉到相機頁面，在相機頁面使用者拍攝完視訊後會看到一個紅包掛件，在掛件中可以看到已發放補貼。
使用者選擇補貼後點選下一步完成投稿後即可完成視訊紅包的發放。
如上圖所示，從左至左：“圖1”是春節紅包雨活動、“圖 2”是紅包補貼 、“圖 3”是紅包掛件、“圖4”是B2C的紅包傳送 tab 頁。
3.2 C2C 紅包
在 C2C 紅包玩法中，使用者拍攝視訊點選掛件，填寫紅包的金額和個數資訊，選擇紅包的領取範圍後，點選傳送紅包會拉起收銀臺，使用者支付完成後點選下一步釋出視訊，即可完成 C2C 紅包的發放。
如上圖所示，從左至左：“圖1”是C2C 紅包傳送 Tab 頁 、“圖2”是支付介面、“圖3”是紅包支付後掛件展示。
3.3 紅包領取
B2C 和 C2C 紅包的領取流程都是一樣的。
使用者在抖音刷視訊遇到有視訊紅包的視訊時，視訊下方有個領取紅包按鈕，使用者點選紅包領取，會彈出到紅包封面。
使用者點選紅包封面的開紅包後即可領取紅包，領取成功後會顯示領取結果彈窗，在領取結果中使用者可以看領取金額，以及跳轉到領取詳情頁，在領取詳情頁中可以看到這個紅包其他使用者的領取手氣。
如上圖所示，從左至左：“圖1”是紅包視訊、“圖2”是紅包封面、“圖3”是紅包領取結果、“圖4”是紅包領取詳情。
最後，C2C視訊紅包有個推廣視訊，大家可以更形象地瞭解下整體操作流程：（點選下方視訊可以播放 ▼）
4、技術挑戰
4.1 通用紅包系統的設計問題
在上節中有提到，本次春節活動（指的是2022年春節）需要同時支援 B2C 和 C2C 兩種型別的紅包。
這兩個型別的紅包既有一些相似的業務，也有很多不同的業務。
在相同點上：他們都包括紅包的發放和領取這兩個操作。在不同點上：比如 B2C 的紅包發放需要通過使用補貼來傳送，而 C2C 的紅包發放需要使用者去完成支付。B2C 的紅包使用者領取後需要去提現，而 C2C 的紅包使用者領取後直接到零錢。
因此需要設計一個通用的紅包系統來支援多種紅包型別。
另外：對於紅包系統本身而言，除了發領紅包外，還涉及到一些紅包資訊的查詢，以及各種狀態機的推進，這些功能模組之間如何劃分也是需要考慮的一個點。
4.2 大流量補貼的發放處理問題
前面提到過：B2C 紅包玩法會先進行補貼的發放。在春節活動期間，每場紅包雨都會有大量的使用者進入參與，如果將這些流量直接打到資料庫，將需要大量的資料庫資源。而春節期間資料庫的資源是非常稀缺的，如何減少這部分的資源消耗也是一個需要考慮的問題。
4.3 紅包領取方案的選型問題
在紅包業務中，領取是一個高頻的操作。
在領取方式的設計中，需要業務場景考慮一個紅包是否會被多個使用者同時領取。多個使用者同時去領取同一個紅包可能會導致熱點賬戶問題，成為系統效能的瓶頸。
解決熱點賬戶問題也有多個方案，我們需要結合視訊紅包的業務場景特點來選取合適的方案。
4.4 穩定性容災問題
在本次春節活動中，包括 B2C 和 C2C 兩種業務流程，其中每個業務流量鏈路都依賴很多的下游服務和基礎服務。
在這種大型活動中，如果出現黑天鵝事件時，如何快速止損，減少對系統的整體影響，是一個必須要考慮的問題。
4.5 資金安全保證問題
在春節活動期間，B2C 會發放大量的紅包補貼，如果補貼發生超發，或者補貼的核銷出現問題，一個補貼被多次核銷，將會造成大量的資損。
另外 C2C 也涉及到使用者的資金流入流出，如果使用者領取紅包後如果發現錢變少了，也可能會造成大量的客訴和資損。
因此資金安全這塊需要做好充足的準備。
4.6 紅包系統的壓測問題
在傳統的壓測方式中，我們一般會對某個大流量介面進行壓測從而得到系統的瓶頸。
然而在紅包系統中，使用者的發領和查都是同時進行的，並且這幾個介面之間也是相互依賴的，比如需要先發紅包，有了紅包後才能觸發多個人的領取，領取完成後才可以檢視領取詳情。
如果使用傳統的單介面的壓測方式，首先 mock 資料會非常困難。和支付相應的壓測資料因為涉及實名還需要特殊生成，而且單個介面單個介面的壓測很難得到系統的真實瓶頸。
因此如何對系統進行全鏈路的壓測從而得到系統準確的瓶頸也是我們需要解決的一個問題。
認清了我們要面臨的技術挑戰和技術難題之後，接下來將分享我們是如何在實踐中一一解決這些問題的。
5、通用紅包系統的設計實踐
對於紅包系統，核心包括三個操作：
1）紅包傳送；
2）紅包的領取；
3）未領取紅包的退款。
另外：我們還會需要去查一些紅包的資訊和領取的資訊等。對於傳送、領取和退款這三個核心操作，我們需要對它們的狀態進行一個維護。同時在我們的業務場景中，還存在 B2C 特有的補貼的發放，我們也需要維護補貼的狀態。
在上面初步介紹紅包系統後，可以看到紅包的幾個功能模組：
1）發放；
2）領取；
3）退款；
4）補貼發放；
5）各種資訊查詢；
6）狀態機的維護等。
對紅包的功能進行梳理後，我們開始對紅包的模組進行劃分。
模組劃分原則：
1）功能內聚，每個系統只處理一個任務（方便之後系統的開發和迭代，以及問題的排查）；
2）API 閘道器層只進行簡單的 proxy 處理；
3）非同步任務拆解；
4）讀寫分離，將紅包的核心操作和紅包的查詢分成兩個服務。
模組劃分結果：
1）紅包閘道器服務：HTTP API 閘道器，對外對接客戶端和 h5，對內封裝各個系統 rpc 介面，限流，許可權控制、降級等功能；
2）紅包核心服務：主要承載紅包核心功能，包括紅包的發放、領取、退款，以及紅包補貼的發放，維護紅包狀態機，紅包的狀態推進；
3）紅包查詢服務：主要承載紅包查詢功能，包括紅包詳情、紅包傳送狀態、紅包領取狀態、紅包領取詳情、紅包補貼資訊；
4）紅包非同步服務：主要承載紅包非同步任務，保證狀態機的流轉，包括紅包的轉賬，紅包的退款，以及紅包補貼的狀態推進；
5）紅包基礎服務：主要承載紅包各個系統的公共呼叫，例如對 DB，redis、tcc 的操作，公共常量和工具類，相當於紅包的基礎工具包；
6）紅包對賬服務：主要承載紅包和財經的對賬邏輯，按天和財經對賬。
最後整個視訊紅包的系統架構如圖所示：
6、大流量補貼的發放處理實踐
6.1 同步獎勵發放
在紅包補貼發放鏈路流程中，為了應對春節的大流量，整個鏈路流程也經歷過幾次方案的迭代。
在最初的方案設計中，我們是按照同步的補貼發放流程來處理的，上游鏈路呼叫紅包系統介面發券，發券成功後使用者感知到券發放成功，可以使用該券來發放紅包。
最初方案的整體流程如下圖：
上面方案的一個問題是在春節活動期間，整個鏈路都需要能扛住活動期間的總流量，而且最終流量都會打到資料庫，而資料庫的資源在春節期間也是比較緊缺的。
6.2 非同步獎勵發放
為了解決同步獎勵發放的問題，我們將整體流程改為通過 MQ 進行削峰，從而降低下游的流量壓力。
相當於是從同步改為非同步，使用者參與活動後會先下發一個加密 Token 給客戶端，用於客戶端的展示以及和服務端的互動處理。
活動非同步發券方案如下圖：
這樣算是解決了大流量的問題，但是相應地引入了其他的問題。。。
在最初方案中：使用者的紅包補貼都會先在紅包系統中落庫，後續使用者對補貼的查詢和核銷我們都能在紅包資料庫中找到對應的記錄。
但是在非同步的方式中：整個補貼的入賬預估需要 10min，而使用者在 APP 介面感知到發券後可能馬上就會開始使用用補貼來發放視訊紅包，或者會去紅包掛件檢視自己已經領取的紅包補貼，而此時補貼還未在紅包系統中入賬。
6.3 最終方案
為了解決上面問題，我們對紅包補貼的視訊紅包發放和紅包補貼查詢的整個邏輯進行了修改。即在使用者使用紅包補貼進行視訊紅包發放時，我們會先對該補貼進行一個入庫操作，入庫成功後才可以用這個補貼進行紅包發放。
另外對於查詢介面：我們無法感知到所有補貼是否完全入賬，因此每次查詢時我們都需要去獎勵發放端查詢全量的 Token 列表。同時我們還需要查詢出資料庫中使用者的補貼，對這兩部分資料進行一次 merge 操作，才能得到全量的補貼列表。
在上面的流程中：為了解決 MQ 非同步會有延遲的問題，我們在使用者進行請求時主動地進行入賬，而使用者主動的操作包括使用補貼發放紅包和查詢補貼。
我們為什麼只在補貼發放紅包時入賬而在查詢補貼時不入賬呢？
因為使用者的查詢行為是一個高頻行為，同時涉及到批量的操作，在操作 DB 前我們無法感知該補貼是否入賬，所以會涉及到 DB 的批量處理，甚至使用者每次來查詢時我們都需要重複這個操作，會導致大量的 DB 資源浪費。
而補貼的發放時入賬則是一個低頻的，單個補貼的操作，我們只需要在使用者核銷時入賬即可，這樣可以大量減輕資料庫的壓力，節省資料庫資源。
7、紅包領取方案的選型實踐
在視訊紅包領取的技術方案中，我們也有一些方案的選擇和思考，這裡和大家分享下。
7.1 悲觀鎖方案
如上圖所示：也是最常見的思路（我們稱為方案一），在使用者領取時對資料庫的紅包進行加鎖，然後扣減金額，然後釋放鎖完成整個紅包領取。
這個方案的優點是清晰明瞭，但是這種方案的問題會導致多個使用者同時來領取紅包時，會造成資料庫行鎖的衝突，需要排隊等待。
當排隊請求過多時會造成資料庫連結的浪費，影響整體系統的效能。同時在上游長時間未收到反饋導致超時，使用者側可能會不停重試，導致整體資料庫連結被耗盡，從而導致系統崩潰。
7.2 紅包預拆分方案
方案一的問題是多個用同時領取會造成鎖衝突，不過解鎖鎖衝突可以通過拆分的方式，來將鎖化成更細的粒度，從而提高單個紅包的領取併發量。
具體方案如下（我們稱為方案一）：
在方案二中，對發紅包的流程進行了一個改動，即在發紅包時會對紅包進行一個預拆分的處理，將紅包拆成多個紅包，這樣就完成了鎖粒度的細化，在使用者領取紅包時從之前的爭搶單個紅包鎖變為現在多個紅包鎖分配。
從而在領取紅包時問題就變為如何給使用者分配紅包。
一種常用的思路是當使用者請求領取紅包時，通過 redis 的自增方法來生成序列號，該序列號即對應該領取那一個紅包。但是這種方式強依賴 redis,在 redis 網路抖動或者 redis 服務異常時，需要降級到去查詢 DB 還未領取的紅包來獲取序列號，整體實現比較複雜。
7.3 最終方案
在視訊紅包的場景中，整個業務流程是使用者拍攝視訊發紅包，然後在視訊推薦 feed 流中刷到視訊時，才會觸發領取。
相對於微信和飛書這種典型IM即時通訊的群聊場景，視訊紅包中同一個紅包的領取併發數並不會很高，因為使用者刷視訊的操作以及 feed 流本身就完成了流量的打散。所以對於視訊紅包來說，領取的併發數並不會很高。
從業務的角度來看：在需求實現上，我們在使用者領取完成後需要能獲取到未領取紅包的個數資訊下發給使用者展示。方案一獲取紅包庫存很方便，而方案二獲取庫存比較麻煩。
另外從系統開發複雜度和容災情況看：方案一相對來說是一個更合適的選擇。但是方案一中的風險我們需要處理下。我們需要有其他的方式來保護 DB 資源，儘量減少鎖的衝突。
具體方案如下：
1）紅包 redis 限流：
為儘可能少的減少 DB 鎖衝突，首先會按照紅包單號進行限流，每次允許剩餘紅包個數*1.5 的請求量通過。
被限流返回特殊錯誤碼，前端最多輪訓 10 次，在請求量過多的情況下通過這種方式來慢慢處理。
2）記憶體排隊：
除了 redis 限流外，為了減少 DB 鎖，我們在領取流程中加個一個紅包記憶體鎖。
對於單個紅包，只有獲取到記憶體鎖的請求才能繼續去請求 DB，從而將 DB 鎖的衝突遷移到記憶體中提前處理，而記憶體資源相對於 DB 資源來說是非常廉價的，在請求量過大時，我們可以水平擴容。
為了實現記憶體鎖，我們進行了幾個改動。
首先：需要保證同一個紅包請求能打到同一個 tce 例項上，這裡我們對閘道器層路由進行了調整，在閘道器層呼叫下游服務時，會按照紅包單號進行路由策略，保證同一單號的請求打到同一個例項上。
另外：我們在紅包系統的 core 服務中基於 channel 實現了一套記憶體鎖，在領取完成後會釋放該紅包對應的記憶體鎖。
最後：為了防止鎖的記憶體佔用過大或者未及時釋放，我們起了一個定時任務去定期地處理。
3）轉賬非同步化：
從介面耗時來看：轉賬是一個耗時較長的操作，本身涉及和第三方支付機構互動，會有跨機房請求，響應延時較長。將轉賬非同步化可以降低領取紅包介面的時延，提高服務效能和使用者體驗。
從使用者感知來看：使用者更關注的是領取紅包的點選開後是否領取成功，至於餘額是否同步到賬使用者其實感知沒那麼強烈。
另外：轉賬本身也是有一個轉賬中到轉賬成功的過程，將轉賬非同步化對於使用者的感知基本沒有影響。
8、穩定性容災實踐
8.1 概述
整個紅包系統的容災，我們主要從以下3個方式來進行的：
1）介面限流；
2）業務降級；
3）多重機制保證狀態機的推進。
如下圖所示：
下面對這幾個方式分別介紹下。
8.2 介面限流
介面限流是一種常見的容災方式，用於保護系統只處理承受範圍內的請求，防止外部請求過大將系統打崩。
在進行介面限流前，我們首先需要和上下游以及產品溝通得到一個預估的紅包發放和領取量，然後根據發放和領取量進行分模組地全鏈路的大盤流量梳理。
下面是當時我們梳理的一個 b2c 全鏈路的請求量：
有個各個模組的請求量後，彙總之後就可以得到各個介面，紅包系統各個服務以及下游依賴的各個服務的流量請求，這個時候再做限流就比較方便了。
8.3 業務降級
8.3.1）核心依賴降級：
在春節活動期間，紅包系統整個鏈路依賴的服務有很多，這些下游的鏈路依賴可以分為核心依賴和非核心依賴。
當下遊核心服務異常時，可能某一個鏈路就不可用，此時可以在 API 層直接降級返回一個比較友好的文案提示，等下游服務恢復後再放開。
比如在 C2C 的紅包傳送流程中，使用者需要完成支付才可以發紅包，如果財經的支付流程異常或者支付成功狀態長時間未完成，會造成使用者支付後紅包傳送不成功，也會導致前端來不停的輪訓查詢紅包狀態，導致請求量陡增，造成服務壓力，甚至影響 B2C 的紅包發放和查詢。
此時可以通過介面降級的方式，將 C2C 的紅包發放降級返回，減少服務壓力，同時降低對其他業務邏輯的影響。
8.3.2）非核心依賴降級：
除核心依賴外，紅包系統還有一些非核心的下游依賴，對於這些依賴，如果服務出現異常，我們可以降低使用者部分體驗的方式來保證服務的可用。
比如在前面我們提到的，使用者在發 B2C 紅包前需要先獲取所有可用的紅包補貼，我們會去獎勵發放端查詢到所有的 Token 列表，然後查詢我們自己的 DB，然後進行 merge 返回。
如果獲取 Token 列表的介面異常時，我們可以降級只返回我們自己 DB 中的補貼資料，這樣可以保證使用者在這種情況下還可以進行紅包的發放，隻影響部分補貼的展示，而不是影響整個紅包傳送鏈路。
8.4 多重機制保證狀態機的推進
在紅包系統中，如果某個訂單長時間未到終態，比如使用者領取紅包後長時間未到賬，或者使用者 C2C 紅包未領取長時間未給使用者退款都有可能造成使用者的客訴。
因此需要及時準確地保證系統中各個訂單的狀態能推到終態。
這裡我們有幾種方式去保證。
首先是回撥，在依賴方系統訂單處理完後會及時地通知給紅包系統，這種方式也是最及時的一種方式。
但是隻依賴回撥可能會出現依賴方異常或者網路抖動導致回撥丟失，此時我們在紅包的各個階段都會給紅包系統發一個 mq，間隔一定的時間去消費 mq 主動查詢依賴方的訂單狀態進行更新。
最後，我們對每個狀態機都會有一個定時任務用於兜底，在定時任務多次執行仍未到終態的會 lark 通知，及時人工介入發現問題。
9、資金安全保證實踐
9.1 交易冪等
在程式設計中，冪等指任意多次執行一個請求所產生的影響與一次執行的影響相同。在資金安全中，通過訂單號來進行相應的冪等邏輯處理可以防止資損的發生。
具體來說：在紅包系統中，在紅包的發放、領取和退款中，我們都通過訂單號唯一鍵來保證介面冪等。
另外：紅包系統的補貼發放介面是冪等的，外部同一個單號多次請求發放補貼，我們需要保證只會發一張券。
實現冪等的方案很多：包括有通過資料庫或者 redis 來實現冪等的。最可靠的就是通過資料庫的唯一鍵衝突來實現，但是這種方式在資料庫存在分片例項時會引入一些額外的問題。
這裡：我們就補貼的發放來簡單介紹下，在業務系統的設計中，我們是按照 uid 分片的方式來建立業務的資料庫表，這就導致補貼的分片鍵是 uid，雖然我們也設定了紅包的補貼單號作為唯一鍵。
但是其中存在一個風險就是如果上游的系統呼叫補貼發放時，同一個外部單號更換了 uid，就可能會導致兩個請求分別打到不同的資料庫例項上，導致唯一索引失效，造成資損。
為了解決這個問題，我們又額外的引入一個以補貼發放外部單號作為分片鍵的資料庫來解決這個風險。
9.2 B2C 紅包核對
除了在開發過程的系統設計上進行相應的資金安全考慮，我們還需要通過對賬的方式來校驗我們的系統是否有資金安全問題。
在 B2C 鏈路中，整個鏈路主要是從補貼發放到紅包領取，我們對這幾個鏈路的上下游的資料都進行相應的小時計 hive 對賬。
9.3 C2C 紅包核對
在 C2C 鏈路中，整個主要從使用者發起支付，到使用者領取轉賬以及最後紅包過期退款。
在支付、轉賬、退款這三個流程都需要進行相應的核對。
同時：還需要保證使用者的紅包發放金額大於等於紅包轉賬金額+紅包退款金額，這裡大於等於是因為紅包從發放成功到退款成功整個週期會在 24h 以上。
另外：可能存在轉賬在途的這種訂導致會有多筆退款單，如果要求嚴格等於的話具體對賬時機沒法控制。
10、紅包系統的壓測實踐
10.1 概述
前面提到過，紅包系統的鏈路包含有多個介面，發領查等，需要模擬使用者的真實行為來進行壓測才能得到系統的真實效能。這裡我們使用了壓測平臺的指令碼壓測方式來進行壓測。
首先：需要對整個壓測鏈路整個改造，和上下游溝通是否可以壓測，不能壓測的需要進行相應的 mock 處理。
另外：對於儲存服務，資料庫，redis 和 mq 都要確保壓測標的正確傳遞，否則可能會影響到線上。
改造完壓測鏈路後，需要構造相應的壓測指令碼，對於 B2C 和 C2C 分為兩個指令碼。
10.2 B2C 紅包鏈路壓測
上面是 B2C 壓測的整個鏈路，首先是補貼的發放，然後通過查詢補貼，通過補貼來發放紅包，為了模擬多人來領取的情況，我們起了多個 goroutinue 來併發的領取紅包。
10.3 C2C 紅包鏈路壓測
C2C 紅包因為涉及到支付相關的操作，整個鏈路又是另外一套流程，因此對於 C2C 也需要有一個單獨的指令碼。
在壓測流程中，因為涉及到外部系統的依賴，如果等待全鏈路 OK 時再一起壓測可能會導致一些未知的問題出現。
因此我們需要自己壓測沒問題後再開始全鏈路一起壓測，在圖中和支付相關的藍色模組我們都新增了相應的 mock 開關，來控制壓測的結果。
在 mock 開關開啟時，會直接構造一個結果返回，在 mock 開關關閉時，會正常地去請求財經獲取結果。
11、後續規劃（服務 Set 化）
在前面提到的系統容災中，如果紅包核心服務改掉，或者資料庫 DB 主機房掛掉，將影響所有的使用者。此時只能降級返回，整個系統無法快速切換和恢復。
後續考慮將服務改為 set 化的架構。
即將服務 Server 和對應的儲存劃分為一個單獨的 Set，每個 Set 只處理對應劃分單元內的流量，同時多個單元之間實現流量拆分和故障隔離，以及 Set 之間資料備份。
這樣後續在某個單元異常時，可以及時將對應單元的流量切到備份單元中。
12、更多資料
[1] 一套億級使用者的IM架構技術乾貨(上篇)：整體架構、服務拆分等
[2] 一套億級使用者的IM架構技術乾貨(下篇)：可靠性、有序性、弱網優化等
[3] 從新手到專家：如何設計一套億級訊息量的分散式IM系統
[4] 阿里技術分享：電商IM訊息平臺，在群聊、直播場景下的技術實踐
[5] 一套高可用、易伸縮、高併發的IM群聊、單聊架構方案設計實踐
[6] 一套海量線上使用者的移動端IM架構設計實踐分享(含詳細圖文)
[7] 一套原創分散式即時通訊(IM)系統理論架構方案
[8] 新手入門一篇就夠：從零開發移動端IM
（本文已同步釋出於：http://www.52im.net/thread-39...）