您好,登錄后才能下訂單哦!
Riak請求過程是什么以及Riak有幾種失敗場景,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
CAP原理告訴我們,一致性,可用性和分區容忍性三者最多只能偏重其中兩個。在NoSQL系統中,分區容忍性(P)幾乎已經成為必選項。于是很多NoSQL選擇了犧牲一定一致性的做法。下面億速云小編來講解下Riak請求過程是什么?Riak有幾種失敗場景?
Riak請求過程是什么
首先介紹一下Riak的請求處理過程,以數據冗余N份存儲,每次讀取其中的R份,寫操作需要寫W份。
通過計算得出請求的key所在的N個節點
向這N個節點依次發起請求
等待這N個節點中的W個(如果是寫操作的)或R個(如果是讀操作)返回成功
返回相應的數據給客戶端。
Riak有幾種失敗場景
1.讀取數據前其中一個節點故障
數據以W=3成功寫入三份
其中一個節點故障
數據再以R=3讀取三份,發起三個請求
此次讀操作會返回了not_found
而這次系統在檢測到了數據只有兩份,會啟動修復器將數據備份一份到secondary節點上,以保證有三份備份
后續的讀操作將會從primary上讀到兩份,從secondary上讀到一份數據,以實現成功讀到三份數據。
2.讀取數據前其中兩個節點故障
數據以W=3成功寫入三份
其中兩個節點故障
數據再以R=3讀取三份,發起三個請求
此次讀操作會返回了not_found
后續的讀操作將會從primary上讀到一份,從secondary上讀到兩份數據,以實現成功讀到三份數據。
3.讀取數據前三個節點全部故障
數據以W=3成功寫入三份
其中三個節點故障
數據讀取操作將會永遠返回not_found,直到某個節點恢復
4.寫操作前一個節點故障
一個節點故障
數據以W=3發起三個寫請求
一個secondary節點承擔了其中的一個寫請求
后面的讀請求會正常的讀到三份數據
5.寫操作前一個節點故障,后來又恢復了
一個節點故障
數據以W=3發起三個寫請求
一個secondary節點承擔了其中的一個寫請求
故障節點又恢復了
在60秒內,一個叫hintedhandoff的過程會啟動,將secondary中的數據遷移到剛剛恢復的primary中
在hintedhandoff過程完成后,數據就恢復正常了
6.在hintedhandoff過程中進行讀寫操作
在hintedhandoff過程中,由于原來的primary節點是啟動的,所以數據讀寫操作都會到這個節點上來執行,這時候可能由于一些值還沒有備份回來,所以會導致這個節點暫時的not_found返回。
7.在兩個primary節點故障后一個又恢復期間進行讀寫操作
這時候剛剛恢復的節點會進行hintedhandoff過程,而讀寫操作依然會由于not_found的發生而啟動修復器進行數據備份到secordary中。
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注億速云行業資訊頻道,感謝您對億速云的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。