概念：去中心化的概念就是說用戶的訪問不是集中在一個數據中心，這里的去中心是針對數據中心而言的。
站在這個角度而言，實際上并非所有的業務都能做去中心化設計，對于一致性要求越高的業務去中心化越難做。比如電商領域的庫存就是一個對一致性要求很高的業務，不能超賣也不能少賣，這在單中心容易實現，但多中心純從技術層面感覺無解，可能需要從業務和技術層面一起去做個折衷。
反過來看 IM 的業務場景是非常適合做去中心化設計的，因為其業務場景都是弱一致性需求。打開你的微信或 QQ 仔細觀察下，對大部分人來說與你聯系頻繁的實際多是在地域上離你近的人，人與人之間的心理距離和物理距離會隨著時間漸趨保持一致。所以根據這個特點，按地域來分布數據中心和聚合人群是比較合適的。
在進入去中心化 IM 架構模型之前，我們先看看中心化架構是怎樣的，分析其關鍵設計再來看如果要去中心化需要做哪些變化？
1、中心化
IM 的中心化架構并不意味著只有一個數據中心，它也可以是多數據中心的，如下圖。
我們這里只分析下實現 IM 消息互通這個重要場景下共享數據存儲里需要存些什么數據呢？一個是用戶上線后的「座標」，主要指用戶本次在線接入了哪臺機器的哪根連接，這個「座標」用于在線消息投遞。而另一方面若用戶離線時，別人給它發消息，這些消息也需要存儲下來，一般稱為用戶的「離線消息」，下次用戶上線就可以自動收取自己的離線消息。
中心化架構實際能做到的就是把讀實現自有數據中心閉環，而寫依然需要向主數據中心所在的存儲寫入。而 IM 的寫入場景還不算是一個低頻操作，那么要實現去中心化架構關鍵點就在如何解決寫的問題上。
2、去中心化
在設計IM的去中心化架構之前，希望去實現這個架構并編寫代碼時，不需要去考慮終部署到底是去中心的還是中心的。編碼時就像開發中心化架構一樣去實現場景的功能，而去中心化的能力做為純基礎的技術能力，通過附加的方式來獲得，先看看架構圖的變化，如下。
消息網關統一接收應當發往其他數據中心的消息，以實現跨數據中心的消息流轉。這里有個疑問是其他數據中心的「座標」是怎么跑到本地來的？離線消息的場景又該如何處理呢？關于這兩個問題，就涉及到我們解決跨數據中心同步數據的關鍵技術了。
3、關鍵技術
結合 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，而再算上程序開銷，這個延時很可能在數秒內波動，這個量級的延時對于少數的臨界場景是完全可以接受的。
4、總結
本文的標題是概念模型，但它不像另外一篇《RPC 的概念模型與實現解析》跟了實現解析，說明這只是一個理論推導。因為里面關鍵的是如何配合 Gossip 的共享存儲似乎沒有找到特別適合的產品，要是自己做一個呢就會產生一種今天只想出去兜兜風，卻要先自己動手造輛車的感覺。
粵嵌科技創辦于2005年是一家IT高新技術企業，專注IT職業教育13年，主要培訓課程分別有嵌入式培訓、Java培訓、Unity游戲開發、Python人工智能、HTML5前端開發、全棧UI設計、網絡營銷、CCIE網絡等專業課程