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

2021-09-19 03:01:40 字數 2666 閱讀 2892

今天打算寫寫關於 im 去中心化涉及的架構模型變化和設計思路,去中心化的概念就是說使用者的訪問不是集中在乙個資料中心,這裡的去中心是針對資料中心而言的。

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

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

im 的中心化架構並不意味著只有乙個資料中心,它也可以是多資料中心的,如下圖。

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

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

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

這裡的變化是為「座標」增加乙個「資料中心」緯度,當按通用的方式去本地儲存定位使用者時,發現乙個非本地的座標時訊息該怎麼投遞?這裡可以在每個本地資料中心額外新增乙個訊息閘道器程式,註冊到本地儲存中,並負責接收所有非本地座標的訊息,這有點像路由網路中的邊界閘道器。

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

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

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

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

上面描述了一種臨界場景,在這種臨界場景下,使用者收訊息存在延時。而這種臨界場景實際上並不是常態,而且 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,而再算上程式開銷,這個延時很可能在數秒內波動,這個量級的延時對於少數的臨界場景是完全可以接受的。

本文的標題是概念模型,但它不像另外一篇《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

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

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

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

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

超級 App 手機百度雲端架構設計與個性化推薦

下面是此次技術沙龍活動雲端分會場的主題演講概要總結 手百個性化在設計的時候就考慮了精準豐富的使用者標籤,包括使用者本身的資訊,如性別 年齡 職業 教育與消費等,還有使用者的目的如興趣 關注 需求。豐富的標籤在手百的實際使用中起到很重要的作用,可以進行卡片推薦,幫助個性化解決冷啟動問題,幫助產品更加了...