今天小編就爲大家分享一篇關於Redis cluster集羣的介紹，小編覺得內容挺不錯的，現在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧
1.前言
Redis集羣模式主要有2種:
主從集羣、分佈式集羣。
前者主要是爲了高可用或是讀寫分離，後者爲了更好的存儲數據，負載均衡。
redis集羣提供了以下兩個好處
1、將數據自動切分(split)到多個節點
2、當集羣中的某一個節點故障時，redis還可以繼續處理客戶端的請求。
一個 redis 集羣包含 16384 個哈希槽（hash slot），數據庫中的每個數據都屬於這16384個哈希槽中的一個。集羣使用公式 CRC16(key) % 16384 來計算鍵 key 屬於哪個槽。集羣中的每一個節點負責處理一部分哈希槽。
集羣中的主從複製
集羣中的每個節點都有1個至N個複製品，其中一個爲主節點，其餘的爲從節點，如果主節點下線了，集羣就會把這個主節點的一個從節點設置爲新的主節點，繼續工作。這樣集羣就不會因爲一個主節點的下線而無法正常工作
注意：
1、如果某一個主節點和他所有的從節點都下線的話，redis集羣就會停止工作了。redis集羣不保證數據的強一致性，在特定的情況下，redis集羣會丟失已經被執行過的寫命令
2、使用異步複製（asynchronous replication）是redis 集羣可能會丟失寫命令的其中一個原因，有時候由於網絡原因，如果網絡斷開時間太長，redis集羣就會啓用新的主節點，之前發給主節點的數據就會丟失。
2. 主從切換原理
Redis的主從原理與MySQL相似，都是設置兩臺機器，一主一從。也就是常說的熱備與冷備。設置主從的同時，設置兩個哨兵進程，用來檢測主節點是否宕機。若發現主節點宕機，立馬從從節點內選取出合適的節點 作爲新的主節點。這點與VIP(虛擬IP技術有點相似)。
3.Redis羣集TCP端口
每個Redis羣集的節點都需要打開兩個TCP連接，由於這兩個連接就需要兩個端口，分別是用於爲客戶端提供服務的常規Redis TCP命令端口（例如6379）以及通過將10000和命令端口相加（10000+6379）而獲得的端口，就是集羣端口（例如16379）。
第二個大號端口用於羣集總線，即使用二進制協議的節點到節點通信通道。 節點使用羣集總線進行故障檢測，配置更新，故障轉移授權等。 客戶端不應嘗試與羣集總線端口通信，爲了保證Redis命令端口的正常使用，請確保在防火牆中打開這兩個端口，否則Redis羣集節點將無法通信。
命令端口和集羣總線端口偏移量是固定的，始終爲10000。
請注意，爲了讓Redis羣集正常工作，您需要爲每個節點：
1、用於與客戶端進行通信的普通客戶端通信端口（通常爲6379）對所有需要到達羣集的客戶端以及所有其他羣集節點（使用客戶端端口進行密鑰遷移）都是開放的。
2、集羣總線端口（客戶端端口+ 10000）必須可從所有其他集羣節點訪問。
如果您不打開這兩個TCP端口，則您的羣集將無法正常工作。
集羣總線使用不同的二進制協議進行節點到節點的數據交換，這更適合於使用很少的帶寬和處理時間在節點之間交換信息。
4.Redis集羣和Docker
目前，Redis羣集不支持NAT地址環境，並且在IP地址或TCP端口被重新映射的一般環境中。
Docker使用一種叫做端口映射的技術：Docker容器中運行的程序可能會暴露在與程序認爲使用的端口不同的端口上。 這對於在同一服務器中同時使用相同端口運行多個容器很有用。
爲了使Docker與Redis Cluster兼容，您需要使用Docker的主機聯網模式。 請查看Docker文檔中的–net = host選項以獲取更多信息。
5.Redis集羣數據分片
Redis集羣沒有使用一致的散列，而是一種不同的分片形式，其中每個 key 在概念上都是我們稱之爲散列槽的部分。
Redis集羣中有16384個散列槽，爲了計算給定 key 的散列槽，我們簡單地取16384模的CRC16。
Redis集羣中的每個節點負責哈希槽的一個子集，例如，您可能有一個具有3個節點的集羣，其中：
- 1、節點A包含從0到5500的散列槽。
- 2、節點B包含從5501到11000的散列槽。
- 3、節點C包含從11001到16383的散列槽。
這允許輕鬆地添加和刪除集羣中的節點。例如，如果我想添加一個新節點D，我需要將節點A，B，C中的一些散列槽移動到D。同樣，如果我想從集羣中刪除節點A，我可以只移動由A使用的散列槽到B和C，當節點A將爲空時，我可以將它從羣集中徹底刪除。
因爲將散列槽從一個節點移動到另一個節點不需要停機操作，添加和移除節點或更改節點佔用的散列槽的百分比也不需要任何停機時間。
只要涉及單個命令執行（或整個事務或Lua腳本執行）的所有 key 都屬於同一散列插槽，Redis羣集就支持多個 key 操作。用戶可以使用稱爲散列標籤的概念強制多個 key 成爲同一個散列槽的一部分。
Hash標記記錄在Redis集羣規範文檔中，但要點是如果在關鍵字{}括號內有一個子字符串，那麼只有該花括號“{}”內部的內容被散列，例如 this{foo}key 和 another{foo}key 保證在同一散列槽中，並且可以在具有多個 key 作爲參數的命令中一起使用。
6.Redis集羣之主從模型
爲了在主服務器節點的子集失敗或不能與大多數節點通信時保持可用，Redis集羣使用主從模型，其中每個散列槽從1（主服務器本身）到N個副本（N -1個附加從節點）。
在我們具有節點A，B，C的示例的羣集中，如果節點B失敗，則羣集無法繼續，因爲我們沒有辦法再在5501-11000範圍內提供散列槽。然而，當創建集羣時（或稍後），我們爲每個主服務器節點添加一個從服務器節點，以便最終集羣由作爲主服務器節點的A，B，C以及作爲從服務器節點的A1，B1，C1組成，如果節點B發生故障，系統能夠繼續運行。節點B1複製B，並且B失敗，則集羣將促使節點B1作爲新的主服務器節點並且將繼續正確地操作。
但請注意，如果節點B和B1在同一時間發生故障，則Redis羣集無法繼續運行。
7.Redis集羣一致性保證
Redis 集羣無法保證很強的一致性。實際上，這意味着在某些情況下，Redis 集羣可能會丟失系統向客戶確認的寫入。
Redis集羣可能會丟失寫入的第一個原因是因爲它使用異步複製。這意味着在寫入期間會發生以下事情：
- 1、你的客戶端寫給主服務器節點 B
- 2、主服務器節點B向您的客戶端回覆確認。
- 3、主服務器節點B將寫入傳播到它的從服務器B1，B2和B3。
正如你可以看到主服務器節點 B 在回覆客戶端之前不等待B1，B2，B3的確認，因爲這會對Redis造成嚴重的延遲損失，所以如果你的客戶端寫入了某些東西，主服務器節點 B 確認寫入，就在將寫入發送給它的從服務器節點存儲之前系統崩潰了，其中一個從站（沒有收到寫入）可以提升爲主站，永遠丟失寫入。
這與大多數配置爲每秒將數據刷新到磁盤的數據庫所發生的情況非常相似，因爲過去的經驗與傳統數據庫系統有關，不會涉及分佈式系統，因此您已經能夠推斷這種情況。同樣，通過強制數據庫在回覆客戶端之前刷新磁盤上的數據，這樣可以提高一致性，但這通常會導致性能極低。這與Redis Cluster中的同步複製相當。
基本上，性能和一致性之間需要權衡。
Redis集羣在絕對需要時也支持同步寫入，通過WAIT命令實現，這使得丟失寫入的可能性大大降低，但請注意，即使使用同步複製，Redis集羣也不可能實現完全的一致性：總是有可能會發生故常，在無法接受寫入的從設備被選爲主設備的時候 。
還有另一個值得注意的情況，Redis集羣也將丟失數據的寫入，這種情況發生在網絡分區的時候，客戶端與包含至少一個主服務器的少數實例隔離。
以A，B，C，A1，B1，C1三個主站和三個從站組成的6個節點集羣爲例。還有一個客戶，我們會調用Z1。
分區發生後，可能在分區的一側有A，C，A1，B1，C1，另一側有B和Z1。
Z1仍然能夠寫入B，它也會接受Z1的寫入。如果分區在很短的時間內恢復，則羣集將正常繼續。但是，如果分區使用比較長的時間將B1提升爲多數側分區的主設備，則Z1發送給B的寫入操作將丟失。
請注意，Z1能夠發送給B的寫入量有一個最大窗口（maximum window）：如果分區多數側有足夠的時間選擇一個從設備作爲主設備，那麼少數側的每個主節點將停止接受寫操作。
這個時間值是Redis集羣非常重要的配置指令，稱爲 node timeout (節點超時)。
在節點超時過後，主節點被認爲是失效的，並且可以被其副本之一替換。類似地，節點超時過後，主節點無法感知大多數其他主節點，它進入錯誤狀態並停止接受寫入。
8.redis容錯機制
每個redis提供了節點之間相互發送ping命令，用於測試每個節點的健康狀態，集羣中連接正常的節點收到其他接節點發送的ping命令時，會返回一個pong字符串
Redis投票機制：如果一個節點A給B發送ping沒有得到pong返回，那麼A就會通知其他節點再次給B發送ping，如果集羣中超過一半的節點給B發送ping都沒有得到返回，那麼B就被坐實game over了，所以爲了避免單點故障，一般都會爲redis的每個節點提供了備份節點，B節點掛掉之後立馬啓動B的節點服務器。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對神馬文庫的支持。如果你想了解更多相關內容請查看下面相關鏈接