本文由微信客戶端技術(shù)團(tuán)隊(duì)工程師“Jon”分享，原題“Windows微信：消息數(shù)據(jù)庫(kù)架構(gòu)演進(jìn)”，有較多修訂。

1、引言

本文分享的是，微信客戶端團(tuán)隊(duì)基于對(duì)微信用戶日常使用場(chǎng)景和數(shù)據(jù)分析，通過(guò)分離重要和非重要數(shù)據(jù)、采用可靠的分庫(kù)策略等，對(duì)微信Windows端IM本地?cái)?shù)據(jù)庫(kù)的架構(gòu)進(jìn)行的優(yōu)化和改造，并最終得到一個(gè)具備良好實(shí)踐效果的技術(shù)改造方案。

?

以下是相關(guān)技術(shù)文章，有興趣的讀者可以一并閱讀：

1. 微信客戶端SQLite數(shù)據(jù)庫(kù)損壞修復(fù)實(shí)踐

2. 微信移動(dòng)端的全文檢索優(yōu)化之路

3. 微信移動(dòng)端的全文檢索多音字問(wèn)題解決方案

4. 微信iOS端的最新全文檢索技術(shù)優(yōu)化實(shí)踐

5. 微信本地?cái)?shù)據(jù)庫(kù)破解版(含iOS、Android)，僅供學(xué)習(xí)研究 [附件下載]

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

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

- 開(kāi)源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

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

2、背景說(shuō)明

微信的Windows客戶端自2014年上線以來(lái)，用戶數(shù)穩(wěn)步增長(zhǎng)。隨著時(shí)間的不斷推移，很多用戶本地積攢的消息量越來(lái)越大。

最初的本地IM數(shù)據(jù)庫(kù)設(shè)計(jì)秉著遵循“簡(jiǎn)單易用、方便管理”的原則，把用戶收到的所有消息都統(tǒng)一存放在用戶當(dāng)前客戶端本地的“同一個(gè)SQLite數(shù)據(jù)文件中”。

(作者注：微信不會(huì)保存聊天記錄，聊天內(nèi)容只存儲(chǔ)在用戶手機(jī)、電腦等終端設(shè)備上。)

3、當(dāng)前問(wèn)題

由于初期這套本地?cái)?shù)據(jù)庫(kù)設(shè)計(jì)方案的短板，隨著目前微信使用越來(lái)越廣泛、消息堆積越來(lái)越多，從而逐漸暴露出了許多技術(shù)問(wèn)題。

3.1 問(wèn)題1：數(shù)據(jù)查詢慢

隨著使用時(shí)間的推移，數(shù)據(jù)也逐漸增多，當(dāng)數(shù)據(jù)量越來(lái)越龐大：

• 1）數(shù)據(jù)庫(kù)的查詢和插入效率會(huì)受到影響；

• 2）即使消息數(shù)據(jù)庫(kù)存在索引，索引的查詢效率也隨之下降。

從文件系統(tǒng)的角度，數(shù)據(jù)庫(kù)文件是逐頁(yè)增長(zhǎng)的。因?yàn)殚L(zhǎng)時(shí)間的使用微信會(huì)使得消息量的逐步累積，讓數(shù)據(jù)庫(kù)體積逐漸增長(zhǎng)，也會(huì)導(dǎo)致碎片化更嚴(yán)重，這在機(jī)械硬盤(pán)下，也會(huì)進(jìn)一步影響讀寫(xiě)效率。

對(duì)用戶最直觀的影響就是——切換聊天變得很卡，這個(gè)問(wèn)題對(duì)于重度用戶尤甚，甚至?xí)霈F(xiàn)點(diǎn)擊聊天就卡頓的情況。

3.2 問(wèn)題2：存儲(chǔ)文件大

隨著時(shí)間的推移，消息量的逐步累積，數(shù)據(jù)庫(kù)存儲(chǔ)文件的體積也是越來(lái)越大，顯著占用用戶存儲(chǔ)空間。

