目錄
爲什麼要有集羣
單個Redis存在不穩定性，當Redis服務宕機或硬盤故障，系統崩潰之後，就沒有可用的服務了，還會造成數據的丟失
單個Redis的讀寫能力也是有限的
還由於互聯網的三高架構，高併發，高性能，高可用
概念
通過添加服務器的數量，提供相同的服務，從而讓服務器達到一個穩定，高效的狀態
三種模式
- 主從模式
- 哨兵模式
- Cluster模式
主從模式
爲什麼要用主從複製
單機redis的風險與問題
問題一：機器故障
- 硬盤故障，系統崩潰
- 本質：數據丟失，可能對業務造成災難性打擊
問題二：容量瓶頸
- 內存不足，一臺redis內存是有限的
解決方案：
爲了避免單點Redis服務器故障，準備多臺服務器，互相聯通，將數據複製多個副本保存在不同服務器上，連接在一起，並保證數據是同步的，即使有其中一臺服務器宕機，其他服務器依然可以繼續提供服務，實現Redis的高可用，同時實現數據冗餘備份
特徵
- 一個master可以擁有多個slave，一個slave只對應一個master
- 主從複製即將master中的數據及時，有效的複製到slave中
職責
master
- 寫數據
- 執行寫操作時，將出現變化的數據自動同步到slave
slave： - 讀數據，禁止寫數據
作用
- 讀寫分離：master寫，slave度，提高服務器的讀寫負載能力
- 負載均衡：基於主從結構，配合讀寫分離，由slave分擔master負載，並根據需求的變化，改變slave的數據，通過多個結點分擔數據讀取負載，大大提高Redis服務器併發量與數據吞吐量
- 故障恢復：當master出現問題時，由slave提供服務，實現快速的故障恢復
- 數據冗餘：實現數據熱備份，是持久化之外的一種數據冗餘方式
- 高可用基石：基於主從複製，構建哨兵模式與集羣，實現Redis的高可用方案
工作流程
分三個階段
- 建立連接階段-建立slave到master的連接，使master能夠識別slave，並保存slave端口號
- 數據同步階段-在slave初次連接master後，複製master中的所有數據到slave
- 命令傳播階段-當master數據庫狀態被修改後，導致主從服務器數據庫狀態不一致，此時需要讓主從數據同步到一致的 狀態
建立連接階段
數據同步階段
要想了解這一階段，先了解這幾個知識點：複製緩衝區
複製緩衝區
複製緩衝區，又名複製積壓緩衝區，是一個先進先出的隊列，用於存儲服務器執行過的命令，每次傳播命令，master都會將傳播的命令記錄下來，並存儲在複製緩衝區
工作原理
組成：
- 偏移量（offset），用來記錄已發送的信息對應的偏移量,作爲下次發送信息的座標依據
- 字節值，存放的用戶的操作命令
原理：
通過偏移量區分不同的slave當前數據傳播的差異（每個slave可能接受到master的命令的數量還不一樣）
總結
複製緩衝區存的是全量複製之後的用戶的一些操作，因爲rdb不是實時的，需要有一個地方存儲在全量複製更新期間，用戶的一些操作命令，全量複製之後，這些命令都會發到slave，但不是一次性全發過去，而是有一定的規則去發，分好幾次發送，每次都會記錄命令發到了哪個位置，下回發送就從這個地方發送
注意事項
- 如果master數據量巨大，數據同步階段應避開流量高峯期，避免造成master阻塞，影響業務正常執行
- 複製緩衝區大小設定不合理，會導致數據溢出。如進行全量複製週期太長，進行部分複製時發現數據已經存在丟失的清空，必須進行第二次全量複製
- master單機內存佔用主機內存的比例不應過大，建議使用50%-70%的內存，留下30%-50%的內存用於執行bgsave命令和創建複製緩衝區
命令傳播階段
要想了解這一階段，先了解這幾個知識點：複製緩衝區、服務器運行ID、心跳機制
服務器運行ID
服務器運行ID是每一臺服務器每次運行的身份識別碼，一臺服務器多次運行可以生成多個運行id
組成：運行id由40位字符組成，是一個隨機的十六進制字符 例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
作用：運行id被用於在服務器間進行傳輸，識別身份 如果想兩次操作均對同一臺服務器進行，必須每次操作攜帶對應的運行id，用於對方識別
實現方式：運行id在每臺服務器啓動時自動生成的，master在首次連接slave時，會將自己的運行ID發 送給slave，slave保存此ID，通過info Server命令，可以查看節點的runid
心跳機制
進入命令傳播階段候，master與slave間需要進行信息交換，使用心跳機制進行維護，實現雙方連接保持在
master心跳：
- 指令：PING
- 週期：由repl-ping-slave-period決定，默認10秒
- 作用：判斷slave是否在線
- 查詢：INFO replication 獲取slave最後一次連接時間間隔，lag項維持在0或1視爲正常
slave心跳任務- 指令：REPLCONF ACK {offset}
- 週期：1秒
- 作用1：彙報slave自己的複製偏移量，獲取最新的數據變更指令
- 作用2：判斷master是否在線
常見問題
- master數據巨大的時候，一旦master重啓，runid將會發生變化，會導致全部的slave的全量複製操作
- 複製緩衝區過小，斷網後slave的offset越界，觸發全量複製
總結
- 主數據庫可以進行讀寫操作，當讀寫操作導致數據變化時會自動將數據同步給從數據庫
- 從數據庫一般都是隻讀的，並且接收主數據庫同步過來的數據
- 一個master可以擁有多個slave，但是一個slave只能對應一個master
- slave掛了不影響其他slave的讀和master的讀和寫，重新啓動後會將數據從master同步過來
- master掛了以後，不影響slave的讀，但redis不再提供寫服務，master重啓後redis將重新對外提供寫服務
- master掛了以後，不會在slave節點中重新選一個master，只能手動的一個一個改，不合適，就有了之後的哨兵
哨兵模式
哨兵（sentinel）是一個分佈式系統，用於對主從結構中的每臺服務器進行監控，當出現故障時通過投票機制選擇新的master並將所有slave連接到新的master
爲什麼有哨兵
主機宕機，如何能夠高可用的恢復正常，不用人爲進行干預
作用
- 監控
- 不斷地檢查master和slave是否正常運行
- master存活檢測，master與slave運行清空檢測
- 通知（提醒）
- 當被監控地服務器出現問題時，向其他（哨兵、客戶端）發送通知
- 自動故障轉移
- 斷開master與slave連接，選取一個slave作爲master，將其他slave連接到新地master，並告知客戶端新地服務器地址
注意：
- 哨兵也是一臺redis服務器，只是不提供數據服務
- 通常哨兵配置數量爲單數
Cluster
redis最開始使用主從模式做集羣，若master宕機需要手動配置slave轉爲master；後來爲了高可用提出來哨兵模式，該模式下有一個哨兵監視master和slave，若master宕機可自動將slave轉爲master，但它也有一個問題，就是不能動態擴充，哨兵模式還是隻有一個master；所以在3.x提出cluster集羣模式。
redis cluster在設計的時候，就考慮到了去中心化，去中間件，也就是說，集羣中的每個節點都是平等的關係，都是對等的，每個節點都保存各自的數據和整個集羣的狀態。每個節點都和其他所有節點連接，而且這些連接保持活躍，這樣就保證了我們只需要連接集羣中的任意一個節點，就可以獲取到其他節點的數據。
那麼redis 是如何合理分配這些節點和數據的呢？
Redis 集羣沒有並使用傳統的一致性哈希來分配數據，而是採用另外一種叫做哈希槽 (hash slot)的方式來分配的。redis cluster 默認分配了 16384 個slot，當我們set一個key 時，會用CRC16算法來取模得到所屬的slot，然後將這個key 分到哈希槽區間的節點上，具體算法就是：CRC16(key) % 16384。
在redis-cluster架構中，redis-master節點一般用於接收讀寫，而redis-slave節點則一般只用於備份，其與對應的master擁有相同的slot集合，若某個redis-master意外失效，則再將其對應的slave進行升級爲臨時redis-master。