一致性雜湊的實際應用

前言

今天重看了一下一致性雜湊的論文，心裡有幾處不清楚的地方，求指導

情境

四台server伺服器（192.168.1.1-4），redis資料庫，儲存key-value索引值對

問題1

首先，redis的key-value資料一般需要3份備份，對應到一致性雜湊的情境，可以說有一台主伺服器，和2台從伺服器。問題：從伺服器的選取是一致性雜湊碼裡選取三個不同的server，還是選取一個server，然後給這個server再配上兩台從伺服器呢（這樣伺服器從原先的4台，增加到4 + 2 * 4 = 12台），我考慮用memcache記錄key、主、從分布表

問題2

如果冗餘到其他兩台伺服器，假設是A\B\C\D四台伺服器，key的主庫是A，備份庫在BC上，那當A單點故障，BC之間如何選擇，BC上針對A節點的增刪改資料如何再恢複給A節點嗎？我看了NRW模型，但是沒能完全理解

解答1

群裡有人提示，伺服器端可以用HAproxy+Keepalived實現每個機器主備模式，其實相當於一致性雜湊的環上真正只有4個可用的target，卻需要8台伺服器來完成

回複內容：

前言

今天重看了一下一致性雜湊的論文，心裡有幾處不清楚的地方，求指導

情境

四台server伺服器（192.168.1.1-4），redis資料庫，儲存key-value索引值對

問題1

首先，redis的key-value資料一般需要3份備份，對應到一致性雜湊的情境，可以說有一台主伺服器，和2台從伺服器。問題：從伺服器的選取是一致性雜湊碼裡選取三個不同的server，還是選取一個server，然後給這個server再配上兩台從伺服器呢（這樣伺服器從原先的4台，增加到4 + 2 * 4 = 12台），我考慮用memcache記錄key、主、從分布表

問題2

如果冗餘到其他兩台伺服器，假設是A\B\C\D四台伺服器，key的主庫是A，備份庫在BC上，那當A單點故障，BC之間如何選擇，BC上針對A節點的增刪改資料如何再恢複給A節點嗎？我看了NRW模型，但是沒能完全理解

解答1

群裡有人提示，伺服器端可以用HAproxy+Keepalived實現每個機器主備模式，其實相當於一致性雜湊的環上真正只有4個可用的target，卻需要8台伺服器來完成

根據樓主想要使用一致性雜湊演算法來看，基本上是把redis當做緩衝使用，而不是資料庫；

而使用一致性雜湊的主要目的通常都是：當叢集中機器數量發生變化時，減少緩衝失效範圍，防止“雪崩”；

在這種情況下，我想到了另一個問題：是不是一定要用雜湊一致性演算法？

按照我的想法，根據redis目前提供的一些特性，或許使用下面這種常見架構，就能解決剛才的問題;

1台master，n台slave，然後採取讀寫分離的方式，master處理寫請求，slave負責處理讀請求（負載平衡）

這種部署方式有什麼優勢？

• 當業務訪問量猛增時，我們可以快速新增一台redis機器，連上master，當完成主從複製後， 放入到slave叢集，開始對外提供服務；

• 當slave叢集中有一台機器掛掉後，可以通過某種機制被識別（借鑒sentinel），並將它從slave叢集中踢出；

這樣子無論slave叢集如何變化，都不會出現cache失效或者部分失效問題;

這種部署方式有什麼劣勢？

• redis目前主從複製過程有個很不好的地方就是：當slave和master在同步過程中，網路出現問題，這時候slave要求master重傳而不是續傳（重建一份RDB檔案然後傳輸）；這樣當master中資料很多的時候，影響會很大，所以一個master下掛多個slave穩定性會下降；

以上僅為個人一點想法，拿出來和樓主探討

這兩天看了一點架構的東西，這個問題基本可以關閉了

解決方案

1. 還是採用8個server，主備的方式，採用一致性雜湊演算法增加節點伺服器可以通過虛擬節點和權重來防止資料位移，這裡的節點伺服器可以用VIP來標識

2. 主備伺服器之間可以採用keepalived方案，對外提供的是虛擬ip，自動容錯移轉，至於主備伺服器的資料庫同步，可以用redis提供的主從機制，也可以自己crontab+aof日誌，可以再redis資料庫上再封裝一層insert或者update操作，對外提供api介面，需要操作時訪問該介面即可