3.3 問(wèn)題3：磁盤(pán)文件損壞

磁盤(pán)文件意外損壞也有可能導(dǎo)致數(shù)據(jù)丟失。

因?yàn)樗邢⒍挤诺揭粋€(gè)數(shù)據(jù)庫(kù)文件，就類(lèi)似把所有雞蛋放在一個(gè)籃子。

數(shù)據(jù)庫(kù)文件也可能會(huì)因?yàn)榇鎯?chǔ)壞道、電腦意外斷電、sqlite自身bug等原因?qū)е聰?shù)據(jù)庫(kù)文件發(fā)生損壞。如果發(fā)生損壞時(shí)，有可能導(dǎo)致用戶丟失消息數(shù)據(jù)。即使有DB恢復(fù)機(jī)制，也無(wú)法保證能恢復(fù)出所有歷史記錄。

當(dāng)這種情況發(fā)生時(shí)，對(duì)用戶影響十分大，因?yàn)榱奶煊涗浛赡軟](méi)了！

PS：微信移動(dòng)端也有類(lèi)似困擾，有興趣可以閱讀《微信客戶端SQLite數(shù)據(jù)庫(kù)損壞修復(fù)實(shí)踐》。

4、原因分析

4.1 概述

上述數(shù)據(jù)庫(kù)存儲(chǔ)文件變大和查詢變慢的問(wèn)題，都是由于消息數(shù)據(jù)的不斷增多引起。

但消息數(shù)的增長(zhǎng)是無(wú)法避免的，那么有沒(méi)有辦法控制增長(zhǎng)速度，并且控制數(shù)據(jù)庫(kù)的大?。?/p>

我們從兩個(gè)方向進(jìn)行分析：消息情況、日常使用場(chǎng)景

4.2 分析1：消息情況

微信里的IM消息可分為三大類(lèi)：

• 1）單人聊天消息；

• 2）群聊消息；

• 3）以及訂閱號(hào)/服務(wù)號(hào)消息（統(tǒng)稱(chēng)為公眾號(hào)消息）。

按消息的重要性來(lái)說(shuō)：

• 1）單聊/群聊消息：這是用戶的私人消息，被刪除或者丟失無(wú)法恢復(fù)，對(duì)用戶損失最大；

• 2）公眾號(hào)的消息：因?yàn)橹灰P(guān)注了公眾號(hào)，都可以拉取閱讀，屬于公共消息，所以對(duì)用戶來(lái)說(shuō)重要性稍低。

按消息的大小來(lái)說(shuō)：

• 1）基于對(duì)測(cè)試帳號(hào)的消息大小數(shù)據(jù)分析，我們發(fā)現(xiàn)：占總條數(shù)比例不高的公眾號(hào)消息，占用了超過(guò)一半的數(shù)據(jù)庫(kù)空間；

• 2）經(jīng)過(guò)對(duì)測(cè)試帳號(hào)消息類(lèi)型的分析：網(wǎng)頁(yè)卡片類(lèi)消息是公眾號(hào)消息的主要類(lèi)型，其平均消息體大小是文本消息的幾十倍。

4.3 分析2：日常應(yīng)用場(chǎng)景分析

眾所周知，我們?nèi)粘Ｊ褂梦⑿?，都是收發(fā)消息，或者瀏覽最近的消息。對(duì)于更早的消息，我們一般很少會(huì)主動(dòng)去瀏覽。

越早的消息，瀏覽的概率越低。

所以：在大多數(shù)場(chǎng)景下，我們要讓最常訪問(wèn)的消息，不受老數(shù)據(jù)的影響。

5、解決方案

5.1 概述

針對(duì)前述問(wèn)題并結(jié)合上述分析，我們從以下方面對(duì)微信Windows端本地SQLite數(shù)據(jù)庫(kù)的架構(gòu)進(jìn)行了演進(jìn)和優(yōu)化。

