本文作者騰訊WXG后臺開發工程師jeryyzhang，收錄時有改動，感謝原作者的分享。
1、引言
大約3年前，微信技術團隊分享了《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》一文，文中總結了微信這種超級IM基于時間序的海量數據存儲架構的設計實踐，也得以讓大家了解了微信后臺的架構設計思路。
時隔3年，微信再次分享了基于時間序的新一代海量數據存儲架構的設計實踐（可以認為是《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》一文中所述架構的升級版），希望能帶給你啟發。
本文將同步發布于“即時通訊技術圈”公眾號，歡迎關注：
推薦閱讀：阿里團隊也分享過IM基于時序的數據同步和存儲方案，有興趣可以一并閱讀：《現代IM系統中聊天消息的同步和存儲方案探討》。
本文中提到的KV存儲技術，微信團隊在多篇技術文章中都有提及，以下是這些文章：
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
學習交流：
- 即時通訊/推送技術開發交流5群：215477170[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步發布于：http://www.52im.net/thread-2970-1-1.html）
2、微信基于時序的數據業務場景
作為以手機為主要平臺的移動社交應用，微信內大部分業務生成的數據是有共性可言的：數據鍵值帶有時間戳信息，并且單用戶數據隨著時間在不斷的生成，我們將這類數據稱為基于時間序的數據。例如朋友圈的發表，支付賬單流水，公眾號文章閱讀記錄等。
這類基于時間序的數據通常不會刪除，而是會隨著時間流逝不斷積累，相應需要的存儲空間也與日俱增：key 量在萬億級別、數據量達到 PB 級別、每天新增 key 十億級別。同時在十億用戶的加持下，每天的訪問量也高達萬億級別。
3、微信的數據訪問模式
經過數據分析，我們發現基于時間序的存儲一般有如下三個特點。
特點1——讀多寫少：
這類基于時間序的存儲，如果需要訪問一段時間內的數據就需要對對應時間段內的所有鍵值對都進行一次訪問。與全部寫入到一個鍵值對的場景相比可以視為讀擴散的場景。部分業務場景下的讀寫比甚至高達 100:1。
特點2——冷熱分明：
這類基于時間序的存儲，數據的時效性往往也決定了訪問頻率。比如對用戶進行公眾號文章的推薦，用戶近期的閱讀記錄會更加具有參考意義。這就導致數據的訪問不是均勻的，而會更集中在最近一段時間所產生的數據。以某業務場景為例，70%以上的訪問來自最近一天內的新增數據，90%來自 3 個月內的新增數據。一年外的數據訪問占比只有 5%。
特點3：數據安全性要求高：
這類數據通常是由用戶主動產生，一旦丟失，非常容易被用戶感知，導致投訴。
下圖是數據的讀取分布情況統計：
（▲ 本圖在上篇《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》也有類似統計）
4、本次升級之前的架構及其面臨的挑戰
在本次升級之前，我們使用一致性緩存層+SSD 熱數據層+機械盤冷數據層的分層架構方案來解決此類基于時間序的存儲。更多的技術細節可以參考上篇《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》。
對于冷數據集群，我們使用微信自研的 WFS（Wechat File System 微信分布式文件系統）對其進行了一次升級，極大的簡化了運維成本。不過這部分不是本文重點，在此不再詳述。
舊架構在過去幾年微信后臺的發展過程中始終表現平穩，但是也依然面臨著一些挑戰。
首先是擴展能力方面的挑戰：舊架構中，考慮到讀多寫少的訪問模型，為了加快宕機后的數據 catchup 速度，我們使用了細粒度的 paxos group，即每個 key 有一個獨立的 paxos group。這樣在進程重啟等宕機場景下，只有少量寫入的 key 需要進行 catchup。理想很豐滿，現實很骨感。在 PaxosStore 架構中，數據的擴縮容是以 paxos group 為粒度的。也就是說，對于使用細粒度 paxos group 的存儲，進行擴縮容是逐 key 的，耗時可以看成與 key 量成正比；單機百億級別的 key 量放大了這一問題，即使我們采取一系列的工程優化縮短耗時，整體的遷移周期依然比較長，需要幾周時間。
另外一個方面則是來自容災能力的挑戰：PaxosStore 使用 KV64+三園區的部署方式（PaxosStore在上篇《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》中，被認為是該架構中的技術關鍵點）。同一個 key 的三個副本分屬三個園區，同一個園區的兩臺機器服務分片沒有重疊，因此可以容忍園區級別的故障。然而對于同組兩臺不同園區機器故障的情況，則有占比 1/6 的數據只剩余單個副本，無法提供讀寫服務。
可能有同學會認為，同組兩臺不同園區機器故障，概率無異于中彩票。然而根據墨菲定律：“凡是可能出錯的事情，最終一定會出錯”。在過去幾年也曾出現過同 Set 兩臺不同園區機器先后發生故障的情況。
我們都知道，分布式系統的一個核心觀點就是基于海量的，不可靠的硬件，構造可靠的系統。那么硬件究竟有多不可靠呢？
Jeff Dean 在 2009 年的一次 Talk 中曾經提到過：
Jeff Dean是誰？
Jeff Dean是谷歌Level 11（Google Senior Fellow）級別的超級工程師。Jeff Dean被認為是谷歌技術的代名詞，谷歌之所以如此強大，Jeff Dean是其中的很重要的原因之一?？梢钥纯粗跎系倪@個討論：zhihu.com/question/22081653
PaxosStore 使用 no raid 的磁盤陣列，磁盤故障導致單盤數據丟失時有發生。在機器故障檢修以及數據恢復的過程中，有大量數據（占單組 50%，逐漸收斂為 0）是以 2 副本形式存在，這就進一步削弱了系統的容災能力。
總結一下，我們面臨如下幾個挑戰：
1）單機百億級別 key 量，10TB 級別數據，如何快速擴容？
2）如何低成本的提升系統的容災能力，使之容忍任意雙機故障？
3）磁盤故障，數據清空后如何快速恢復。
4）作為一款十億月活的國民 APP，對其進行改造無異于給一架正在飛行的飛機更換發動機，改造過程稍有不慎都可能招致用戶投訴，甚至上個熱搜。
接下來我會針對這幾個難點逐一展開，介紹我們的解決思路與方案。
5、本次架構升級過程的技術的詳細實踐總結
5.1 計算和存儲分離的思路
對于細粒度的的 paxos group，遷移過程中，掃 key、遷移、校驗等步驟都是逐 key 粒度的。這會產生大量的磁盤 IO 與 CPU 消耗，導致遷移速度上不去，需要幾周才可以完成遷移。
那么我們能否可以采取粗粒度 paxos group 以加快遷移呢？答案是肯定的。
對比細粒度的 paxos group，單個粗粒度的 paxos group 可以同時保證多個 key 的內容強一致。因此遷移校驗等過程中，可以減少大量的 paxos 交互。
然而粗粒度 paxos group 的存儲，與細粒度 paxos group 的存儲相比，在遷移過程中對目標集群的寫入不會減少，總體依然涉及了大量數據的騰挪。而由于 LSMTree 存儲引擎存在的寫放大問題，數據大量寫入目標機這一過程會成為瓶頸。
總體來看，擴容時間可以縮短為原來的 1/2 甚至 1/3，達到天級別的水平。
看起來相比細粒度 paxos group 的遷移已經有很大改進，我們能否更進一步？
首先我們分析一下在什么場景下需要擴容，一般來說是以下兩個場景：
1）由于數據增加，磁盤容量達到瓶頸；
2）由于請求增加，CPU 處理能力達到瓶頸。
對于情況 1：如果我們使用分布式文件系統替代本地文件系統，當容量達到瓶頸時只需要增加分布式文件系統的機器就可以實現容量的快速擴容，對上層應用而言相當于獲得了一塊容量可以無限增長的磁盤。
對于情況 2：采用計算存儲分離結構后。計算節點無狀態，不涉及數據騰挪，自然可以實現快速擴容；如果是存儲層節點 CPU 瓶頸，也可以通過文件塊級別的騰挪來實現快速擴容以及熱點打散。
應用計算存儲分離的思路，我們基于 WFS（微信分布式文件系統）以及微信 Chubby（分布式鎖），實現了一套計算存儲分離的存儲架構，代號 Infinity，寓意無限的擴展能力。
5.2 “任何計算機問題都可以通過增加一個中間層來解決”
計算機科學經典名語：“All problems in computer science can be solved by another level of indirection”。
在 Infinity 中，我們引入了一個被稱為 Container 的中間層。Container 可以近似理解為一個數據分片。每臺機器可以裝載一個或多個 Container，我們稱之為 ContainerServer。ContainerServer 會處理其上 Container 對應數據的讀寫請求，Master 負責 Container 在 ContainerServer 間的調度，Chubby 則提供了分布式鎖服務以及 Container 位置信息在內的元信息存儲。
當 master 發現有新加入的機器時，會主動觸發負載均衡，將其他 ContainerServer 上的 Container 調度到新機。整個調度過程中，不涉及數據的騰挪。在我們實際的測試中，Container 騰挪的平均耗時在百毫秒級別。
如上圖所示，這是一個多園區部署的 Infinity 示意圖。每個園區內都有獨立的 WFS 與 Chubby 存儲，每個園區都對應全量的數據。對于同一個數據分片，分別位于 3 個園區的 3 個 container 組成一個 paxos group。
對于這樣一個方案，我們是可以對每個園區實現彈性伸縮的，系統整體的可用率由最上層的 paxos 提供保證。
我們來計算下這一方案的存儲成本：園區內 3 副本的 WFS 存儲 X 園區間的 3 副本 Replica，整體就是 9 副本。對于 PB 體量的存儲，這一方案所增加的存儲成本是我們難以承擔的。既然多 zone 部署的 Infinity 存在成本問題。我們自然想到，能否使用單 zone 部署的 Infinity 來負責存儲。
首先分析成本：單 zone 部署 Infinity 的存儲成本為 3 副本 WFS，與現有架構的成本一致。其次分析擴展能力，單 zone 部署的 Infinity 一樣具有出色的擴展能力，優于現有架構。對于 Chubby 這一中心點依賴，我們可以實行 Set 化改造來盡量消除風險。
分 Set 改造后，我們不由得又想起那些年舊架構經常遇到的一種情況：單組請求突增。
此處有必要簡單介紹一下 PaxosStore 的路由方案，組間一致性 Hash，單組內是 KV64 結構。一致性 Hash 消除訪問熱點，一切看起來很美好。然而假設由于某些原因，大量請求集中訪問某組 KV 時，如何應急？
此時我們既無法快速增加該組內的機器處理請求（KV64 限制），也無法快速分散請求到其他組（如果這組 KV 需要 3 倍容量，那就要把整個服務整體擴容 3 倍才可以）。
這就引發了一個尷尬的局面：
1）一組 KV 水深火熱，其他組 KV 愛莫能助；
2）只能反復調整前端請求的訪問比例，直到業務低峰期。
那么在 Infinity 中，我們如何解決這一問題呢？
首先：我們的 Set 化本質上是對 Container 進行分組，其中 Container 到組的映射關系是存儲于 Chubby 中的。如果我們想分散一組請求到其他組，只需要依次修改每一組 Chubby 中存儲的映射關系即可。在實際實現中還有一些工程細節需要考慮，比如對于要移入其他組的 Container，必須在原組進行 Unload 并停止調度等。這里就不一一展開了。
我們在線上也進行了一次大規模騰挪 Container 到其他組的實驗：結果顯示，單個 container 騰挪到其他組，平均耗時不足 1 秒。
5.3 單 zone Infinity 架構的一些問題
單 zone Infinity 架構解決了多 zone Infinity 成本問題的同時，也必然做出了取舍。
對于某個 container，任一時刻必須只在最多一個 containersvr 上服務。否則就有導致數據錯亂的風險。類比多線程中的 data race。我們通過引入分布式鎖服務來避免 double assign。同時為了減少分布式鎖開銷，我們將鎖的粒度由 Container 級別收斂到 ContainerSvr 級別。每臺 ContainerSvr 開始提供服務后會定期前往 chubby 續租。如果一臺 ContainerSvr 崩潰，master 也需要等到鎖租約過期后才可以認為這臺 ContainerSvr 掛掉，并將其上的 container 分配出去。
這就會導致存在一部分 container 在租約切換期間（秒級別）不能服務。
我們引入兩個可靠性工程的常見指標來進行說明：
1）MTTR：全稱是 Mean Time To Repair，即平均修復時間。是指可修復系統的平均修復時間，就是從出現故障到修復中間的這段時間。MTTR 越短表示易恢復性越好；
2）MTBF：全稱是 Mean Time Between Failure，是指可修復系統中相鄰兩次故障間的平均間隔。MTBF 越高說明越不容易出現故障。
可以說，單 zone Infinity 架構縮短了 MTTR，但是也縮短了 MTBF，導致整體的可用性依然不高。
5.4 不可能三角？
在很多領域中，都有類似“不可能三角”的理論。比如分布式理論中經典的 CAP 定理，經濟學理論中的蒙代爾不可能三角等。
在我們上面的討論中，其實也蘊含了這樣的一個“不可能三角”：
1）成本
2）擴展性
3）可用性。
具你本來說：
1）PaxosStore 兼顧了成本與可用性，但擴展能力稍遜；
2）多 zone Infinity 可用性與擴展性都為上乘，但成本是個問題；
3）單 zone Infinity 犧牲了一點可用性，換來了成本和擴展性的優勢。
三者不可得兼，我們該如何取舍？
1）首先是成本：是我們必須考慮的因素，這關系到我們架構實際落地還是成為巴貝奇的分析機；
2）其次是可用性：這關系到用戶的使用體驗。
在我們的新架構中，可用性不僅不能下降，甚至還應該有所提升。比如：容忍任意雙機故障。結合上面的討論，一個核心的目標逐漸浮出水面：低成本雙機容災改造。
5.5 低成本雙機容災改造
我們首先來分析一下如何實現雙機容災改造。
一個簡單的思路是：提升我們的副本數，由 3 副本提升為 5 副本。
5 副本自然可以容忍小于多數派（<=2）的機器故障，實現雙機容災。然而考慮到成本問題，3 副本改造為 5 副本，成本增加 66%，這是我們無法接受的。
此時我們想到了函數式編程中的常見思想：Immutable! 對于靜態不可變的數據而言，只要有 3 個副本，那么我們也可以在丟失 2 個副本的情況下，信任唯一的副本。
然而對于一個存儲系統而言，我們沒辦法控制用戶不修改 Key 對應的 Value 值，那么我們該如何實現靜態化 3 副本呢？
5.6 LSMTree Revisited
關于 LSMTree 這一存儲引擎的介紹，資料有很多。這里就不再詳述了。
這里引用一張 LSMTree 的架構圖：
我們分析一下圖中每個類型的文件：
1）對于 SSTable 文件，寫入完成后即不可變，而且是 LSMTree 中主要的數據存儲（占比超過 99%），對于這一部分文件我們只需要存儲 3 副本即可；
2）對于其他的文件如 WAL log，以及 Manifest，我們使用 5 副本存儲，總體的存儲成本增長可以忽略不計。
這樣，我們就可以使用單 zone Infinity，在保持存儲成本不變的情況下，獲得雙機容災的能力。
5.7 分而治之
架構的不足之處：
1）單 zone Infinity 可以以 3 副本的存儲成本實現雙機容災，然而存在租約切換期間的不可用問題；
2）5 副本 KV 實現了無租約的雙機容災，然后存儲成本相比原來增加了 2/3。
兩種架構各有不足，看似我們陷入了死局。然而回顧基于時間序數據的訪問模型，我們發現對于熱數據與溫數據，他們表現出了截然不同甚至相反的一些有趣性質。
我們可以采取計算機科學中的重要思想——分治來解決：
1）對于熱數據：訪問量較大，我們希望他有最高的可用性，同時它的數據占比又不大，適于采用 5 副本 KV 的方案進行雙機容災改造；
2）對于溫數據：數據量較大，不能采取 5 副本方案改造，而使用單 zone Infinity 的方案，則可以完美解決成本問題。
雖然會有偶爾短暫的不可用時長，但是由于整體的訪問占比不多，系統整體的可用率依然可以保持在很高的水準。
對新架構的成本分析：
這樣我們就在不顯著增加存儲成本，不犧牲可用性的前提下，實現了雙機容災的目標。
為了提升熱數據部分的擴展性，我們可以使用粗粒度 paxos group 的交互方案。對于熱數據，在數據量減少+粗粒度 paxos group 雙重改進下，擴容時間可以提升到小時級別。同時，我們實現了熱數據由 5 副本 KV 到單 zone Infinity 的自動下沉。一方面可以保持總體的存儲成本不膨脹，另一方面也減少了熱數據的總量，熱數據集群的擴容需求也就沒有那么強烈。
5.8 磁盤清空后的數據快速恢復
對于 Infinity 部分的數據，可以依靠 WFS 自動檢測，補全副本數。在機器檢修期間就可以完成大部分數據的補全。對于熱數據部分的數據，雖然數據減少，但是恢復過程中還是會受限于 lsmtree 的寫入過程中 Compact 產生的寫放大問題。
經過一些業界的調研，對于 lsmtree 批量導入的場景，一種常見的做法是 BulkLoad，也即先將所有 key 進行排序，生成有序的 SSTable 文件，直接提交到 lsmtree 的最后一層，這樣可以完全繞過寫放大實現數據的導入。
我們經過分析，發現這種做法還不是最優的。首先，我們對于 SSTable 中的數據會進行 block 級別的壓縮，在遍歷數據的過程中需要進行解壓；而在生成 SSTable 的過程中，為了減少存儲成本，又需要進行壓縮。經過研究，發現我們這種場景下有更優的恢復方案：基于目錄級別的快速恢復。
5.9 目錄級別的快速恢復
要想實現目錄級別的快速恢復，首要條件就是：需要數據的路由規則與目錄分布是完全對齊的。這樣才可以保證恢復目錄后，不會獲得不屬于本機的數據，也不會遺漏數據。
在此前的 kv 中都忽略了這一設計，導致無法通過拷貝文件實現快速恢復。結合 5 副本的路由方案，我們獲得了一個可以實現對齊的目錄分布方案。推導后的方案非常簡潔，用一張圖片即可說明。
我們進行的測試也印證了這一改造的效果，基于目錄拷貝的恢復方案相比原來逐 paxos group 恢復方案取得了近 50 倍的速度提升，從小時級進入到分鐘級。
5.10 新架構終得成型
對幾個架構方案的對比：
5.11 平穩升級到最新架構成果
至此我們的改造方案有了，然而改造過程同樣值得注意。我們必須在保證系統穩定的前提下，平穩的完成數據與訪問的切換。
首先是灰度能力，我們做了兩個粒度的灰度控制：
1）一是訪問時間級別，按照 key 上面的時間，分批將數據從原架構中騰挪出來；
2）二是命令字級別，數據騰挪完成后，我們會先保持雙寫狀態觀察，先逐步切換讀請求到新架構中，觀察正常后才會去掉雙寫，完成切換。
其次是改造的正確性：
1）我們采取了全量的數據校驗方案，保證改造過程中不會丟失數據；
2）最后是在騰挪過程中，我們開發了一套基于機器資源以及監控上報的自動反饋機制，當業務高峰期或者出現失敗時自動降速，低峰期自動加速，減少了人為介入。
目前，我們已經完成部分核心存儲集群的架構改造，實現了全程無故障切換。
6、本文小結
2019 年，微信后臺通過如上持續不斷的改造，在不增加成本的前提下，極大提升了基于時間序存儲的擴展能力，從周級別的擴容速度升級到整體小時級的擴容速度，并且溫數據部分的計算節點做到了分鐘級的擴容速度。
同時，利用數據的特性進行集群劃分，將 5 副本 PaxosStore 存儲與計算存儲分離架構進行有機結合，在極大提升了擴展能力的同時，將可用性提升到容忍雙機故障的水平。
附錄1：更多QQ、微信團隊原創技術文章
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)》
《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《微信團隊原創分享：iOS版微信的內存監控系統技術實踐》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《iOS后臺喚醒實戰：微信收款到賬語音提醒技術總結》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《微信團隊分享：視頻圖像的超分辨率技術原理和應用場景》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享：手機QQ中的人臉識別酷炫動畫效果實現詳解》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數據全文檢索優化之路》
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務接口隔離技術》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《以手機QQ為例探討移動端IM中的“輕應用”》
《一篇文章get微信開源移動端數據庫組件WCDB的一切！》
《微信客戶端團隊負責人技術訪談：如何著手客戶端性能監控和優化》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信后臺?；顚崙鸱窒?進程保活篇)》
《微信團隊原創分享：Android版微信后臺?；顚崙鸱窒?網絡?；钇?》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術之道PPT [附件下載]》
《微信對網絡影響的技術試驗及分析（論文全文）》
《一份微信后臺技術架構的總結性筆記》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《全面總結iOS版微信升級iOS9遇到的各種“坑”》
《微信團隊原創資源混淆工具：讓你的APK立減1M》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰記錄》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背后的技術難題》
《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設備字體適配方案探討》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《騰訊TEG團隊原創：基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《了解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術嘗鮮之旅》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背后的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高并發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構等》
《社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐》
《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背后的功能設計思路》
《微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現》
《微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考》
>> 更多同類文章 ……
附錄2：更多IM架構方面的文章匯總
[1] 有關IM架構設計的文章：
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《王者榮耀2億用戶量的背后：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《以微博類應用場景為例，總結海量社交系統的架構設計步驟》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐》
《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背后的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高并發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(七)：支付寶紅包的海量高并發技術實踐》
《社交軟件紅包技術解密(八)：全面解密微博紅包技術方案》
《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構等》
《社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐》
《即時通訊新手入門：一文讀懂什么是Nginx？它能否實現IM的負載均衡？》
《即時通訊新手入門：快速理解RPC技術——基本概念、原理和用途》
《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》
《從游擊隊到正規軍(一)：馬蜂窩旅游網的IM系統架構演進之路》
《從游擊隊到正規軍(二)：馬蜂窩旅游網的IM客戶端架構演進和實踐總結》
《IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！》
《瓜子IM智能客服系統的數據架構設計（整理自現場演講，有配套PPT）》
《阿里釘釘技術分享：企業級IM王者——釘釘在后端架構上的過人之處》
《從游擊隊到正規軍(三)：基于Go的馬蜂窩旅游網分布式IM系統技術實踐》
《微信后臺基于時間序的新一代海量數據存儲架構的設計實踐
>> 更多同類文章 ……
[2] 更多其它架構設計相關文章：
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路》
《新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐》
《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《達達O2O后臺架構演進實踐：從0到4000高并發請求背后的努力》
《優秀后端架構師必會知識：史上最全MySQL大表優化方案總結》
《小米技術分享：解密小米搶購系統千萬高并發架構的演進和實踐》
《一篇讀懂分布式架構下的負載均衡技術：分類、原理、算法、常見方案等》
《通俗易懂：如何設計能支撐百萬并發的數據庫架構？》
《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》
《從新手到架構師，一篇就夠：從100到1000萬高并發的架構演進之路》
《美團技術分享：深度解密美團的分布式ID生成算法》
《12306搶票帶來的啟示：看我如何用Go實現百萬QPS的秒殺系統(含源碼)》
>> 更多同類文章 ……
（本文同步發布于：http://www.52im.net/thread-2970-1-1.html）