實時訊息RTM| 多活架構中的資料一致性問題

一，容災方案

之前介紹過RTM的系統架構設計，其中有說到我們的容災設計的是雙活和多活。有很多小夥伴問到為什麼不採用主從架構設計，以及多活容災怎麼做到資料一致性等問題。這裡我們針對容災和多活設計進行詳細介紹。

容災的方案有很多，最常見的就是主備容災，最初版本我們也採用了主機+冷備機容災模式：Client正常與Master連線進行通訊，正常情況下只有主機提供服務；在主機出故障時，仲裁服務切換主備，原來的主機下線變成備機，原備機變成主機後為Client提供服務。

一主機一備機的模型設計簡單，並且具有不錯的可用性——畢竟主備兩臺機器同時不可用的概率極低，相信很多後臺系統也採用了類似的容災策略。

主備容災存在一些明顯的缺陷，比如備機閒置導致有一半的空閒機器；比如主備切換的時候，備機在瞬間要接受主機所有的請求，容易導致備機過載。既然一主一備容災存在這樣的問題，為什麼還有大量的公司採用這種容災模型？事實上，架構的選擇往往跟專案背景有關，大多數情況專案需要的機器數少，機器冗餘不是主要問題；其次主備架構簡單穩定，可以快速開發，快速上線。

由於RTM系統對併發的要求非常高，同時由於專案對裝置的使用率要求較高，所以我們採用了多活架構。

多活架構中每臺機器都能為客戶端提供服務，如果其中一臺宕機或發生故障，Client只需要連線相同區域內其他的服務即可。多活架構可是使得機器的利用率最大化，降低服務運營的成本，同時對於運維來說也相對簡單，當發生流量峰值時只需要平行增加機器即可，當流量較低時，可以減少機器；動態增加或減少機器對於成本的控制非常有效。多活架構看似非常美好，對於技術人員來說使用多活架構需要解決的技術難題非常多，其中一個就是分散式資料一致性問題。

二，一致性演算法

一致性就是資料保持一致，在分散式系統中，可以理解為多個節點中資料的值是一致的。

1，為什麼需要一致性 a)資料不能存在單個節點（主機）上，否則可能出現單點故障。

b)多個節點（主機）需要保證具有相同的資料。

c)一致性演算法就是為了解決上面兩個問題。

2，一致性的分類 a)強一致性 說明：保證系統改變提交以後立即改變叢集的狀態。 模型： Paxos Raft（muti-paxos） ZAB（muti-paxos）

b)弱一致性 說明：也叫最終一致性，系統不保證改變提交以後立即改變叢集的狀態，但是隨著 時間的推移最終狀態是一致的。 模型： DNS系統 Gossip協議 具體的一致性演算法的介紹大家可以自行搜尋，其中的一些思想非常值得去深究，都是大牛們智慧的結晶。

RTM系統中有個非常經典的場景，一個群組裡面有N個人分佈在不同的區域，這時候有些人同時對群組的某一個相同屬性進行修改；屬性的修改需要通知群裡的所有人，這個時候如果沒有資料一致性的保證，有極大的可能會導致群裡的N個人中一部分人收到的資料去其他人收不到的不一樣，如果是這樣對於業務來說是致命的。

多個人在不同地點同時對屬性A進行修改，由於網路的波動延時，導致Client-D、E、F收到的順序完全不同；最終呈現的屬性值也不同。因此我們參考了Paxos演算法的一些思想：

P1： 一個Acceptor必須接受它收到的第一個議案。

P2： 如果一個值為v的議案被選定了，那麼被選定的更大編號的議案，它的值必須也是v。

P2a： 如果一個值為v的議案被選定了，那麼Acceptor接受的更大編號的議案，它的值必須也是v。

P2b： 如果一個值為v的議案被選定了，那麼Proposer提出的更大編號的議案，它的值必須也是v。

P2c： 在所有Acceptor中，任意選取半數以上的Acceptor集合，我們稱這個集合為S。Proposal新提出的議案（簡稱Pnew）必須符合下面兩個條件之一：

1）如果S中所有Acceptor都沒有接受過議案的話，那麼Pnew的編號保證唯一性和遞增即可，Pnew的值可以是任意值。   2）如果S中有一個或多個Acceptor曾經接受過議案的話，要先找出其中編號最大的那個議案，假設它的編號為N，值為V。那麼Pnew的編號必須大於N，Pnew的值必須等於V。

演算法的推導過程理解起來還是比較困難，我們大致總結了其核心點：一致性演算法不是演算法保證資料一致，他保證的是你資料寫入順序的一致。如果資料寫入順序一致，最終的結果肯定是一樣的。

比如上面我們提到的經典場景，我們只要保證所有客戶端收到的屬性的順序是一致的，不論屬性是213，還是312，只要大家都是這個順序，那麼最終每個客戶端上的最終屬性值肯定是一樣的。

三，總結

任何架構和演算法最終都是服務於實際的業務，並不是一種架構勝任所有，應當從多角度、多維度找到適合的方案才是最優解。