涉及的主要優(yōu)化內(nèi)容和手段有：

• 1）分庫(kù)改造；

• 2）建立消息索引；

• 3）消息體積優(yōu)化；

• 4）提高數(shù)據(jù)庫(kù)健壯性。

下面我們將逐一詳細(xì)介紹。

5.2 分庫(kù)改造

基于以上分析，首先把公眾號(hào)消息劃分出去，存到單獨(dú)的一個(gè)數(shù)據(jù)庫(kù)，跟用戶的普通消息隔離，同時(shí)也可以大幅減少普通消息數(shù)據(jù)庫(kù)的體積。

基于日常使用場(chǎng)景的分析，大部分老數(shù)據(jù)讀取的頻率很低，所以應(yīng)該提高最近一段時(shí)間的讀寫(xiě)效率。

對(duì)于上述這種情況，我們采取了以時(shí)間和空間動(dòng)態(tài)劃分?jǐn)?shù)據(jù)庫(kù)的方案。初始默認(rèn)值是每個(gè)數(shù)據(jù)庫(kù)存放半年的消息，超過(guò)時(shí)間之后新建一個(gè)數(shù)據(jù)庫(kù)存放。對(duì)于大部分使用場(chǎng)景，我們只需要讀寫(xiě)最新的數(shù)據(jù)庫(kù)就可以滿足需求，如果需要瀏覽更早的消息，可以再打開(kāi)之前的數(shù)據(jù)庫(kù)進(jìn)行讀取。

除了時(shí)間維度，我們還考慮了空間維度的劃分：如果半年內(nèi)消息普通消息規(guī)模超過(guò)閾值，也會(huì)新建一個(gè)數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)，讓每個(gè)數(shù)據(jù)庫(kù)大小和數(shù)據(jù)規(guī)模不至于太大，能提升最近一段時(shí)間消息的讀寫(xiě)效率。

5.3 建立消息索引

對(duì)于最廣泛的使用場(chǎng)景——查看每一個(gè)聊天的消息，這種場(chǎng)景需要對(duì)每一個(gè)聊天會(huì)話建立一個(gè)索引。

這里的索引方案我們參考了安卓端：即將每一個(gè)聊天轉(zhuǎn)換成一個(gè)數(shù)值型的ID，從而減少每條索引的長(zhǎng)度，提高索引的讀寫(xiě)效率。（關(guān)于微信的移動(dòng)端SQLite完整數(shù)據(jù)庫(kù)結(jié)構(gòu)，可以參考：《微信本地?cái)?shù)據(jù)庫(kù)破解版(含iOS、Android)，僅供學(xué)習(xí)研究 [附件下載]》）

除此之外，我們還對(duì)一些經(jīng)常訪問(wèn)的內(nèi)容，單獨(dú)提取成為一個(gè)字段，并且增加索引。比如消息的子類(lèi)型（這個(gè)在老數(shù)據(jù)庫(kù)中是一個(gè)序列化字段），它沒(méi)有索引，但這個(gè)字段經(jīng)常需要用到，所以單獨(dú)提出成為一列，并且加上索引，為消息按類(lèi)型查找提供方便。

5.4 消息體積優(yōu)化

IM中消息顯然總是會(huì)越來(lái)越多的，但如何能夠在不影響讀寫(xiě)效率的同時(shí)，減少/壓縮消息數(shù)據(jù)的體積，也是我們的優(yōu)化方向。

從上面的數(shù)據(jù)看，部分消息體積較大，已經(jīng)超過(guò)了數(shù)據(jù)庫(kù)每頁(yè)的大?。≒age Size）。

