Redis 集羣的高可用性

在本文中,我們將研究以下主題:

•Redis 集羣的高可用性。•Redis 集羣的自動故障轉移。•Redis 集羣中的腦裂問題及其解決方案。

問題: Redis-Cluster 如何提供高可用性?

答案: 高可用性是指集羣在面臨某些故障時仍能保持操作能力。例如,集羣可以檢測到主分片失敗並在無需外部手動干預的情況下將副本提升爲主分片。

問題: Redis-Cluster 如何提供自動故障轉移?

答案: Redis-Cluster 可以迅速瞭解主分片何時失敗,並且可以將其副本晉升爲新主分片。

• 假設我們爲每個主分片都有一個副本。如果我們的數據分佈在三個 Redis 服務器之間,我們將需要一個六成員的集羣,其中三個主分片和三個副本。• 所有六個分片通過 TCP 相互連接,並不斷地相互 ping 並交換消息。這些消息允許集羣確定哪些分片是活動的。• 當足夠多的分片報告給定主分片未響應它們時,它們可以同意觸發故障轉移,並將分片的副本提升爲新的主分片。在觸發故障轉移之前需要同意離線同行的分片數量在集羣創建時是可配置的。

問題: 用 Redis-Cluster 演示腦裂的情況?

答案: 以下是腦裂情況的演示方式:

步驟#1: 想象一下,我們有一個具有三個主分片和每個主分片一個副本的 Redis-Cluster。總體而言,我們的 Redis 集羣是一個六成員的集羣,其中有三個主分片和三個副本。進一步想象,網絡分區已經發生,即左側的組將無法與右側的組中的分片通信。

• 現在,兩個集羣組都認爲它們處於脫機狀態,兩者都將觸發任何主分片的故障轉移,導致左側具有所有主分片,右側也將具有所有主分片。

步驟#2: 兩側認爲它們具有所有主分片,將繼續接收修改數據的客戶端請求。這是一個問題,因爲也許客戶端 A 在左側將鍵 foo 的值設置爲 bar,但客戶端 B 在右側將相同鍵的值設置爲 baz

步驟#3: 當網絡分區被刪除並且分片嘗試重新連接時,我們將會有衝突,因爲我們有兩個保存不同數據的分片,聲稱是主分片,我們不會知道哪些數據是有效的。這稱爲腦裂情況,在分佈式系統的世界中是一個非常常見的問題。

問題: 如何解決腦裂的問題?

答案: 在集羣中保持奇數個主分片和每個主分片兩個副本。以下是解決此問題的詳細解決方案:

• 爲防止在 Redis 集羣中發生一種稱爲腦裂情況的情況,始終保持奇數個分片。• 現在,當我們得到網絡分割時,左側和右側的組將進行計數,並查看它們是在更大的(多數)還是更小的組(少數)?• 如果特定組處於少數,它將不嘗試觸發故障轉移,並且將不接

受任何客戶端寫入請求。

讓我們來看看下面的集羣:

現在,假設發生網絡分割,如下所示:

• 在這裏,左側組(節點集合)處於少數,因此它不會嘗試觸發故障轉移,並將停止接受任何客戶端寫入請求。• 右側組(節點集合)處於多數,因此它具有觸發任何主分片故障轉移的權限和能力。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/nh4On4u_739EXgo8OVEXBA