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