數(shù)據(jù)庫(kù)是按頁(yè)存儲(chǔ)數(shù)據(jù)的，Page Size是數(shù)據(jù)庫(kù)一頁(yè)能夠容納的數(shù)據(jù)。如果一條數(shù)據(jù)，一個(gè)頁(yè)放不下，就需要用到溢出頁(yè)，把多出來(lái)放不下的數(shù)據(jù)放到溢出頁(yè)中，溢出頁(yè)可以有多個(gè)。

這時(shí)候，如果讀取這條數(shù)據(jù)，就需要把溢出頁(yè)也全部讀出來(lái)，會(huì)增加IO的消耗。

如果壓縮數(shù)據(jù)，能夠把消息體壓縮到一個(gè)頁(yè)能放得下，減少溢出頁(yè)的使用，是可以增加IO性能的。

SQLite數(shù)據(jù)庫(kù)溢出頁(yè)結(jié)構(gòu)：

(上圖引用自書(shū)籍《The Definitive Guide to SQLite》第308頁(yè))

PS：《The Definitive Guide to SQLite》這本書(shū)的電子版我也給你找到了，請(qǐng)從下面附件處下載：

?The Definitive Guide to SQLite (2nd edition, 2010)-52im.net.pdf.zip?(3.61 MB)

但是壓縮需要占用CPU資源，這里選擇一種能夠平衡性能和壓縮率的算法是關(guān)鍵。

經(jīng)過(guò)對(duì)比壓縮算法的Benchmark，并且對(duì)消息體壓縮性進(jìn)行實(shí)測(cè)，最終選擇了一個(gè)高性能壓縮算法：lz4。

經(jīng)過(guò)對(duì)測(cè)試帳號(hào)的數(shù)據(jù)分析，不同類(lèi)型的消息體大小差異較大。

一般來(lái)說(shuō)：文本消息的長(zhǎng)度不會(huì)特別大，但是網(wǎng)頁(yè)卡片類(lèi)型的消息，體積會(huì)較大。由于不同的消息長(zhǎng)度，獲得的壓縮率不一樣，太短的文本長(zhǎng)度，壓縮起來(lái)并沒(méi)有意義。

所以經(jīng)過(guò)消息體長(zhǎng)度、壓縮、，壓縮性能的分析，最終確定對(duì)網(wǎng)頁(yè)卡片等進(jìn)行壓縮，在較低性能消耗的前提下，綜合壓縮率可達(dá)到40%，減少了IO次數(shù) 。

5.5 提高健壯性

如果數(shù)據(jù)庫(kù)文件由于外部原因發(fā)生損壞，則會(huì)對(duì)體驗(yàn)造成較大影響。降低損壞率和減少損壞帶來(lái)的數(shù)據(jù)損失，也是我們改進(jìn)的方向。

按照時(shí)間維度劃分?jǐn)?shù)據(jù)庫(kù)之后，相當(dāng)于把消息按時(shí)間分散存儲(chǔ)。最新的數(shù)據(jù)庫(kù)負(fù)責(zé)讀寫(xiě)最近的消息，其余的數(shù)據(jù)庫(kù)只需要根據(jù)需求支持瀏覽查看消息。

對(duì)于老數(shù)據(jù)庫(kù)而言：可以做到按需加載，從而減少了對(duì)數(shù)據(jù)庫(kù)的讀寫(xiě)，也減少了這些數(shù)據(jù)庫(kù)損壞的幾率。一旦有數(shù)據(jù)庫(kù)出現(xiàn)損壞，即使無(wú)法恢復(fù)，也不會(huì)所有消息全部丟失，只會(huì)丟失該數(shù)據(jù)庫(kù)對(duì)應(yīng)時(shí)間段的消息，這也可以減少部分?jǐn)?shù)據(jù)庫(kù)損壞帶來(lái)的損失。

