IM 去中心化概念模型與架構設計

今天打算寫寫關於 IM 去中心化涉及的架構模型變化和設計思路，去中心化的概念就是說用戶的訪問不是集中在一個數據中心，這裡的去中心是針對數據中心而言的。站在這個角度而言，實際上並非所有的業務都能做去中心化設計，對於一致性要求越高的業務去中心化越難做。比如電商領域的庫存就是一個對一致性要求很高的業務， ...

今天打算寫寫關於 IM 去中心化涉及的架構模型變化和設計思路，去中心化的概念就是說用戶的訪問不是集中在一個數據中心，這裡的去中心是針對數據中心而言的。

站在這個角度而言，實際上並非所有的業務都能做去中心化設計，對於一致性要求越高的業務去中心化越難做。比如電商領域的庫存就是一個對一致性要求很高的業務，不能超賣也不能少賣，這在單中心容易實現，但多中心純從技術層面感覺無解，可能需要從業務和技術層面一起去做個折衷。

反過來看 IM 的業務場景是非常適合做去中心化設計的，因為其業務場景都是弱一致性需求。打開你的微信或 QQ 仔細觀察下，對大部分人來說與你聯繫最頻繁的實際多是在地域上離你最近的人，人與人之間的心理距離和物理距離會隨著時間漸趨保持一致。所以根據這個特點，按地域來分佈數據中心和聚合人群是比較合適的。

在進入去中心化 IM 架構模型之前，我們先看看中心化架構是怎樣的，分析其關鍵設計再來看如果要去中心化需要做哪些變化？

中心化

IM 的中心化架構並不意味著只有一個數據中心，它也可以是多數據中心的，如下圖。

之所以說它是中心化架構，關鍵特征是其存在共用的數據存儲。部署在兩個數據中心的應用需要共用訪問統一的數據存儲，而這種共用訪問實際是依賴數據中心之間的專線連通，這樣的架構也限制了能選取的數據中心地理位置的距離。而實現去中心架構的關鍵點就在於規避跨數據中心的共用存儲訪問，使得應用在其自身數據中心實現訪問閉環。

我們這裡只分析下實現 IM 消息互通這個最重要場景下共用數據存儲里需要存些什麼數據呢？一個是用戶上線後的「座標」，主要指用戶本次線上接入了哪台機器的哪根連接，這個「座標」用於線上消息投遞。而另一方面若用戶離線時，別人給它發消息，這些消息也需要存儲下來，一般稱為用戶的「離線消息」，下次用戶上線就可以自動收取自己的離線消息。

中心化架構實際能做到的極致就是把讀實現自有數據中心閉環，而寫依然需要向主數據中心所在的存儲寫入。而 IM 的寫入場景還不算是一個低頻操作，那麼要實現去中心化架構關鍵點就在如何解決寫的問題上。

去中心化

在設計 IM 的去中心化架構之前，希望去實現這個架構並編寫代碼時，不需要去考慮最終部署到底是去中心的還是中心的。編碼時就像開發中心化架構一樣去實現場景的功能，而去中心化的能力做為純基礎的技術能力，通過附加的方式來獲得，先看看架構圖的變化，如下。

這裡的變化是為「座標」增加一個「數據中心」緯度，當按通用的方式去本地存儲定位用戶時，發現一個非本地的座標時消息該怎麼投遞？這裡可以在每個本地數據中心額外添加一個消息網關程式，註冊到本地存儲中，並負責接收所有非本地座標的消息，這有點像路由網路中的邊界網關。

消息網關統一接收應當發往其他數據中心的消息，以實現跨數據中心的消息流轉。這裡有個疑問是其他數據中心的「座標」是怎麼跑到本地來的？離線消息的場景又該如何處理呢？關於這兩個問題，就涉及到我們解決跨數據中心同步數據的關鍵技術了。

關鍵技術

結合 IM 的業務場景，實際它對同步的延時具有一定的容忍度。所以我覺得基於 Gossip 協議的小道消息傳播特性就能很好的滿足這個同步場景。

關於 Gossip 我是在新近的 NoSQL 資料庫 Cassandra 上聽說的，後來 Redis Cluster 也利用了該協議來實現無中心化集群架構。但 Gossip 協議可不是什麼新東西，實際關於它的誕生可以追溯到好幾十年前的施樂研究中心，就是為瞭解決資料庫同步問題被我們的前前前輩想出來的。

這個協議的靈感來自於辦公室小道消息的傳播路徑，當一個人知道了一條小道消息，他碰到一個朋友並隨口告訴了他，朋友又告訴了朋友的朋友，沒多久整個辦公室都知道了，也就完成了信息的同步。借用這個模型，實際上我們需要同步的信息就是用戶的線上「座標」和「離線消息」。

因為 Gossip 自好幾十年前已經有很多論文證明並公開發表，而且近年也有 Cassandra 和 Redis 的成功工程實踐，所以我就先不用去懷疑其可行性，而是直接利用其結論了。根據其特性，分析 IM 的去中心場景在引入 Gossip 後有些什麼可供觀察的變化和值得註意的方面。

在一個稍具規模的 IM 場景下，用戶總是在上上下下，消息也在不停的在「線上」和「離線」之間變化，所以需要通過 Gossip 同步的信息是時時存在的。所以假設我們在某個時刻去拍一個快照（實際做不到），得到的結果是多個數據中心的數據肯定是不一致的，幾乎不存在所謂的全局最終一致性的某一時刻。在這樣的客觀環境下，對 IM 的業務場景有多大影響？

當用戶A在 IDC#1 線上，用戶B 在 IDC#2 剛上線，這裡存在一個同步時差，那麼此時用戶A給用戶B發消息，在本地沒有用戶B的座標，所以進入離線消息池。用戶B此時不能立刻收到用戶A的消息，但離線消息池會在隨後通過 Gossip 協議同步到用戶B所在的 IDC#2，用戶B此時就可以通過離線消息收取用戶A的消息。

上面描述了一種臨界場景，在這種臨界場景下，用戶收消息存在延時。而這種臨界場景實際上並不是常態，而且 IM 用戶實際對這種剛上線的消息延時存在很高的容忍度。這一點我想大家用 QQ 可能體會過，有時一上線都一分鐘了，還會收到之前的離線消息，我不知道這是有意的延時還是真有這麼長的系統延時。

那麼使用 Gossip 協議從理論上來估算下會產生多久的延時？假設我們在全國東西南北中各部署一個數據中心，一共五個。五個數據中心之間無專線，走公網互通，網路延時最大 200 ms。使用 Gossip 完成在五個數據中心的最終一致性同步最大需要多長時間？這裡我直接引用 Gossip 論文結論：

Cycles = log(N) + ln(N) + O(1)

當 N=5 時，完成全部同步，需要節點間私下傳播的次數，套用公式得到 3.3 次，取整得 4 次。按最大網路延時 200 ms，每次 Gossip 交換信息間隔 100 ms，那麼協議本身固有延時大約 4x200 + 4x100 = 1.2s，而再算上程式開銷，這個延時很可能在數秒內波動，這個量級的延時對於少數的臨界場景是完全可以接受的。