文章目錄

• • 簡介
  • 1. pacificA中的一些名詞
  • 2. Replica Group 的工作模式
  • • 1. 正常讀寫模式
    • • 1. 讀，Query
      • 2. 寫 Update
    • 2. primary 和secondary之間的交互
    • 3. 非正常模式下的邏輯處理
    • • 1. Secondary故障
      • 2. Primary故障
      • 3. secondary增加

簡介

??pacificA協議算是一個分布式的架構解決方案，在正常的分布式系統中，比如hdfs，kafka，elasticsearch中，系統對整個集群的元數據的管理需求和對本身存儲的業務數據的管理需求是不同的。
??比如，元數據一般采用leader寫入模式，而且要求具備線性化的讀寫，但是這部分的數據一般是量不大，一致性要求高，盡可能的提供更高的可用性，但是對于業務數據,可能需要備份的數量不同(備份的數量和可用性一般是成反比的)，pacificA的存在就是為了試圖優化這個問題，簡化系統設計。
??在滿足線性化讀寫的分布式系統中，目前的系統設計都是由master進行寫入，然后像follower進行同步，假如master不會宕機，那么是可以永遠滿足分布式一致性的，通常都是有問題了應該如何處理這一塊兒，現在大部分系統都是進行master選舉，這一塊兒也引入了系統了復雜度。如果我們對業務系統設計成一個master永遠不會掛掉（這里不是真的物理上不會掛掉，而是通過一些措施來保證），而且只管理業務數據的一致性系統，集群的元數據的一致性就交給另外的模塊去管理，這樣是不是就舒服很多了。而pacificA的設計理念就是這樣的。

在一個pacificA架構中主要有兩個模塊

Configuration Manager: 扮演上帝角色，主要負責集群的元數據信息的一致性維護，同時也負責replica group的管理工作

Replica Group：這個主要是用來完成業務數據的存儲工作

在這種設計模式下，pacificA沒有強調Configuration Manager,你可以使用任何一個分布式一致性協議(raft,zab,viewstamp),或者是借助zookeeper來實現，然后他主要介紹的是如何實現Replica Group的實現，以及Configuration Manager如何和Replica Group交互和管理Replica Group。

下面文章敘述的大部分參考阿里大佬王懷遠的這篇文章

1. pacificA中的一些名詞

Replica Group：一個互為副本的數據集合叫做Replica Group，每個副本是一個Replica。一個Replica Group中只有一個副本是Primary，其余為Secondary。

Configuration：一個Replica Group的Configuration描述了這個Replica Group包含哪些副本，其中Primary是誰等。

Configuration Version：Configuration的版本號，每次Configuration發生變更時加1。

Configuration Manager: 管理Configuration的全局組件，其保證Configuration數據的一致性。Configuration變更會由某個Replica發起，帶著Version發送給Configuration Manager，Configuration Manager會檢查Version是否正確，如果不正確則拒絕更改。

Query & Update：對一個Replica Group的操作分為兩種，Query和Update，Query不會改變數據，Update會更改數據。

Serial Number(sn)：代表每個Update操作執行的順序，每次Update操作加1，為連續的數字。

Prepared List：Update操作的準備序列。

Committed List：Update操作的提交序列，提交序列中的操作一定不會丟失(除非全部副本掛掉)。在同一個Replica上，Committed List一定是Prepared List的前綴。

2. Replica Group 的工作模式

Replica Group和raft協議中的leader和follower構成的一個集群一樣，如果比較具體的就是ES的某個shard的primary shard和replica shard共同構成的group就是Replica Group,接下來來看一下假如對于client的讀寫操作，Replica Group是如何處理的呢。

1. 正常讀寫模式

1. 讀，Query

Query流程比較簡單，Query只能發送給Primary，Primary根據最新commit的數據，返回對應的值。由于算法要求滿足Primary Invariant，所以Query總是能讀到最新commit的數據。

2. 寫 Update

Update流程如下：

Primary分配一個Serial Number(簡稱sn)給一個UpdateRequest。

Primary將這個UpdateRequest加入自己的Prepared List，同時向所有Secondary發送Prepare請求，要求將這個UpdateRequest加入Prepared List。

當所有Replica都完成了Prepare，即所有Replica的Prepared List中都包含了該Update請求時，Primary開始Commit這個請求，即將這個UpdateRequest放入Committed List中，同時Apply這個Update。需要注意的是，同一個Replica上，Committed List永遠是Prepared List的前綴，所以Primary實際上是提高Committed Point，把這個Update Request包含進來。

返回客戶端，Update操作成功。