在早期使用的單數(shù)據(jù)庫(kù)架構(gòu)中，由于數(shù)據(jù)會(huì)越攢越多，數(shù)據(jù)庫(kù)體積會(huì)持續(xù)變大，很難去做備份。分庫(kù)之后，每個(gè)數(shù)據(jù)庫(kù)體積變小，因而數(shù)據(jù)庫(kù)備份變得更為可行。因?yàn)樽钚碌臄?shù)據(jù)庫(kù)存在頻繁的消息讀寫(xiě)，發(fā)生損壞的概率遠(yuǎn)高于老數(shù)據(jù)庫(kù)，所以這里對(duì)最新的一個(gè)數(shù)據(jù)庫(kù)做定期的備份。

默認(rèn)配置下，我們每間隔一段時(shí)間會(huì)對(duì)最新的數(shù)據(jù)庫(kù)進(jìn)行一次備份，該備份是最新的一個(gè)數(shù)據(jù)庫(kù)的完整拷貝。若最新的數(shù)據(jù)庫(kù)在讀寫(xiě)時(shí)發(fā)生損壞，會(huì)先嘗試從備份數(shù)據(jù)恢復(fù)。若恢復(fù)成功，則最多丟失從備份到恢復(fù)這段時(shí)間的數(shù)據(jù)，進(jìn)一步降低損壞造成的損失。

6、優(yōu)化對(duì)比

經(jīng)過(guò)對(duì)比，對(duì)于一個(gè)在測(cè)試帳號(hào)中原始的消息數(shù)據(jù)庫(kù)，壓縮后大小可以減少接近一半，同時(shí)溢出頁(yè)數(shù)和需要使用溢出頁(yè)的記錄數(shù)減少也超過(guò)一半。

對(duì)于讀寫(xiě)性能，對(duì)比壓縮前，壓縮后的讀取和解壓縮性能比之前有接近10%的提升。

7、未來(lái)展望

后續(xù)我們微信客戶端團(tuán)隊(duì)將繼續(xù)研究數(shù)據(jù)庫(kù)修復(fù)相關(guān)的實(shí)踐，持續(xù)關(guān)注數(shù)據(jù)庫(kù)相關(guān)的性能數(shù)據(jù)，提升可靠性，打造更好的用戶體驗(yàn)！

附錄：更多大廠IM文章匯總

[1] 微信團(tuán)隊(duì)原創(chuàng)技術(shù)文章：

1. 《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

2. 《IM全文檢索技術(shù)專(zhuān)題(二)：微信移動(dòng)端的全文檢索多音字問(wèn)題解決方案》

3. 《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》

4. 《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》

5. 《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

6. 《iOS后臺(tái)喚醒實(shí)戰(zhàn)：微信收款到賬語(yǔ)音提醒技術(shù)總結(jié)》

7. 《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場(chǎng)景》

8. 《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

9. 《微信團(tuán)隊(duì)分享：微信Android版小視頻編碼填過(guò)的那些坑》

10. 《IM全文檢索技術(shù)專(zhuān)題(一)：微信移動(dòng)端的全文檢索優(yōu)化之路》

11. 《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

12. 《微信團(tuán)隊(duì)披露：微信界面卡死超級(jí)bug“15。。。?！钡膩?lái)龍去脈》

13. 《月活8.89億的超級(jí)IM微信是如何進(jìn)行Android端兼容測(cè)試的》

14. 《一篇文章get微信開(kāi)源移動(dòng)端數(shù)據(jù)庫(kù)組件WCDB的一切！》

15. 《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》

16. 《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》

17. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》

18. 《微信后臺(tái)團(tuán)隊(duì)：微信后臺(tái)異步消息隊(duì)列的優(yōu)化升級(jí)實(shí)踐分享》

19. 《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫(kù)損壞修復(fù)實(shí)踐》

20. 《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫(kù)，即將開(kāi)源》

21. 《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開(kāi)源》

22. 《開(kāi)源libco庫(kù)：?jiǎn)螜C(jī)千萬(wàn)連接、支撐微信8億用戶的后臺(tái)框架基石 [源碼下載]》

23. 《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》

24. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(進(jìn)程?；钇?》

25. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)?；钇?》

