Redis叢集
這幾天工作需要研究了一下Redis叢集，將其原理的核心內容記錄下來以便以後查閱。
叢集原理
一個系統建立叢集主要需要解決兩個：資料同步問題和叢集容錯問題。
Naive方案
一個簡單粗暴的方案是部署多臺一模一樣的Redis服務，再用負載均衡來分攤壓力以及監控服務狀態。這種方案的優勢在於容錯簡單，只要有一臺存活，整個叢集就仍然可用。但是它的問題在於保證這些Redis服務的資料一致時，會導致大量資料同步操作，反而影響效能和穩定性。
Redis叢集方案
Redis叢集方案基於分而治之的思想。Redis中資料都是以Key-Value形式儲存的，而不同Key的資料之間是相互獨立的。因此可以將Key按照某種規則劃分成多個分割槽，將不同分割槽的資料存放在不同的節點上。這個方案類似資料結構中雜湊表的結構。在Redis叢集的實現中，使用雜湊演算法（公式是 CRC16(Key) mod 16383 ）將Key對映到0~16383範圍的整數。這樣每個整數對應儲存了若干個Key-Value資料，這樣一個整數對應的抽象儲存稱為一個槽（slot）。每個Redis Cluster的節點——準確講是master節點——負責一定範圍的槽，所有節點組成的叢集覆蓋了0~16383整個範圍的槽。
據說任何計算機問題都可以通過增加一箇中間層來解決。槽的概念也是這麼一層。它介於資料和節點之間，簡化了擴容和收縮操作的難度。資料和槽的對映關係由固定演算法完成，不需要維護，節點只需維護自身和槽的對映關係。
Slave
上面的方案只是解決了效能擴充套件的問題，叢集的故障容錯能力並沒有提升。提高容錯能力的方法一般為使用某種備份/冗餘手段。負責一定數量的槽的節點被稱為master節點。為了增加叢集穩定性，每個master節點可以配置若干個備份節點——稱為slave節點。Slave節點一般作為冷備份儲存master節點的資料，在master節點宕機時替換master節點。在一些資料訪問壓力比較大的情況下，slave節點也可以提供讀取資料的功能，不過slave節點的資料實時性會略差一下。而寫資料的操作則只能通過master節點進行。
請求重定向
當Redis節點接收到對某個key的命令時，如果這個key對應的槽不在自己的負責範圍內，則返回MOVED重定向錯誤，通知客戶端到正確的節點去訪問資料。
如果頻繁出現重定向錯誤，勢必會影響訪問的效能。由於從key對映到槽的演算法是固定公開的，客戶端可以在內部維護槽到節點的對映關係，訪問資料時可以自己通過key計算出槽，然後找到正確的節點，減少重定向錯誤。目前大部分開發語言的Redis客戶端都會實現這個策略。這個地址 ofollow,noindex" target="_blank">https://redis.io/clients 可以檢視主流語言的Redis客戶端。
節點通訊
儘管不同節點儲存的資料相互獨立，這些節點仍然需要相互通訊以同步節點狀態資訊。Redis叢集採用P2P的Gossip協議，節點之間不斷地通訊交換資訊，最終所有節點的狀態都會達成一致。常用的Gossip訊息有下面幾種：
- ping訊息：每個節點不斷地向其他節點發起ping訊息，用於檢測節點是否線上和交換節點狀態資訊。
- pong訊息：收到ping、meet訊息時的響應訊息。
- meet訊息：新節點加入訊息。
- fail訊息：節點下線訊息。
- forget訊息：忘記節點訊息，使一個節點下線。這個命令必須在60秒內在所有節點執行，否則超過60秒後該節點重新參與訊息交換。實踐中不建議直接使用forget命令來操作節點下線。
節點下線
當某個節點出現問題時，需要一定的傳播時間讓多數master節點認為該節點確實不可用，才能標記標記該節點真正下線。Redis叢集的節點下線包括兩個環節：主觀下線（pfail）和客觀下線（fail）。
- 主觀下線：當節點A在cluster-node-timeout時間內和節點B通訊（ping-pong訊息）一直失敗，則節點A認為節點B不可用，標記為主觀下線，並將狀態訊息傳播給其他節點。
- 客觀下線：當一個節點被叢集內多數master節點標記為主觀下線後，則觸發客觀下線流程，標記該節點真正下線。
故障恢復
一個持有槽的master節點客觀下線後，叢集會從slave節點中選出一個提升為master節點來替換它。Redis叢集使用選舉-投票的演算法來挑選slave節點。一個slave節點必須獲得包括故障的master節點在內的多數master節點的投票後才能被提升為master節點。假設叢集規模為3主3從，則必須至少有2個主節點存活才能執行故障恢復。如果部署時將2個主節點部署到同一臺伺服器上，則該伺服器不幸宕機後集群無法執行故障恢復。
預設情況下，Redis叢集如果有master節點不可用，即有一些槽沒有負責的節點，則整個叢集不可用。也就是說當一個master節點故障，到故障恢復的這段時間，整個叢集都處於不可用的狀態。這對於一些業務來說是不可忍受的。可以 在配置中將cluster-require-full-coverage配置為no ，那麼master節點故障時只會影響訪問它負責的相關槽的資料，不影響對其他節點的訪問。
搭建叢集
啟動新節點
修改Redis配置檔案以啟動叢集模式：
# 開啟叢集模式 cluster-enabled yes # 節點超時時間，單位毫秒 cluster-node-timeout 15000 # 叢集節點資訊檔案 cluster-config-file "nodes-6379.conf"
然後啟動新節點。
傳送meet訊息將節點組成叢集
使用客戶端發起命令 cluster <ip> <port> ，節點會發送meet訊息將指定IP和埠的新節點加入叢集。
分配槽
上一步執行完後我們得到的是一個還沒有負責任何槽的“空”叢集。為了使叢集可用，我們需要將16384個槽都分配到master節點數。
在客戶端執行 cluster add addslots {<a>...<b>} 命令，將 <a> ~ <b> 範圍的槽都分配給當前客戶端所連線的節點。將所有的槽都分配給master節點後，執行 cluster nodes 命令，檢視各個節點負責的槽，以及節點的ID。
接下來還需要分配slave節點。使用客戶端連線待分配的slave節點，執行 cluster replicate <nodeId> 命令，將該節點分配為 <nodeId> 指定的master節點的備份。
使用命令直接建立叢集
在Redis 5版本中 redis-cli 客戶端新增了叢集操作命令。
如下所示，直接使用命令建立一個3主3從的叢集：
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \ 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \ --cluster-replicas 1
如果你用的是舊版本的Redis，可以使用官方提供的 redis-trib.rb 指令碼來建立叢集:
./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \ 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
叢集伸縮
擴容
擴容操作與建立叢集操作類似，不同的在於最後一步是將槽從已有的節點遷移到新節點。
redis-cli --cluster add-node redis-cli --cluster reshard
收縮
為了安全刪除節點，Redis叢集只能下線沒有負責槽的節點。因此如果要下線有負責槽的master節點，則需要先將它負責的槽遷移到其他節點。
- 遷移槽。使用命令
redis-cli --cluster reshard將待刪除節點的槽都遷移到其他節點。 - 忘記節點。使用命令
redis-cli --cluster del-node刪除節點（內部使用forget訊息實現）。 -
叢集配置工具
如果你的redis-cli版本低於5，那麼可以使用redis-trib.rb指令碼來完成上面的命令。點選 這裡 檢視 redis-cli 和 redis-trib.rb 操作叢集的命令。
持久化
Redis有RDB和AOF兩種持久化策略。 這篇文章 詳細講解了RDB和AOF持久化原理。
一個RDB持久化的坑
RDB持久化神坑：
save ""
後果：
- 如果關閉了RDB持久化（以及AOF持久化），那麼 當Redis重啟時，則會載入上一次從節點全量複製或者執行shutdown時儲存的RDB檔案 。而這個RDB檔案很可能是一份過時已久的資料。
- Cluster模式下，Redis重啟並從RDB檔案恢復資料後，如果沒有讀取到cluster-config-file中nodes的配置，則 標記自己為單獨的master並佔用從RDB中恢復的資料的Key對應的槽，導致此節點無法再加入其它叢集 。