數(shù)據(jù)復(fù)制與一致性

2 數(shù)據(jù)復(fù)制與一致性2.2 一致性模型分類

2.3 副本更新策略

2.4一致性協(xié)議2.2 一致性模型分類1.一致性模型關(guān)系圖2.定義以下場景及術(shù)語來說明各種一致性的具體含義：A,B,C：代表3個(gè)獨(dú)立的進(jìn)程，這些進(jìn)程會(huì)對NoSQL數(shù)據(jù)庫里的數(shù)據(jù)進(jìn)行讀/寫操作。x：NoSQL數(shù)據(jù)庫中的某條數(shù)據(jù)。v1,v2,v3：數(shù)據(jù)x的不同取值。Write(Item,Value):代表某進(jìn)程的一次寫操作，將Item的值更新為Value。Read(Item,Value):代表某進(jìn)程的一次讀操作，即讀出Item的值為Value。Notify(p1,p2,Item,Value):代表進(jìn)程p1通知進(jìn)程p2將Item的值更新為Value。2.2.1 強(qiáng)一致性在數(shù)據(jù)庫的所有進(jìn)程中，當(dāng)更新完成，后續(xù)所有訪問都將獲得更新值。弱一致性：即系統(tǒng)不能保證后續(xù)訪問都將獲得更新值。2.2.2 最終一致性在對x做出操作后，與最終看到新數(shù)值之前，存在一個(gè)時(shí)間片段，在這個(gè)時(shí)間片段內(nèi)，數(shù)據(jù)也許是不一致的，即“不一致窗口”。2.2.3 因果一致性因果一致性發(fā)生在進(jìn)程之間有因果依賴關(guān)系的情形下。進(jìn)程A與進(jìn)程C沒有因果依賴關(guān)系，則遵循最終一致性。2.2.4 “讀你所寫”一致性“讀你所寫”一致性是因果一致性的特例。更新操作后，進(jìn)程A后續(xù)訪問到的都是新數(shù)值，其他進(jìn)程并未受影響。2.2.5 會(huì)話一致性“會(huì)話一致性”是“讀你所寫”一致性的變體。當(dāng)進(jìn)程A通過會(huì)話與數(shù)據(jù)庫系統(tǒng)連接，同一個(gè)會(huì)話內(nèi)，可以保證“讀你所寫”一致性，若會(huì)話終止，進(jìn)程A的數(shù)值則會(huì)不一定。2.2.6 單調(diào)讀一致性最終一致性的另一種變體。如果某個(gè)進(jìn)程讀取到數(shù)據(jù)x的一個(gè)數(shù)值，那么后續(xù)所有訪問將不會(huì)返回任何之前的值。2.2.7 單調(diào)寫一致性另外一種最終一致性的變體。對于某個(gè)進(jìn)程來說，單調(diào)寫一致性可以保證其多次寫操作的序列化，同時(shí)也保證了應(yīng)用開發(fā)者的順利開發(fā)。在實(shí)際的存儲(chǔ)系統(tǒng)中，可以綜合使用以上的一致性模型。2.3 副本更新策略2.3.1同時(shí)更新類型AB有無一致性協(xié)議沒有任何，直接更新有是否有執(zhí)行順序無，多個(gè)節(jié)點(diǎn)交叉有，唯一確定數(shù)據(jù)是否一致不一致一致2.3.2 主從式更新類型A：同步方式B：異步方式C：混合方式含義主副本等待所有從副本更新完成后才確認(rèn)更新操作完成主副本在通知從副本更新之前即可確認(rèn)更新操作主副本首先同步更新從副本數(shù)據(jù)，然后確認(rèn)更新操作完成，其他副本通過異步方式獲得更新異步方式根據(jù)讀操作的響應(yīng)方式，可分為兩種情形根據(jù)讀操作的響應(yīng)方式，可分為兩種情形任意一個(gè)副本接收到讀請求后，將其轉(zhuǎn)發(fā)給主副本任意一個(gè)副本都可響應(yīng)讀請求同時(shí)更新了好多節(jié)點(diǎn)，至少要讀出一個(gè)新數(shù)值對讀出的數(shù)值沒有要求優(yōu)點(diǎn)強(qiáng)一致性保證了強(qiáng)一致性請求延時(shí)大大降低強(qiáng)一致性-缺點(diǎn)請求延時(shí)較大請求延時(shí)增加結(jié)果不一致問題請求延時(shí)增大讀不一致問題2.3.3 任意節(jié)點(diǎn)更新數(shù)據(jù)更新請求可能發(fā)給多副本中的任意一個(gè)節(jié)點(diǎn)，然后由這個(gè)節(jié)點(diǎn)來負(fù)責(zé)通知其他副本進(jìn)行數(shù)據(jù)更新。請求延時(shí)和一致性權(quán)衡有以下兩種情形：類型A：同步通知其他副本B：異步通知其他副本特點(diǎn)與“主從式更新”類型A類似存在和“同時(shí)更新”及“主從式更新”策略類型B類似的問題2.4 一致性協(xié)議2.4.1兩階段提交協(xié)議（Two-PhraseCommit,2PC）含義：在大數(shù)據(jù)環(huán)境下，代表要么所有備份數(shù)據(jù)同時(shí)更改某個(gè)數(shù)值，要么都不更改。兩類實(shí)體：唯一的協(xié)調(diào)者，眾多的參與者。兩階段提交過程：協(xié)調(diào)者的有限狀態(tài)機(jī)：參與者的有限狀態(tài)機(jī)：

