今天打算寫寫關於 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，那麼協議本身固有延時大約 4×200 + 4×100 = 1.2s，而再算上程式開銷，這個延時很可能在數秒內波動，這個量級的延時對於少數的臨界場景是完全可以接受的。
總結
本文的標題是概念模型，但它不像另外一篇《RPC 的概念模型與實現解析》跟了實現解析，說明這只是一個理論推導。因為裡面最關鍵的是如何配合 Gossip 的共享儲存似乎沒有找到特別適合的產品，要是自己做一個呢就會產生一種今天只想出去兜兜風，卻要先自己動手造輛車的感覺。
參考
[1]. Wikipedia. Gossip protocol. 2016.03.29
[2]. ALVARO VIDELA. GOSSIP PROTOCOLS, WHERE TO START. 2015.12.02
[3]. Anne-Marie et al. Gossiping in Distributed Systems. 2007
[4]. Márk Jelasity. Gossip Protocols
[5]. Alberto Montresor. Gossip protocols for large-scale distributed systems. 2010
寫點程式世間的文字，畫點生活瞬間的畫兒。
微信公眾號「瞬息之間」，遇見了不妨就關注看看。