Redis採用數據分區和主從模式實現了分佈式集羣管理方式，數據分區實現了橫向擴展，主從模式實現了故障恢復。
Redis集羣示意圖
數據分區
Redis集羣將數據分區後存儲在多個節點上，即不同的分區存儲在不同的節點上，每個節點可以存儲多個分區。每個分區在Redis中也被稱爲“hash slot”，Redis集羣中總共規劃了16384個分區。
例如：當集羣中有3個節點時，節點A將包含0-5460分區，節點B將包含5461-10922分區，節點C將包含10923-16383分區。
每個key將會存儲到一個唯一的分區中，每個分區其實就是一組key的集合，兩者對應關係爲：key的CRC16校驗碼%16384=hash slot（分區標記）.可見Redis並沒有像Memecache一樣使用一致性哈希。社區說採用此規則的key分佈是相當的均勻，在我們的測試中也印證了這一點。
在Redis集羣中添加或者移除一個節點時相當容易的事情。例如：添加新節點D時，需要做的只是從A、B、C節點中移動一些分區給D。類似的，移除A時，只需將原屬A的分區移動給B和C，等A變空時移除即可。
節點間的分區移動不需要停止服務，所以添加節點、移除節點或者改變節點的分區數量不需要停止集羣服務。
客戶端訪問集羣時，理論上可以訪問集羣中的任一節點。此時，被訪問的數據可能不存在於被訪問的節點中，但是被訪問節點能自動獲知目標節點，並重定向客戶端的訪問，即將目標節點地址返回給客戶端，客戶端再次發起訪問請求。當然，好的客戶端工具應該實現數據分區和節點對應關係的緩存，並在對應關係發生改變時能自動更新。目前，包括Jedis在內的幾個客戶端工具已經實現了此功能。
主-從模型（master-slave model）
Redis集羣採用了主-從模型，即一個節點可以有N個副本，其中一個爲主節點，N-1個爲從節點。
主-從模型可以應對集羣中部分節點故障的場景。例如：在上述集羣的例子中，如果節點B發生故障，由於分區5461-10922不能訪問，所以集羣會不可用。如果每個主節點有一個從節點，即A、B、C爲主節點，A1、B1、C1爲從節點。此時，如果B節點故障，集羣則推舉B1作爲新的主節點，集羣對外服務正常。
注意：1.從節點可在集羣創建時添加，也可後向追加。2.如果B和B1同時發生故障，則集羣仍然不可用。
Redis集羣中，每個節點需要使用兩個TCP連接。第一個端口服務於客戶端，例如默認的端口6379。第二個端口值總是在第一個之上增加10000，例如：16379.
第二個端口用於集羣總線，這是一個使用二進制協議的節點和節點之間的通信通道。集羣總線可用於失敗檢測、配置更新、故障轉移授權等。客戶端只使用第一個端口，從來不會使用第二個端口。
一個主節點可以有多個從節點。當從節點首次或者重連主節點時，主節點會進行後臺存儲，即將數據snapshot爲磁盤上的rdb文件，也將rdb文件發給從節點進行存儲。後臺存儲過程中以及之後的產生的寫操作，主節點都會異步的發送到從節點，從節點執行這些操作以保證數據同步。默認情況下，從節點對客戶端只提供讀服務。
由於主從之間是異步傳輸，所以存在丟失數據的風險。例如：客戶端寫主節點B，B回覆客戶端OK，B傳送寫操作到從節點B1、B2和B3. 由於B在回覆客戶端前，不會等待從節點的確認。所以如果此時B發生故障，雖然從節點會被推舉出一個主節點，但是還沒有傳送到從節點的數據將永遠丟失了。
