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

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

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

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

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

中心化

码报开奖结果本期 www.iwqgw.icu IM 的中心化架構并不意味著只有一個數據中心,它也可以是多數據中心的,如下圖。

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

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

undefined

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

去中心化

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

undefined

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

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

關鍵技術

結合 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,而再算上程序開銷,這個延時很可能在數秒內波動,這個量級的延時對于少數的臨界場景是完全可以接受的。

來源:mindwind

上一篇: Java程序員的日?!樘ù扛苫酰?/a>

下一篇: Java Scripting API 使用示例

分享到: 更多
必中pk10手机计划软件安卓版 pk10手机直播开奖 网络棋牌 北京pk10官方投注平台 幸运飞艇6码2期免费计划 比分网即时比分500 彩名堂计划软件# 重庆时时彩龙虎和漏洞 排列五小凯机器人软件 重大时时彩三星走势图 彩票阶梯投注方案 pk10苹果手机软件下载中心 非凡聚合计划 体球网即时比分手机版 微信群里玩大小单双 安徽时时计划软件手机版下载手机版下载手机版下载