26. 《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》

27. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》

28. 《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》

29. 《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(PPT講稿) [附件下載]》

30. 《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》

31. 《微信海量用戶背后的后臺(tái)系統(tǒng)存儲(chǔ)架構(gòu)(視頻+PPT) [附件下載]》

32. 《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬(wàn)連接背后的后臺(tái)解決方案》

33. 《微信朋友圈海量技術(shù)之道PPT [附件下載]》

34. 《微信對(duì)網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》

35. 《一份微信后臺(tái)技術(shù)架構(gòu)的總結(jié)性筆記》

36. 《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》

37. 《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

38. 《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（二）》

39. 《微信團(tuán)隊(duì)原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》

40. 《全面總結(jié)iOS版微信升級(jí)iOS9遇到的各種“坑”》

41. 《微信團(tuán)隊(duì)原創(chuàng)資源混淆工具：讓你的APK立減1M》

42. 《微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》

43. 《Android版微信安裝包“減肥”實(shí)戰(zhàn)記錄》

44. 《iOS版微信安裝包“減肥”實(shí)戰(zhàn)記錄》

45. 《移動(dòng)端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測(cè)方案》

46. 《微信“紅包照片”背后的技術(shù)難題》

47. 《移動(dòng)端IM實(shí)踐：iOS版微信小視頻功能技術(shù)方案實(shí)錄》

48. 《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（一）》

49. 《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》

50. 《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》

51. 《移動(dòng)端IM實(shí)踐：iOS版微信的多設(shè)備字體適配方案探討》

52. 《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》

53. 《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》

54. 《微信多媒體團(tuán)隊(duì)訪談：音視頻開(kāi)發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》

55. 《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》

56. 《微信多媒體團(tuán)隊(duì)梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》

57. 《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實(shí)踐》

58. 《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

59. 《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》

60. 《微信團(tuán)隊(duì)分享：Kotlin漸被認(rèn)可，Android版微信的技術(shù)嘗鮮之旅》

61. 《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

62. 《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

63. 《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》

64. 《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》

65. 《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》

66. 《社交軟件紅包技術(shù)解密(十一)：解密微信紅包隨機(jī)算法(含代碼實(shí)現(xiàn))》

67. 《微信團(tuán)隊(duì)分享：極致優(yōu)化，iOS版微信編譯速度3倍提升的實(shí)踐總結(jié)》

68. 《IM“掃一掃”功能很好做？看看微信“掃一掃識(shí)物”的完整技術(shù)實(shí)現(xiàn)》

69. 《微信團(tuán)隊(duì)分享：微信支付代碼重構(gòu)帶來(lái)的移動(dòng)端軟件架構(gòu)上的思考》

70. 《IM開(kāi)發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總》

71. 《微信團(tuán)隊(duì)分享：微信直播聊天室單房間1500萬(wàn)在線的消息架構(gòu)演進(jìn)之路》

72. 《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等》

73. 《IM全文檢索技術(shù)專(zhuān)題(四)：微信iOS端的最新全文檢索技術(shù)優(yōu)化實(shí)踐》

74. 《微信團(tuán)隊(duì)分享：微信后臺(tái)在海量并發(fā)請(qǐng)求下是如何做到不崩潰的》

75. 《微信Windows端IM消息數(shù)據(jù)庫(kù)的優(yōu)化實(shí)踐：查詢慢、體積大、文件損壞等》

76. >>?更多同類(lèi)文章 ……

[2] 微信背后的技術(shù)故事：

1. 《技術(shù)往事：微信估值已超5千億，雷軍曾有機(jī)會(huì)收編張小龍及其Foxmail》

2. 《騰訊開(kāi)發(fā)微信花了多少錢(qián)？技術(shù)難度真這么大？難在哪？》

3. 《開(kāi)發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》

4. 《開(kāi)發(fā)往事：微信千年不變的那張閃屏圖片的由來(lái)》

