文章目錄

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

簡介

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

在一個pacificA架構(gòu)中主要有兩個模塊

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

Replica Group：這個主要是用來完成業(yè)務(wù)數(shù)據(jù)的存儲工作

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

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

1. pacificA中的一些名詞

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

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

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

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

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

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

Prepared List：Update操作的準(zhǔn)備序列。

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

2. Replica Group 的工作模式

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

1. 正常讀寫模式

1. 讀，Query

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

2. 寫 Update

Update流程如下：

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

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

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

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

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

這里也可以看出primary是領(lǐng)先secondary的。

2. primary 和secondary之間的交互

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

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

如何保證當(dāng)一個Replica認(rèn)為自己是Primary時，Configuration Manager中維護(hù)的Configuration也認(rèn)為其是當(dāng)前的Primary。任何時候，最多只有一個Replica認(rèn)為自己是這個Replica Group的Primary呢。

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

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

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

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

1. Secondary故障

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

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

2. Primary故障

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

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

3. secondary增加

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。