從剛才的狀態(tài)機(jī)中可以看出，協(xié)調(diào)者的等待狀態(tài)，參與者的初始狀態(tài)和準(zhǔn)備狀態(tài)都需要等待對方的反饋信息，進(jìn)入了阻塞狀態(tài)，而且很可能因有進(jìn)程陷入崩潰而導(dǎo)致處于阻塞態(tài)的對象進(jìn)入長時(shí)間的等待。為了解決這種情況，引入：超時(shí)判斷機(jī)制和參與者互詢機(jī)制。進(jìn)程Q狀態(tài)處于困境的參與者P的動(dòng)作COMMITCOMMITABORTABORTINITABORTREADY與其他參與者聯(lián)系為了解決長時(shí)阻塞，提出了三階段提交協(xié)議（3PC）：2.4.2 向量時(shí)鐘（VectorClock）向量時(shí)鐘的作用Alice、Ben、Cathy和Dave四人約定下周一起聚餐，四個(gè)人通過郵件商量聚餐的時(shí)間。Alice首先建議周三聚餐。之后Dave和Catby商量覺得周四更合適。后來Dave又和Ben商量之后覺得周二也行。最后Alice要匯總大家的意見，得到的反饋如下：Cathy說，他和Dave商量的時(shí)間是周四Ben說，他和Dave商量的時(shí)間是周三此時(shí)恰好聯(lián)系不上Dave，而且不知道Cathy和Ben分別與Dave確定時(shí)間的先后順序，Alice就不能確定到底該定在哪天了。簡單地說，就是為每個(gè)商議結(jié)果加上一個(gè)時(shí)間戳，當(dāng)結(jié)果改變時(shí)，更新時(shí)間戳向量時(shí)鐘的更新規(guī)則1.每次修改數(shù)據(jù)，本節(jié)點(diǎn)的版本號加1;2.當(dāng)進(jìn)程發(fā)送消息時(shí)，會(huì)將自己的向量時(shí)鐘和消息m同時(shí)發(fā)送出;3.每次同步數(shù)據(jù)(同步和修改是不一樣的寫操作哦),會(huì)有三種情況：本節(jié)點(diǎn)的向量版本與消息攜帶過來的向量版本關(guān)系操作<=取每個(gè)分量的最大值>直接丟棄要同步的版本出現(xiàn)沖突，有的分量版本大，有的分量版本小沖突仲裁2.4.3 RWN協(xié)議這是對多備份數(shù)據(jù)如何讀寫成功進(jìn)行靈活配置，達(dá)到數(shù)據(jù)一致性。說明成功寫入的備份集合和成功讀取的備份集合一定會(huì)存在交集，保證了讀取操作一定可以讀到最新的數(shù)據(jù)版本。字母NWR含義在分布式存儲(chǔ)系統(tǒng)中，有多少份備份數(shù)據(jù)代表一次成功的更新操作要求至少有W份數(shù)據(jù)寫入成功代表一次成功的讀數(shù)據(jù)操作至少有r份數(shù)據(jù)成功讀取若R+W>N，則可稱為滿足“數(shù)據(jù)一致性協(xié)議”2.4.4 Paxos協(xié)議1.副本狀態(tài)機(jī)模型在實(shí)現(xiàn)副本狀態(tài)機(jī)中的一致性協(xié)議時(shí)，追求以下特性：安全性保證：即非拜占庭模型下，狀態(tài)機(jī)從不返回錯(cuò)誤的結(jié)果，多個(gè)提議中只有一個(gè)被選中