概念：去中心化的概念就是說用戶的訪問不是集中在一個(gè)數(shù)據(jù)中心，這里的去中心是針對(duì)數(shù)據(jù)中心而言的。
站在這個(gè)角度而言，實(shí)際上并非所有的業(yè)務(wù)都能做去中心化設(shè)計(jì)，對(duì)于一致性要求越高的業(yè)務(wù)去中心化越難做。比如電商領(lǐng)域的庫存就是一個(gè)對(duì)一致性要求很高的業(yè)務(wù)，不能超賣也不能少賣，這在單中心容易實(shí)現(xiàn)，但多中心純從技術(shù)層面感覺無解，可能需要從業(yè)務(wù)和技術(shù)層面一起去做個(gè)折衷。
反過來看 IM 的業(yè)務(wù)場(chǎng)景是非常適合做去中心化設(shè)計(jì)的，因?yàn)槠錁I(yè)務(wù)場(chǎng)景都是弱一致性需求。打開你的微信或 QQ 仔細(xì)觀察下，對(duì)大部分人來說與你聯(lián)系頻繁的實(shí)際多是在地域上離你近的人，人與人之間的心理距離和物理距離會(huì)隨著時(shí)間漸趨保持一致。所以根據(jù)這個(gè)特點(diǎn)，按地域來分布數(shù)據(jù)中心和聚合人群是比較合適的。
在進(jìn)入去中心化 IM 架構(gòu)模型之前，我們先看看中心化架構(gòu)是怎樣的，分析其關(guān)鍵設(shè)計(jì)再來看如果要去中心化需要做哪些變化？
1、中心化
IM 的中心化架構(gòu)并不意味著只有一個(gè)數(shù)據(jù)中心，它也可以是多數(shù)據(jù)中心的，如下圖。
我們這里只分析下實(shí)現(xiàn) IM 消息互通這個(gè)重要場(chǎng)景下共享數(shù)據(jù)存儲(chǔ)里需要存些什么數(shù)據(jù)呢？一個(gè)是用戶上線后的「座標(biāo)」，主要指用戶本次在線接入了哪臺(tái)機(jī)器的哪根連接，這個(gè)「座標(biāo)」用于在線消息投遞。而另一方面若用戶離線時(shí)，別人給它發(fā)消息，這些消息也需要存儲(chǔ)下來，一般稱為用戶的「離線消息」，下次用戶上線就可以自動(dòng)收取自己的離線消息。
中心化架構(gòu)實(shí)際能做到的就是把讀實(shí)現(xiàn)自有數(shù)據(jù)中心閉環(huán)，而寫依然需要向主數(shù)據(jù)中心所在的存儲(chǔ)寫入。而 IM 的寫入場(chǎng)景還不算是一個(gè)低頻操作，那么要實(shí)現(xiàn)去中心化架構(gòu)關(guān)鍵點(diǎn)就在如何解決寫的問題上。
2、去中心化
在設(shè)計(jì)IM的去中心化架構(gòu)之前，希望去實(shí)現(xiàn)這個(gè)架構(gòu)并編寫代碼時(shí)，不需要去考慮終部署到底是去中心的還是中心的。編碼時(shí)就像開發(fā)中心化架構(gòu)一樣去實(shí)現(xiàn)場(chǎng)景的功能，而去中心化的能力做為純基礎(chǔ)的技術(shù)能力，通過附加的方式來獲得，先看看架構(gòu)圖的變化，如下。
消息網(wǎng)關(guān)統(tǒng)一接收應(yīng)當(dāng)發(fā)往其他數(shù)據(jù)中心的消息，以實(shí)現(xiàn)跨數(shù)據(jù)中心的消息流轉(zhuǎn)。這里有個(gè)疑問是其他數(shù)據(jù)中心的「座標(biāo)」是怎么跑到本地來的？離線消息的場(chǎng)景又該如何處理呢？關(guān)于這兩個(gè)問題，就涉及到我們解決跨數(shù)據(jù)中心同步數(shù)據(jù)的關(guān)鍵技術(shù)了。
3、關(guān)鍵技術(shù)
結(jié)合 IM 的業(yè)務(wù)場(chǎng)景，實(shí)際它對(duì)同步的延時(shí)具有一定的容忍度。所以我覺得基于 Gossip 協(xié)議的小道消息傳播特性就能很好的滿足這個(gè)同步場(chǎng)景。
關(guān)于 Gossip 我是在新近的 NoSQL 數(shù)據(jù)庫 Cassandra 上聽說的，后來 Redis Cluster 也利用了該協(xié)議來實(shí)現(xiàn)無中心化集群架構(gòu)。但 Gossip 協(xié)議可不是什么新東西，實(shí)際關(guān)于它的誕生可以追溯到好幾十年前的施樂研究中心，就是為了解決數(shù)據(jù)庫同步問題被我們的前前前輩想出來的。
這個(gè)協(xié)議的靈感來自于辦公室小道消息的傳播路徑，當(dāng)一個(gè)人知道了一條小道消息，他碰到一個(gè)朋友并隨口告訴了他，朋友又告訴了朋友的朋友，沒多久整個(gè)辦公室都知道了，也就完成了信息的同步。借用這個(gè)模型，實(shí)際上我們需要同步的信息就是用戶的在線「座標(biāo)」和「離線消息」。
因?yàn)?Gossip 自好幾十年前已經(jīng)有很多論文證明并公開發(fā)表，而且近年也有 Cassandra 和 Redis 的成功工程實(shí)踐，所以我就先不用去懷疑其可行性，而是直接利用其結(jié)論了。根據(jù)其特性，分析 IM 的去中心場(chǎng)景在引入 Gossip 后有些什么可供觀察的變化和值得注意的方面。
在一個(gè)稍具規(guī)模的 IM 場(chǎng)景下，用戶總是在上上下下，消息也在不停的在「在線」和「離線」之間變化，所以需要通過 Gossip 同步的信息是時(shí)時(shí)存在的。所以假設(shè)我們?cè)谀硞€(gè)時(shí)刻去拍一個(gè)快照（實(shí)際做不到），得到的結(jié)果是多個(gè)數(shù)據(jù)中心的數(shù)據(jù)肯定是不一致的，幾乎不存在所謂的全局終一致性的某一時(shí)刻。在這樣的客觀環(huán)境下，對(duì) IM 的業(yè)務(wù)場(chǎng)景有多大影響？
當(dāng)用戶A在 IDC#1 在線，用戶B 在 IDC#2 剛上線，這里存在一個(gè)同步時(shí)差，那么此時(shí)用戶A給用戶B發(fā)消息，在本地沒有用戶B的座標(biāo)，所以進(jìn)入離線消息池。用戶B此時(shí)不能立刻收到用戶A的消息，但離線消息池會(huì)在隨后通過 Gossip 協(xié)議同步到用戶B所在的 IDC#2，用戶B此時(shí)就可以通過離線消息收取用戶A的消息。
上面描述了一種臨界場(chǎng)景，在這種臨界場(chǎng)景下，用戶收消息存在延時(shí)。而這種臨界場(chǎng)景實(shí)際上并不是常態(tài)，而且 IM 用戶實(shí)際對(duì)這種剛上線的消息延時(shí)存在很高的容忍度。這一點(diǎn)我想大家用 QQ 可能體會(huì)過，有時(shí)一上線都一分鐘了，還會(huì)收到之前的離線消息，我不知道這是有意的延時(shí)還是真有這么長的系統(tǒng)延時(shí)。
那么使用 Gossip 協(xié)議從理論上來估算下會(huì)產(chǎn)生多久的延時(shí)？假設(shè)我們?cè)谌珖鴸|西南北中各部署一個(gè)數(shù)據(jù)中心，一共五個(gè)。五個(gè)數(shù)據(jù)中心之間無專線，走公網(wǎng)互通，網(wǎng)絡(luò)延時(shí) 200 ms。使用 Gossip 完成在五個(gè)數(shù)據(jù)中心的終一致性同步需要多長時(shí)間？這里我直接引用 Gossip 論文結(jié)論：
Cycles = log(N) + ln(N) + O(1)
當(dāng) N=5 時(shí)，完成全部同步，需要節(jié)點(diǎn)間私下傳播的次數(shù)，套用公式得到 3.3 次，取整得 4 次。按網(wǎng)絡(luò)延時(shí) 200 ms，每次 Gossip 交換信息間隔 100 ms，那么協(xié)議本身固有延時(shí)大約 4×200 + 4×100 = 1.2s，而再算上程序開銷，這個(gè)延時(shí)很可能在數(shù)秒內(nèi)波動(dòng)，這個(gè)量級(jí)的延時(shí)對(duì)于少數(shù)的臨界場(chǎng)景是完全可以接受的。
4、總結(jié)
本文的標(biāo)題是概念模型，但它不像另外一篇《RPC 的概念模型與實(shí)現(xiàn)解析》跟了實(shí)現(xiàn)解析，說明這只是一個(gè)理論推導(dǎo)。因?yàn)槔锩骊P(guān)鍵的是如何配合 Gossip 的共享存儲(chǔ)似乎沒有找到特別適合的產(chǎn)品，要是自己做一個(gè)呢就會(huì)產(chǎn)生一種今天只想出去兜兜風(fēng)，卻要先自己動(dòng)手造輛車的感覺。
粵嵌科技創(chuàng)辦于2005年是一家IT高新技術(shù)企業(yè)，專注IT職業(yè)教育13年，主要培訓(xùn)課程分別有嵌入式培訓(xùn)、Java培訓(xùn)、Unity游戲開發(fā)、Python人工智能、HTML5前端開發(fā)、全棧UI設(shè)計(jì)、網(wǎng)絡(luò)營銷、CCIE網(wǎng)絡(luò)等專業(yè)課程