共計 1252 個字符，預計需要花費 4 分鐘才能閱讀完成。
Riak 請求過程是什么以及 Riak 有幾種失敗場景，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
CAP 原理告訴我們，一致性，可用性和分區容忍性三者最多只能偏重其中兩個。在 NoSQL 系統中，分區容忍性 (P) 幾乎已經成為必選項。于是很多 NoSQL 選擇了犧牲一定一致性的做法。下面丸趣 TV 丸趣 TV 小編來講解下 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 中。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。