5. 《開(kāi)發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個(gè)月時(shí)）》

6. 《一個(gè)微信實(shí)習(xí)生自述：我眼中的微信開(kāi)發(fā)團(tuán)隊(duì)》

7. 《微信七年回顧：歷經(jīng)多少質(zhì)疑和差評(píng)，才配擁有今天的強(qiáng)大》

8. 《前創(chuàng)始團(tuán)隊(duì)成員分享：盤(pán)點(diǎn)微信的前世今生——微信成功的必然和偶然》

9. 《即時(shí)通訊創(chuàng)業(yè)必讀：解密微信的產(chǎn)品定位、創(chuàng)新思維、設(shè)計(jì)法則等》

10. 《[技術(shù)腦洞] 如果把14億中國(guó)人拉到一個(gè)微信群里技術(shù)上能實(shí)現(xiàn)嗎？》

11. 《那些年微信開(kāi)發(fā)過(guò)的雞肋功能，及其帶給我們的思考》

12. 《讀懂微信：從1.0到7.0版本，一個(gè)主流IM社交工具的進(jìn)化史》

13. 《專(zhuān)訪馬化騰：首次開(kāi)談個(gè)人經(jīng)歷、管理心得、技術(shù)創(chuàng)新、微信的誕生等》

14. 《一文讀懂微信之父張小龍：失敗天才、顛覆者、獨(dú)裁者、人性操控師》

15. >>?更多同類(lèi)文章 ……

[3] 阿里巴巴的技術(shù)分享：

1. 《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》

2. 《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》

3. 《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》

4. 《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》

5. 《來(lái)自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》

6. 《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺(tái)的技術(shù)挑戰(zhàn)(視頻+PPT) [附件下載]》

7. 《阿里技術(shù)結(jié)晶：《阿里巴巴Java開(kāi)發(fā)手冊(cè)(規(guī)約)-華山版》[附件下載]》

8. 《重磅發(fā)布：《阿里巴巴Android開(kāi)發(fā)手冊(cè)(規(guī)約)》[附件下載]》

9. 《作者談《阿里巴巴Java開(kāi)發(fā)手冊(cè)(規(guī)約)》背后的故事》

10. 《《阿里巴巴Android開(kāi)發(fā)手冊(cè)(規(guī)約)》背后的故事》

11. 《干了這碗雞湯：從理發(fā)店小弟到阿里P10技術(shù)大牛》

12. 《揭秘阿里、騰訊、華為、百度的職級(jí)和薪酬體系》

13. 《淘寶技術(shù)分享：手淘億級(jí)移動(dòng)端接入層網(wǎng)關(guān)的技術(shù)演進(jìn)之路》

14. 《難得干貨，揭秘支付寶的2維碼掃碼技術(shù)優(yōu)化實(shí)踐之路》

15. 《淘寶直播技術(shù)干貨：高清、低延時(shí)的實(shí)時(shí)視頻直播技術(shù)解密》

16. 《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場(chǎng)景下的技術(shù)實(shí)踐》

17. 《阿里技術(shù)分享：閑魚(yú)IM基于Flutter的移動(dòng)端跨端改造實(shí)踐》

18. 《阿里IM技術(shù)分享(三)：閑魚(yú)億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》

19. 《阿里IM技術(shù)分享(四)：閑魚(yú)億級(jí)IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐》

20. 《阿里IM技術(shù)分享(五)：閑魚(yú)億級(jí)IM消息系統(tǒng)的及時(shí)性優(yōu)化實(shí)踐》

21. 《阿里IM技術(shù)分享(六)：閑魚(yú)億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化》

22. 《阿里IM技術(shù)分享(七)：閑魚(yú)IM的在線、離線聊天數(shù)據(jù)同步機(jī)制優(yōu)化實(shí)踐》

23. 《阿里IM技術(shù)分享(八)：深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)》

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