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

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

2.3 副本更新策略

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

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