溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要為大家展示了“redis集群方案的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“redis集群方案的示例分析”這篇文章吧。
將數據完全存儲在單個redis中主要存在兩個問題：
數據備份和數據體量較大造成的性能降低。
Redis的主從模式為這兩個問題提供了一個較好的解決方案。主從模式指的是使用一個redis實例作為主機，其余的實例作為備份機。
主機和從機的數據完全一致，主機支持數據的寫入和讀取等各項操作，而從機則只支持與主機數據的同步和讀取，也就是說，客戶端可以將數據寫入到主機，由主機自動將數據的寫入操作同步到從機。
主從模式很好的解決了數據備份問題，并且由于主從服務數據幾乎是一致的，因而可以將寫入數據的命令發送給主機執行，而讀取數據的命令發送給不同的從機執行，從而達到讀寫分離的目的。
實現主從復制（Master-Slave Replication）的工作原理：
Slave從節點服務啟動并連接到Master之后，它將主動發送一個SYNC命令。Master服務主節點收到同步命令后將啟動后臺存盤進程，同時收集所有接收到的用于修改數據集的命令，在后臺進程執行完畢后，Master將傳送整個數據庫文件到Slave，以完成一次完全同步。而Slave從節點服務在接收到數據庫文件數據之后將其存盤并加載到內存中。此后，Master主節點繼續將所有已經收集到的修改命令，和新的修改命令依次傳送給Slaves，Slave將在本次執行這些數據修改命令，從而達到最終的數據同步。
如果Master和Slave之間的鏈接出現斷連現象，Slave可以自動重連Master，在連接成功之后，一次完全同步將被自動執行。
部署：
redis version:6.0.9
1.分別復制4份Redis配置文件
命名為 master.conf slave1.conf slave2.conf slave3.conf
2.對4份配置文件進行簡單配置
Master節點的配置文件一般不需要特殊設置 port默認為6379
Slave1 節點 port設置 6380 再配置一行 replicaof 127.0.0.1 6379
Slave2 節點 port設置 6381 再配置一行 replicaof 127.0.0.1 6379
Slave3 節點 port設置 6382 再配置一行 replicaof 127.0.0.1 6379
3.分別開啟 Master節點和3個Slave節點
redis-server master.conf
redis-server slave1.conf
redis-server slave2.conf
redis-server slave3.conf
4.驗證集群主從狀態
主從模式的優缺點：
1、優點：
同一個Master可以同步多個Slaves。
master能自動將數據同步到slave，可以進行讀寫分離，分擔master的讀壓力
master、slave之間的同步是以非阻塞的方式進行的，同步期間，客戶端仍然可以提交查詢或更新請求
2、缺點：
不具備自動容錯與恢復功能，master或slave的宕機都可能導致客戶端請求失敗，需要等待機器重啟或手動切換客戶端IP才能恢復
master宕機，如果宕機前數據沒有同步完，則切換IP后會存在數據不一致的問題
難以支持在線擴容，Redis的容量受限于單機配置
其實redis的主從模式很簡單，在實際的生產環境中很少使用，不建議在實際的生產環境中使用主從模式來提供系統的高可用性，之所以不建議使用都是由它的缺點造成的，在數據量非常大的情況，或者對系統的高可用性要求很高的情況下，主從模式也是不穩定的。雖然這個模式很簡單，但是這個模式是其他模式的基礎，所以理解了這個模式，對其他模式的學習會很有幫助。
哨兵顧名思義，就是來為Redis集群站哨的，一旦發現問題能做出相應的應對處理。其功能包括
監控master、slave是否正常運行
當master出現故障時，能自動將一個slave轉換為master（大哥掛了，選一個小弟上位）
多個哨兵可以監控同一個Redis，哨兵之間也會自動監控
當自動發現slave和其他哨兵節點后，哨兵就可以通過定期發送PING命令定時監控這些數據庫和節點有沒有停止服務。
如果被PING的數據庫或者節點超時（通過 sentinel down-after-milliseconds master-name milliseconds 配置）未回復，哨兵認為其主觀下線（sdown，s就是Subjectively —— 主觀地）。如果下線的是master，哨兵會向其它哨兵發送命令詢問它們是否也認為該master主觀下線，如果達到一定數目（即配置文件中的quorum）投票，哨兵會認為該master已經客觀下線（odown，o就是Objectively —— 客觀地），并選舉領頭的哨兵節點對主從系統發起故障恢復。若沒有足夠的sentinel進程同意master下線，master的客觀下線狀態會被移除，若master重新向sentinel進程發送的PING命令返回有效回復，master的主觀下線狀態就會被移除。
哨兵認為master客觀下線后，故障恢復的操作需要由選舉的領頭哨兵來執行，
選出領頭哨兵后，領頭者開始對系統進行故障恢復，從出現故障的master的從數據庫中挑選一個來當選新的master,
挑選出需要繼任的slave后，領頭哨兵向該數據庫發送命令使其升格為master，然后再向其他slave發送命令接受新的master，最后更新數據。將已經停止的舊的master更新為新的master的從數據庫，使其恢復服務后以slave的身份繼續運行。
哨兵模式基于前面的主從復制模式。哨兵的配置文件為sentinel.conf，在相應目錄中添加以下配置，注意端口不要沖突：
port 26379 protected-mode no daemonize yes pidfile "/var/run/redis-sentinel-26379.pid" logfile "/data/redis/logs/sentinel_26379.log" dir "/data/redis/6379" sentinel monitor mymaster 127.0.0.1 6379 2 ##指定主機IP地址和端口，并且指定當有2臺哨兵認為主機掛了，則對主機進行容災切換 #sentinel auth-pass mymaster pwdtest@2019 ##當在Redis實例中開啟了requirepass，這里就需要提供密碼 sentinel down-after-milliseconds mymaster 3000 ##這里設置了主機多少秒無響應，則認為掛了 sentinel failover-timeout mymaster 180000 ##故障轉移的超時時間，這里設置為三分鐘
格式如下：
查看哨兵狀態：
Cluster采用無中心結構,它的特點如下：
客戶端與redis節點直連,客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可
Cluster模式的具體工作機制：
在Redis的每個節點上，都有一個插槽（slot），取值范圍為0-16383 ，一共16384個槽
當我們存取key的時候，Redis會根據CRC16的算法得出一個結果，然后把結果對16384求余數，這樣每個key都會對應一個編號在0-16383之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然后直接自動跳轉到這個對應的節點上進行存取操作。
為了保證高可用，Cluster模式也引入主從復制模式，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啟用從節點。
當其它主節點ping一個主節點A時，如果半數以上的主節點與A通信超時，那么認為主節點A宕機了。如果主節點A和它的從節點都宕機了，那么該集群就無法再提供服務了。
Redis集群，要保證16384個槽對應的node都正常工作，如果某個node發生故障，那它負責的slots也就失效，整個集群將不能工作。
為了增加集群的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。這時，如果主節點失效，Redis Cluster會根據選舉算法從slave節點中選擇一個上升為主節點，整個集群繼續對外提供服務，Redis Cluster本身提供了故障轉移容錯的能力。
Cluster模式集群節點最小配置6個節點(根據cluster的選舉機制和主從備份的實現，redis要求至少三主三從共6個節點才能組成redis集群，因為至少需要半數以上才能確定某個節點是否宕機且需要主從備份)，其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。
cluster集群部署
根據cluster的選舉機制和主從備份的實現，redis要求至少三主三從共6個節點才能組成redis集群，測試環境可一臺物理機器上啟動6個redis節點，但生產環境至少要準備2～3臺物理機。(這里使用三臺虛擬機)
Cluster模式是建立在Sentinel模式的基礎上的，當數據多到需要動態擴容的時候，前面兩種就不行了，需要對數據進行分片，根據一定的規則把redis數據分配到多臺機器。
該模式就支持動態擴容，可以在線增加或刪除節點，而且客戶端可以連接任何一個主節點進行讀寫，不過此時的從節點僅僅只是備份的作用。至于為何能做到動態擴容，主要是因為Redis集群沒有使用一致性hash,而是使用的哈希槽。Redis集群會有16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定放置哪個槽，而集群的每個節點負責一部分hash槽。
那么這樣就很容易添加或者刪除節點， 比如如果我想新添加個新節點， 我只需要從已有的節點中的部分槽到過來；如果我想移除某個節點，就只需要將該節點的槽移到其它節點上，然后將沒有任何槽的A節點從集群中移除即可。由于從一個節點將哈希槽移動到另一個節點并不會停止服務，所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態。
需要注意的是，該模式下不支持同時處理多個key（如MSET/MGET），因為redis需要把key均勻分布在各個節點上，并發量很高的情況下同時創建key-value會降低性能并導致不可預測的行為。
搭建集群
這里就直接搭建較為復雜的Cluster模式集群，也是企業級開發過程中使用最多的。
最終目錄結構如下
以 9001 的為例子，其余五個類似。
編輯 /data/redis-cluster/9001/redis.conf
redis.conf修改如下:
port 9001（每個節點的端口號） daemonize yes appendonly yes //開啟aof bind 0.0.0.0（綁定當前機器 IP） dir "/data/redis-cluster/9001"（數據文件存放位置,,自己加到最后一行 快捷鍵 shift+g） pidfile /var/run/redis_9001.pid（pid 9001和port要對應） logfile "/data/redis-cluster/logs/9001.log" cluster-enabled yes（啟動集群模式） cluster-config-file nodes9001.conf（9001和port要對應） cluster-node-timeout 15000
/data/redis-cluster/bin/redis-server /data/redis-cluster/9001/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9002/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9003/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9004/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9005/redis.conf
/data/redis-cluster/bin/redis-server /data/redis-cluster/9006/redis.conf
現在檢查一下是否成功開啟，如下圖所示，都開啟成功。
ps -el | grep redis
此時的節點雖然都啟動成功了，但他們還不在一個集群里面，不能互相發現，測試會報錯：(error) CLUSTERDOWN Hash slot not served。
如下圖所示
redis-cli --cluster create 10.32.176.80:9001 10.32.176.80:9002 10.32.176.80:9003 10.32.176.80:9004 10.32.176.80:9005 10.32.176.80:9006 --cluster-replicas 1
–cluster-replicas 1 這個指的是從機的數量，表示我們希望為集群中的每個主節點創建一個從節點。
紅色選框是給三個主節點分配的共16384個槽點。
黃色選框是主從節點的分配情況。
藍色選框是各個節點的詳情。
現在通過客戶端命令連接上，通過集群命令看一下狀態和節點信息等
/data/redis-cluster/bin/redis-cli -c -h 10.32.176.80 -p 9001 cluster info cluster nodes
效果圖如下，集群搭建成功。
現在往9001這個主節點寫入一條信息，我們可以在9002這個主節點取到信息，集群間各個節點可以通信。
故障轉移機制詳解
集群中的節點會向其它節點發送PING消息（該PING消息會帶著當前集群和節點的信息），如果在規定時間內，沒有收到對應的PONG消息，就把此節點標記為疑似下線。當被分配了slot槽位的主節點中有超過一半的節點都認為此節點疑似下線（就是其它節點以更高的頻次，更頻繁的與該節點PING-PONG），那么該節點就真的下線。其它節點收到某節點已經下線的廣播后，把自己內部的集群維護信息也修改為該節點已事實下線。
節點資格審查：然后對從節點進行資格審查，每個從節點檢查最后與主節點的斷線時間，如果該值超過配置文件的設置，那么取消該從節點的資格。準備選舉時間：這里使用了延遲觸發機制，主要是給那些延遲低的更高的優先級，延遲低的讓它提前參與被選舉，延遲高的讓它靠后參與被選舉。（延遲的高低是依據之前與主節點的最后斷線時間確定的）
選舉投票：當從節點獲取選舉資格后，會向其他帶有slot槽位的主節點發起選舉請求，由它們進行投票，優先級越高的從節點就越有可能成為主節點，當從節點獲取的票數到達一定數值時（如集群內有N個主節點，那么只要有一個從節點獲得了N/2+1的選票即認為勝出），就會替換成為主節點。
替換主節點：被選舉出來的從節點會執行slaveof no one把自己的狀態從slave變成master，然后執行clusterDelSlot操作撤銷故障主節點負責的槽，并執行 clusterAddSlot把這些槽分配給自己，之后向集群廣播自己的pong消息，通知集群內所有的節點，當前從節點已變為主節點。
接管相關操作：新的主節點接管了之前故障的主節點的槽信息，接收和處理與自己槽位相關的命令請求。
故障轉移測試
這是之前集群中具體節點的情況，我簡化成如下，可以向上回看圖片中的集群信息。
這里關閉該9001端口的進程，即模擬該主節點掛掉。
登錄掛掉的redis節點，會被拒絕服務，通過還在正常運行的某個主節點進入，然后再次查看集群中的信息
簡而言之，就是之前的集群信息變成了如下所示
現在，我重啟剛才掛掉的主節點，重新查看集群內部的節點情況，具體情況如下圖所示
簡而言之，現在集群內的節點情況如下
以上是“redis集群方案的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
