1、前言

IM應(yīng)用從服務(wù)端數(shù)據(jù)的角度來看，它是一種很特殊的應(yīng)用場景，拋開基礎(chǔ)數(shù)據(jù)、增值業(yè)務(wù)和附屬功能不談，單從IM聊天工具的立身之本——聊天數(shù)據(jù)來說，理論上是不需要在服務(wù)端存儲的（或者說只需要短暫存儲——比如離線消息，上線即拉走），這也是為什么微信在前段時間號稱絕不存儲用戶聊天數(shù)據(jù)的原因（從技術(shù)上說這不是沒有道理的，但到底有沒有存儲，這已經(jīng)超越技術(shù)范疇了，不在此文討論之列 ^_^）。

那么為什么說IM系統(tǒng)的服務(wù)端從技術(shù)上說，是不需要存儲聊天數(shù)據(jù)的呢？

原因很簡單，我們知道IM的聊天數(shù)據(jù)分兩種：
?

• 一種是實時消息（就是你在線，對方也在線情況下的聊天數(shù)據(jù)交互）；
• 一種是離線消息（就是你在線，對方不在線時，你發(fā)過去的消息，對于對方而言就是離線消息了）。

實時消息的收發(fā)：服務(wù)端只作為中轉(zhuǎn)角色（關(guān)于中轉(zhuǎn)的技術(shù)問題，很多人可能還在結(jié)糾老思維為何不用P2P，我已經(jīng)論壇說爛了，說白了跟技術(shù)無關(guān)，其實一個很重要的原因就是為了運營的可控性：比如用戶P2P去了，違法的鍋你運營方來背好不好？），聊天消息在此時就相當(dāng)于左手倒右手——即聊天數(shù)據(jù)的本質(zhì)就是從A用戶經(jīng)過服務(wù)端到達(dá)B用戶就完了，服務(wù)端完全沒必要存儲（當(dāng)然，我們討論的是技術(shù)理想情況，實際上拋開技術(shù)因素來說，這么多豐富的用戶行為數(shù)據(jù)你是運營方你會放過嗎？但，這跟技術(shù)無關(guān)對吧）。

離線消息的收發(fā)：當(dāng)接收方不在線時，發(fā)送方的聊天數(shù)據(jù)在服務(wù)端只需要作短因果報應(yīng)存儲，因為接收方一旦上線就拉走了，服務(wù)器刪除即可（注意：從技術(shù)上來說就是這樣的哦）。對用戶而言聊天消息的社會學(xué)的本質(zhì)來說就像兩個人在對話，我已經(jīng)聽見你說的就好了，干嗎老像復(fù)讀機一樣一遍一遍一說給我聽？

正如上述所言，IM系統(tǒng)中最重要的聊天數(shù)據(jù)從技術(shù)上不說其實是沒有存儲的必要的。不過話雖如此，但一個大型的IM系統(tǒng)的方方面面數(shù)據(jù)量也是很可觀的，所以開發(fā)IM系統(tǒng)時討論服務(wù)端數(shù)據(jù)庫的讀寫分離、水平分表等，是很有必要的。因而通過本文快速理解服務(wù)端數(shù)據(jù)庫的讀寫分離原理你不應(yīng)錯過，本文也同時建議您在正確理解它的前提下再慎重決定您的服務(wù)端架構(gòu)方案是否需要數(shù)據(jù)庫讀寫分離，因為很多時候增加緩存策略就能解決的問題，就沒有必在大炮打蚊子了。

好了，費話多說了幾句，我們開始閱讀正文。

2、相關(guān)文章

▼?跟IM數(shù)據(jù)存儲架構(gòu)有關(guān)的文章，有如下幾篇，或許對你有用：

• 《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機QQ的圖片傳輸速度和成功率》
• 《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》
• 《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
• 《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

IM開發(fā)干貨系列文章適合作為IM開發(fā)熱點問題參考資料

• 《IM開發(fā)基礎(chǔ)知識補課(一)：正確理解前置HTTP SSO單點登陸接口的原理》
• 《IM開發(fā)基礎(chǔ)知識補課(二)：如何設(shè)計大量圖片文件的服務(wù)端存儲架構(gòu)？》

?

3、什么是數(shù)據(jù)庫讀寫分離？

如上圖所示，一主多從、讀寫分離、主動同步，是一種常見的數(shù)據(jù)庫架構(gòu)。

一般來說：
?

• 主庫——提供數(shù)據(jù)庫寫服務(wù)；
• 從庫——提供數(shù)據(jù)庫讀服務(wù)。

主從庫之間，通過某種機制同步數(shù)據(jù)，例如mysql的binlog。

像上述圖中這樣，一個主從同步集群通常被稱為一個“分組”。

那么，數(shù)據(jù)庫“分組”架構(gòu)究竟解決什么問題？

