1、前言

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

那么為什么說IM系統的服務端從技術上說，是不需要存儲聊天數據的呢？

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

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

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

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

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

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

2、相關文章

▼?跟IM數據存儲架構有關的文章，有如下幾篇，或許對你有用：

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

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

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

?

3、什么是數據庫讀寫分離？

如上圖所示，一主多從、讀寫分離、主動同步，是一種常見的數據庫架構。

一般來說：
?

• 主庫——提供數據庫寫服務；
• 從庫——提供數據庫讀服務。

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

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

那么，數據庫“分組”架構究竟解決什么問題？

大部分互聯網業務讀多寫少，數據庫的讀往往最先成為性能瓶頸，如果希望：
?

• 線性提升數據庫讀性能；
• 通過消除讀寫鎖沖突提升數據庫寫性能；
• 此時可以使用分組架構。

一句話總結：“分組”主要解決“數據庫讀性能瓶頸”問題，在數據庫扛不住讀的時候，用“分組”架構實現讀寫分離，通過增加從庫線性提升系統讀性能。

4、什么是數據庫水平切分？

如上圖所示，跟數據庫“分組”架構實現讀寫分離一樣，水平切分（也稱大表拆分、分表），也是一種常見的數據庫架構手段。

一般來說：
?

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

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

水平切分架構究竟解決什么問題？

大部分互聯網業務數據量很大，單庫容量容易成為瓶頸，如果希望：
?

• 線性降低單庫數據容量；
• 線性提升數據庫寫性能；
• 此時可以使用水平切分架構。

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

5、數據庫讀寫分離雖好，但不應濫用

對于互聯網大數據量、高并發量、高可用要求高、一致性要求高、前端面向用戶的業務場景，如果數據庫讀寫分離：
?

• 數據庫連接池需要區分：讀連接池，寫連接池；
• 如果要保證讀高可用，讀連接池要實現故障自動轉移；
• 有潛在的主庫從庫一致性問題。

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

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

所以，上述業務場景下，建議使用緩存架構來加強系統讀性能，替代數據庫主從分離架構。

當然，使用緩存架構的潛在問題：如果緩存掛了，流量全部壓到數據庫上，數據庫會雪崩。不過幸好，云上的緩存一般都提供高可用的服務。

6、簡單小結

典型的大型互聯應用架構中，服務端數據庫架構主要使用以下兩種：
?

• 使用“分組”架構實現數據庫讀寫分離：解決“數據庫讀性能瓶頸”問題；
• 使用“分片”架構實現數據庫水平切分：解決“數據庫數據量大”問題。

但對于互聯網大數據量、高并發量、高可用要求高、一致性要求高、前端面向用戶的業務場景，使用微服務緩存架構，很多時候可能比數據庫讀寫分離架構更合適。

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

想要行業洞察和技術干貨，請關注網易云信博客

本文轉載自52im,作者：JackJiang

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。