需要注意的是，這里的第2步結束后并不會想zab當中那樣立刻廣播commit消息，而是像raft當中的那樣，當下一次Primary向Secondary發送新的數據同步請求時，會帶上Primary當前的Committed Point，此時Secondary才會提高自己的Committed Point。

這里也可以看出primary是領先secondary的。

2. primary 和secondary之間的交互

primary要定期的使用心跳來檢測secondary是否還活著，如果secondary不再存活了，那么primary就要向Configuration Manager報告，進而讓Configuration Manager將這個secondary從Replica Group中剔除。

同樣的，secondary也要檢測primary是否存活，如果secondary聯系不上primary，那么secondary就需要向Configuration Manager報告，進而從secondary中選一個做primary。

如何保證當一個Replica認為自己是Primary時，Configuration Manager中維護的Configuration也認為其是當前的Primary。任何時候，最多只有一個Replica認為自己是這個Replica Group的Primary呢。

論文給出的一種方法是通過Lease機制，這也是分布式系統中常用的一種方式。具體來說，Primary會定期獲取一個Lease，獲取之后認為某段時間內自己肯定是Primary，一旦超過這個時間還未獲取到新的Lease就退出Primary狀態。只要各個機器的CPU不出現較大的時鐘漂移，那么就能夠保證Lease機制的有效性。

論文中實現Lease機制的方式是，Primary定期向所有Secondary發送心跳來獲取Lease，而不是所有節點都向某個中心化組件獲取Lease。這樣的好處是分散了壓力，不會出現中心化組件故障而導致所有節點失去Lease的情況。

同時這個Lease的時長應該 >> primary對secondary的健康檢查間隔時間 , 然后secondary對leader不存在的超時判斷要結合健康檢查和Lease的時長。這樣才能避免出現了兩個leader的情況。

3. 非正常模式下的邏輯處理

1. Secondary故障

??當一個Secondary故障時，Primary向Configuration Manager發起Reconfiguration，將故障節點從Replica Group中刪除。一旦移除這個Replica，它就不屬于這個Replica Group了，所有請求都不會再發給它。

??假設某個Primary和Secondary發生了網絡分區，但是都可以連接Configuration Manager。這時候Primary會檢測到Secondary沒有響應了，Secondary也會檢測到Primary沒有響應。此時兩者都會試圖發起Reconfiguration，將對方從Replica Group中移除，這里的策略是First Win的原則，誰先到Configuration Manager中更改成功，誰就留在Replica Group里，而另外一個已經不屬于Replica Group了，也就無法再更新Configuration了。但是如果一個好好工作的primary因為某個不靠譜的secondary頻繁發生網絡分區而頻繁更換primary也是很痛苦的事兒。所以在上面也提到了,由于Primary會向Secondary請求一個Lease，在Lease有效期內Secondary不會執行Reconfiguration，而Primary的探測間隔必然是小于Lease時間的，所以我認為這種情況下總是傾向于Primary先進行Reconfiguration，將Secondary剔除。

2. Primary故障

??當一個Primary故障時，Secondary會收不到Primary的心跳，如果超過Lease的時間，那么Secondary就會發起Reconfiguration，將Primary剔除，這里也是First Win的原則，哪個Secondary先成功，就會變成Primary。

??當一個Secondary變成Primary后，需要先經過一個叫做Reconciliation的階段才能提供服務。這個也就和zab中leader選出來提交一個空的log，zab中的synchronization是一樣的作用，保持Replica Group中的數據和primary對齊。原先的Primary的Committed List一定是新的Primary的Prepared List的前綴，那么我們將新的Primary的Prepared List中的內容與當前Replica Group中的其他節點對齊，相當于把該節點上未Commit的記錄在所有節點上再Commit一次，那么就一定包含之前所有的Commit記錄。

3. secondary增加

??新加的節點需要先成為Secondary Candidate，這時候Primary就開始向其發送Prepare請求，此時這個節點還會追之前未同步過來的記錄，一旦追平，就申請成為一個Secondary，然后Primary向Configuration Manager發起配置變更，將這個節點加入Replica Group。

??還有一種情況是，如果一個節點曾經在Replica Group中，由于臨時發生故障被移除，現在需要重新加回來。此時這個節點上的Commited List中的數據肯定是已經被Commit的了，但是Prepared List中的數據未必被Commit，所以應該將未Commit的數據移除，從Committed Point開始向Primary請求數據。

也可以參考這一篇不太成熟的翻譯來加強理解

總結

以上是生活随笔為你收集整理的pacificA架构介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。