現代IM系統中消息推送和存儲架構的實現

時間 2019-12-07

原文原文鏈接

前言

IM全稱是『Instant Messaging』，中文名是即時通信。在這個高度信息化的移動互聯網時代，生活中IM類產品已經成爲必備品，比較有名的如釘釘、微信、QQ等以IM爲核心功能的產品。固然目前微信已經成長爲一個生態型產品，但其核心功能仍是IM。還有一些非以IM系統爲核心的應用，最典型的如一些在線遊戲、社交應用，IM也是其重要的功能模塊。能夠說，帶有社交屬性的應用，IM功能必定是必不可少的。html

IM系統在互聯網初期即存在，其基礎技術架構在這十幾年的發展中更新迭代屢次，從早期的CS、P2P架構，到如今後臺已經演變爲一個複雜的分佈式系統，涉及移動端、網絡、安全和存儲等技術的方方面面。其支撐的規模也從早期的少許日活，到如今微信這個巨頭最新公佈的達到9億的日活的體量。數據庫

IM系統中最核心的部分是消息系統，消息系統中最核心的功能是消息的同步和存儲：緩存

消息的同步：將消息完整的、快速的從發送方傳遞到接收方，就是消息的同步。消息同步系統最重要的衡量指標就是消息傳遞的實時性、完整性以及能支撐的消息規模。從功能上來講，通常至少要支持在線和離線推送，高級的IM系統還支持『多端同步』。
消息的存儲：消息存儲即消息的持久化保存，這裏不是指消息在客戶端本地的保存，而是指雲端的保存，功能上對應的就是『消息漫遊』。『消息漫遊』的好處是能夠實現帳號在任意端登錄查看全部歷史消息，這也是高級IM系統特有的功能之一。

本篇文章內容主要涉及IM系統中的消息系統架構，會介紹一種基於TableStore構建的消息同步以及存儲系統的架構實現，可以支持消息系統中的高級特性『多端同步』以及『消息漫遊』。在性能和規模上，可以作到全量消息雲端存儲，百萬TPS以及毫秒級延遲的消息同步能力。安全

架構設計

本章主要會介紹基於TableStore的現代IM消息系統的架構設計，在詳細介紹架構設計以前，會先介紹一種Timeline邏輯模型，來抽象和簡化對IM消息同步和存儲模型的理解。理解了Timeline模型後，會介紹如何基於此模型對消息的同步以及存儲進行建模。基於Timeline模型，在實現消息同步和存儲時還會有各方面的技術權衡，例如如何對消息同步常見的讀擴散和寫擴散兩種模型進行對比和選擇，以及針對Timeline模型的特徵如何來選擇底層數據庫。微信

傳統架構 vs 現代架構

上圖是消息系統傳統架構與現代架構的簡單對比。網絡

傳統架構下，消息是先同步後存儲。對於在線的用戶，消息會直接實時同步到在線的接收方，消息同步成功後，並不會進行持久化。而對於離線的用戶或者消息沒法實時同步成功時，消息會持久化到離線庫，當接收方從新鏈接後，會從離線庫拉取全部未讀消息。當離線庫中的消息成功同步到接收方後，消息會從離線庫中刪除。傳統的消息系統，服務端的主要工做是維護髮送方和接收方的鏈接狀態，並提供在線消息同步和離線消息緩存的能力，保證消息必定可以從發送方傳遞到接收方。服務端不會對消息進行持久化，因此也沒法支持消息漫遊。架構

現代架構下，消息是先存儲後同步。先存儲後同步的好處是，若是接收方確認接收到了消息，那這條消息必定是已經在雲端保存了。而且消息會有兩個庫來保存，一個是消息存儲庫，用於全量保存全部會話的消息，主要用於支持消息漫遊。另外一個是消息同步庫，主要用於接收方的多端同步。消息從發送方發出後，通過服務端轉發，服務端會先將消息保存到消息存儲庫，後保存到消息同步庫。完成消息的持久化保存後，對於在線的接收方，會直接選擇在線推送。但在線推送並非一個必須路徑，只是一個更優的消息傳遞路徑。對於在線推送失敗或者離線的接收方，會有另一個統一的消息同步方式。接收方會主動的向服務端拉取全部未同步消息，但接收方什麼時候來同步以及會在哪些端來同步消息對服務端來講是未知的，因此要求服務端必須保存全部須要同步到接收方的消息，這是消息同步庫的主要做用。對於新的同步設備，會有消息漫遊的需求，這是消息存儲庫的主要做用，在消息存儲庫中，能夠拉取任意會話的全量歷史消息。分佈式

以上是傳統架構和現代架構的一個簡單的對比，現代架構上整個消息的同步和存儲流程，並無變複雜太多，可是其能實現多端同步以及消息漫遊。現代架構中最核心的就是兩個消息庫『消息同步庫』和『消息存儲庫』，是消息同步和存儲最核心的基礎。而本篇文章接下來的部分，都是圍繞這兩個庫的設計和實現來展開。性能

2017雲棲社區之星評選暨年度頒獎盛典_投票便可參與抽獎
阿里雲

我有幾張阿里雲幸運券分享給你，用券購買或者升級阿里雲相應產品會有特惠驚喜哦！把想要買的產品的幸運券都領走吧！快下手，立刻就要搶光了。