大部分互聯(lián)網(wǎng)業(yè)務(wù)讀多寫少，數(shù)據(jù)庫的讀往往最先成為性能瓶頸，如果希望：
?

• 線性提升數(shù)據(jù)庫讀性能；
• 通過消除讀寫鎖沖突提升數(shù)據(jù)庫寫性能；
• 此時可以使用分組架構(gòu)。

一句話總結(jié)：“分組”主要解決“數(shù)據(jù)庫讀性能瓶頸”問題，在數(shù)據(jù)庫扛不住讀的時候，用“分組”架構(gòu)實現(xiàn)讀寫分離，通過增加從庫線性提升系統(tǒng)讀性能。

4、什么是數(shù)據(jù)庫水平切分？

如上圖所示，跟數(shù)據(jù)庫“分組”架構(gòu)實現(xiàn)讀寫分離一樣，水平切分（也稱大表拆分、分表），也是一種常見的數(shù)據(jù)庫架構(gòu)手段。

一般來說：
?

• 每個數(shù)據(jù)庫之間沒有數(shù)據(jù)重合，沒有類似binlog同步的關(guān)聯(lián)；
• 所有數(shù)據(jù)并集，組成全部數(shù)據(jù)；
• 會用算法，來完成數(shù)據(jù)分割，例如“取?！?#xff1b;

一個水平切分集群中的每一個數(shù)據(jù)庫，通常稱為一個“分片”。

水平切分架構(gòu)究竟解決什么問題？

大部分互聯(lián)網(wǎng)業(yè)務(wù)數(shù)據(jù)量很大，單庫容量容易成為瓶頸，如果希望：
?

• 線性降低單庫數(shù)據(jù)容量；
• 線性提升數(shù)據(jù)庫寫性能；
• 此時可以使用水平切分架構(gòu)。

一句話總結(jié)：數(shù)據(jù)庫水平切分架構(gòu)主要解決“數(shù)據(jù)庫數(shù)據(jù)量大”（或者更細(xì)一點說是單表數(shù)據(jù)量太大）問題，在數(shù)據(jù)庫容量扛不住的時候，通常水平切分。

5、數(shù)據(jù)庫讀寫分離雖好，但不應(yīng)濫用

對于互聯(lián)網(wǎng)大數(shù)據(jù)量、高并發(fā)量、高可用要求高、一致性要求高、前端面向用戶的業(yè)務(wù)場景，如果數(shù)據(jù)庫讀寫分離：
?

• 數(shù)據(jù)庫連接池需要區(qū)分：讀連接池，寫連接池；
• 如果要保證讀高可用，讀連接池要實現(xiàn)故障自動轉(zhuǎn)移；
• 有潛在的主庫從庫一致性問題。

實際上，如果您的系統(tǒng)面臨的是“讀性能瓶頸”問題，增加緩存可能來得更直接，更容易一點。

另外，從成本上說，從庫的成本比緩存高不少。而且對于云上的架構(gòu)，以阿里云為例，主庫提供高可用服務(wù)，從庫不提供高可用服務(wù)，實現(xiàn)方案上更主流。

所以，上述業(yè)務(wù)場景下，建議使用緩存架構(gòu)來加強系統(tǒng)讀性能，替代數(shù)據(jù)庫主從分離架構(gòu)。

當(dāng)然，使用緩存架構(gòu)的潛在問題：如果緩存掛了，流量全部壓到數(shù)據(jù)庫上，數(shù)據(jù)庫會雪崩。不過幸好，云上的緩存一般都提供高可用的服務(wù)。

6、簡單小結(jié)

典型的大型互聯(lián)應(yīng)用架構(gòu)中，服務(wù)端數(shù)據(jù)庫架構(gòu)主要使用以下兩種：
?

• 使用“分組”架構(gòu)實現(xiàn)數(shù)據(jù)庫讀寫分離：解決“數(shù)據(jù)庫讀性能瓶頸”問題；
• 使用“分片”架構(gòu)實現(xiàn)數(shù)據(jù)庫水平切分：解決“數(shù)據(jù)庫數(shù)據(jù)量大”問題。

但對于互聯(lián)網(wǎng)大數(shù)據(jù)量、高并發(fā)量、高可用要求高、一致性要求高、前端面向用戶的業(yè)務(wù)場景，使用微服務(wù)緩存架構(gòu)，很多時候可能比數(shù)據(jù)庫讀寫分離架構(gòu)更合適。

網(wǎng)易云信，你身邊的即時通訊和音視頻技術(shù)專家，了解我們，請戳網(wǎng)易云信官網(wǎng)

想要行業(yè)洞察和技術(shù)干貨，請關(guān)注網(wǎng)易云信博客

本文轉(zhuǎn)載自52im,作者：JackJiang

總結(jié)

以上是生活随笔為你收集整理的IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。