深刻淺出—Redis集羣的相關詳解

前言：

這篇文章主要介紹了Redis集羣的相關，文中經過示例代碼介紹的很是詳細，對你們的學習或者工做具備必定的參考學習價值。

注意！要求使用的都是redis3.0以上的版本，由於3.0以上增長了redis集羣的功能。

1.redis介紹

1.1什麼是redis

Redis是用C語言開發的一個開源的高性能鍵值對(key-value)的非關係型數據庫。經過多種鍵值數據類型來適應不一樣場景下的存儲需求，目前支持的鍵值數據類型有：
字符串，散列，列表，集合，有序集合

2.2應用場景

緩存（數據查詢、短鏈接、新聞內容、商品內容等等）。（最多使用）
分佈式集羣架構中的session分離。
聊天室的在線好友列表。
任務隊列。（秒殺、搶購、12306等等）
應用排行榜。
網站訪問統計。
數據過時處理（能夠精確到毫秒）

2.Redis集羣的介紹

2.1Redis集羣的架構

 

 

Redis 集羣中內置了 16384 個哈希槽，redis-cluster把全部的物理節點映射到[0-16383]slot上,cluster 負責維護。當須要在 Redis 集羣中放置一個 key-value 時，redis 先對 key 使用 crc16 算法算出一個結果，而後把結果對 16384 求餘數，這樣每一個 key 都會對應一個編號在 0-16383 之間的哈希槽，redis 會根據節點數量大體均等的將哈希槽映射到不一樣的節點

2.2 Redis集羣的特色

當Redis集羣啓動後，就自動在多個節點間作好分片，同時提供了分片之間的可用性：即當一部分redis節點故障或者網絡中斷後，集羣還有從節點能夠替代主節點繼續工做，但若是大面積的節點故障，那集羣就不可用了。

Redis集羣提供了：
自動將16384個數據槽點切分到多個Redis節點中
當一部分節點故障或不可達，集羣依然能繼續工做

2.3 Redis集羣的TCP端口

集羣的每一個節點都須要創建兩個TCP鏈接，監聽這兩個端口：
客戶端端口（通常是6379）：須要對全部客戶端和集羣節點開放，用於接收客戶端指令，且集羣節點須要經過該端口向客戶端轉移數據。

集羣總線端口（通常是6379+10000）：只須要對集羣中的全部節點開放，用於節點之間經過二進制協議通訊。各節點經過集羣總線檢測故障節點，更新配置等，而客戶端是不能使用該端口的。

2.4 Redis集羣數據的分片

Redis集羣使用的是哈希槽，有16384個哈希槽，決定一個key分配到哪一個槽的算法：計算該key的CRC16,結果再模16384.
集羣中的每一個節點負責一部分哈希槽，好比集羣中有３個節點，則：

• 節點Ａ存儲的哈希槽範圍是：0 – 5500
• 節點Ｂ存儲的哈希槽範圍是：5501 – 11000
• 節點Ｃ存儲的哈希槽範圍是：11001 – 16384

這樣的分佈方式方便節點的添加和刪除。好比，須要新增一個節點Ｄ，只須要把Ａ、Ｂ、Ｃ中的部分哈希槽數據移到Ｄ節點。一樣，若是但願在集羣中刪除Ａ節點，只須要把Ａ節點的哈希槽的數據移到Ｂ和Ｃ節點，當Ａ節點的數據所有被移走後，Ａ節點就能夠徹底從集羣中刪除。

由於把哈希槽從一個節點移到另外一個節點是不須要停機的，因此，增長或刪除節點，或更改節點上的哈希槽，也是不須要停機的。

若是多個key都屬於一個哈希槽，集羣支持經過一個命令（或事務, 或lua腳本）同時操做這些key。經過「哈希標籤」的概念，用戶可讓多個key分配到同一個哈希槽。若是key含有大括號」{}」,則只有大括號中的字符串會參與哈希，好比」this{foo}」和」another{foo}」這２個key會分配到同一個哈希槽，因此能夠在一個命令中同時操做他們。

2.5 Redis集羣的主從模式

每一個哈希槽都有一個主節點和多個從節點。
舉例：若是有六個節點，則分A,B,C三個爲主節點，A1,B1,C1三個爲對應的從節點，當A發生故障後，集羣會提高A1爲主節點，A1會繼承A節點的數據，其實A1就至關於A的一個副本，讓集羣繼續工做。

2.5.1 redis-cluster投票:容錯

 

 

(1)投票過程是集羣中全部主節點參與,若是半數以上主節點與故障主節點通訊超過(cluster-node-timeout),認爲當前該主節點掛掉.
(2):何時整個集羣不可用(cluster_state:fail)?
a:若是集羣任意主節點掛掉,且沒有從節點.集羣進入fail狀態,也能夠理解成集羣的slot映射[0-16383]不完成時進入fail狀態.
b:若是集羣超過半數以上主節點掛掉，不管是否有從節點，集羣都進入fail狀態.
ps:當集羣不可用時,全部對集羣的操做作都不可用，收到((error) CLUSTERDOWN The cluster is down)錯誤。

2.6 Redis集羣的一致性保證

Redis集羣不能保證強一致性。一些已經向客戶端確認寫成功的操做，會在某些不肯定的狀況下丟失。
產生寫操做丟失的第一個緣由，是由於主從節點之間使用了異步的方式來同步數據。
一個寫操做是這樣一個流程：

• 1)客戶端向主節點B發起寫的操做
• 2)主節點B迴應客戶端寫操做成功
• 3)主節點B向它的從節點B1,B2,B3同步該寫操做

從上面的流程能夠看出來，主節點B並無等從節點B1,B2,B3寫完以後再回復客戶端此次操做的結果。因此，若是主節點B在通知客戶端寫操做成功以後，但同步給從節點以前，主節點Ｂ故障了，其中一個沒有收到該寫操做的從節點會晉升成主節點，該寫操做就這樣永遠丟失了。

節點超時（node timeout）：對集羣來講很是重要，當達到了這個節點超時的時間以後，主節點被認爲已經宕機，能夠用它的一個從節點來代替。一樣，在節點超時時，若是主節點依然不能聯繫到其餘主節點，它將進入錯誤狀態，再也不接受寫操做。

2.7 Redis集羣的參數配置

在redis.conf中的一些參數說明：

cluster-enabled <yes/no>:
若是配置」yes」則開啓集羣功能，此redis實例做爲集羣的一個節點，不然，它是一個普通的單一的redis實例。

cluster-config-file :
注意：雖然此配置的名字叫「集羣配置文件」，可是此配置文件不能人工編輯，它是集羣節點自動維護的文件，主要用於記錄集羣中有哪些節點、他們的狀態以及一些持久化參數等，方便在重啓時恢復這些狀態。一般是在收到請求以後這個文件就會被更新。

cluster-node-timeout :
這是集羣中的節點可以失聯的最大時間，超過這個時間，該節點就會被認爲故障。若是主節點超過這個時間仍是不可達，則用它的從節點將啓動故障遷移，升級成主節點。注意，任何一個節點在這個時間以內若是仍是沒有連上大部分的主節點，則此節點將中止接收任何請求。

cluster-slave-validity-factor :
若是設置成０，則不管從節點與主節點失聯多久，從節點都會嘗試升級成主節點。若是設置成正數，則cluster-node-timeout乘以cluster-slave-validity-factor獲得的時間，是從節點與主節點失聯後，此從節點數據有效的最長時間，超過這個時間，從節點不會啓動故障遷移。假設cluster-node-timeout=5，cluster-slave-validity-factor=10，則若是從節點跟主節點失聯超過50秒，此從節點不能成爲主節點。注意，若是此參數配置爲非0，將可能出現因爲某主節點失聯卻沒有從節點能頂上的狀況，從而致使集羣不能正常工做，在這種狀況下，只有等到原來的主節點從新迴歸到集羣，集羣才恢復運做。

cluster-migration-barrier
:主節點須要的最小從節點數，只有達到這個數，主節點失敗時，它從節點纔會進行遷移。更詳細介紹能夠看本教程後面關於副本遷移到部分。

cluster-require-full-coverage
<yes/no>:在部分key所在的節點不可用時，若是此參數設置爲」yes」(默認值),
則整個集羣中止接受操做；若是此參數設置爲」no」，則集羣依然爲可達節點上的key提供讀操做。

以上所述是小編給你們介紹的Redis集羣的相關詳解整合，但願對你們有所幫助，