java架構之路-（Redis專題）Redis的主從、哨兵和集群
- 2019 年 10 月 22 日
- 筆記
我們使用的redis，單機的絕對做不到高可用的，萬一單機的redis宕機了，就沒有備用的了，我們可以採用集群的方式來保證我們的高可用操作。
主從架構
大致就是這樣的，一個主節點，兩個從節點（一般兩個就可以了）
主從工作原理
如果你為master配置了一個slave，不管這個slave是否是第一次連接上Master，它都會發送一個SYNC命 令(redis2.8版本之前的命令)給master請求複製數據。 master收到SYNC命令後，會在後台進行數據持久化通過bgsave生成最新的rdb快照文件，持久化期間， master會繼續接收客戶端的請求，它會把這些可能修改數據集的請求快取在記憶體中。當持久化進行完畢以 後，master會把這份rdb文件數據集發送給slave，slave會把接收到的數據進行持久化生成rdb，然後再載入到記憶體中。然後master再將之前快取在記憶體中的命令發送給slave。 當master與slave之間的連接由於某些原因而斷開時，slave能夠自動重連Master，如果master收到了多 個slave並發連接請求，它只會進行一次持久化，而不是一個連接一次，然後再把這一份持久化的數據發送 給多個並發連接的slave。 當master和slave斷開重連後，一般都會對整份數據進行複製。但從redis2.8版本開始，master和slave斷開重連後支援部分複製。
我們在上述文字中可以得出，我們的master得到了SYNC命令以後，還是會繼續接收我們客戶端的命令的，或者說，我們的slave第一次全量複製了，而第二次就不再需要全量複製了，那麼就提到了我們的數據部分複製
數據部分複製
從2.8版本開始，slave與master能夠在網路連接斷開重連後只進行部分數據複製。 master會在其記憶體中創建一個複製數據用的快取隊列，快取最近一段時間的數據，master和它所有的 slave都維護了複製的數據下標offset和master的進程id，因此，當網路連接斷開後，slave會請求master 繼續進行未完成的複製，從所記錄的數據下標開始。如果master進程id變化了，或者從節點數據下標 offset太舊，已經不在master的快取隊列里了，那麼將會進行一次全量數據的複製。
那麼我們實際搭建一下我們的redis主從架構。
1.首先我們準備三台已經安裝好redis的伺服器，不會安裝的小夥伴可以回到我以後的部落格去看一下，超詳細https://www.cnblogs.com/cxiaocai/p/11674716.html
2.修改我們的主節點和從節點配置，將protected-mode no修改為yes，大概在88行，將我們bind 127.0.0.1修改為bind 0.0.0.0，啟動一下我們的主節點，然後分別測試一下從節點的伺服器是否可以連接我們的主節點（我怕你們防火牆開著），輸入$ redis-cli -h 主節點IP -p 主節點redis埠 。
[root@iZm5ec3zn3tzdvp7ttnnosZ redis-5.0.5]# ./src/redis-cli -h 47.104.129.103 -p 6379 47.104.129.103:6379>
注意：我們需要保證主節點和從節點是可以互通的
3.確保可以連接了，我們來配置從節點，我們全局搜索一下replica-read-only 改為replica-read-only yes（搜不到自己寫上replica-read-only yes）大概在326行，表示從節點只讀不寫。在replica‐read‐only yes上面設置replicaof 47.104.129.103 6379。
# administrative / dangerous commands. replicaof 47.104.129.103 6379 replica-read-only yes # Replication SYNC strategy: disk or socket.
4.啟動從節點，在主節點寫入，查看從節點是否得到數據。
配置完成，over~！
哨兵架構
其實我們的主從架構只保證了數據的一致性，但是還是解決不了我們的高可用，我們的master節點宕機了，我們的服務還是不可用的。沒有Zookeeper的選舉機制，我們來看看我們的哨兵架構。
哨兵就是保證我們的master不會宕機，當master宕機以後，他會主動選舉出來一個節點作為我們的master。
sentinel哨兵是特殊的redis服務，不提供讀寫服務，主要用來監控redis實例節點。 哨兵架構下client端第一次從哨兵找出redis的主節點，後續就直接訪問redis的主節點，不會每次都通過 sentinel代理訪問redis的主節點，當redis的主節點發生變化，哨兵會第一時間感知到，並且將新的redis 主節點通知給client端(這裡面redis的client端一般都實現了訂閱功能，訂閱sentinel發布的節點變動消息)
配置起來也是很簡單的，還是我們上一次的主從架構，然後加上我們的哨兵集群。
1.準備好我們剛才搭建完成的主從架構
2.準備三個以上的伺服器（推薦奇數個伺服器，有內部選舉），安裝我們的Redis，需要伺服器之間都相通，上面主從說過
3.修改我們的sentinel.conf文件
daemonize yes #允許後台啟動 sentinel monitor mymaster 192.168.0.60 6379 2 # 設置連接我們的redis主從master 2表示伺服器的數目/2取整數+1
4.輸入src/redis‐sentinel sentinel.conf啟動我們的程式，這時我們的埠是26379。注意：這裡的啟動不再是src/redis‐server。
5.輸入src/redis‐cli進入客戶端，輸入info，即可查看我們的sentinel 資訊。
哨兵模式也就很簡單的配置好了，是在主從的基礎之上搭建的，我們之前的主從架構，當我們的master宕機以後，redis也就算是宕機了，不會有任何選舉機制，但是我們的哨兵會有一個選舉機制，當我們的master宕機以後，我們的哨兵集群會主動選舉一個master，然後告知我們的客戶端，哪個是新的master。即使我們的曾經的master重新啟動了，那也恢復不到主節點了，只能當做從節點（redis集群會詳細說這個選舉）
Redis集群架構
我們的哨兵架構，幾乎可以做到了我們的要實現的高可用，但是哨兵的選舉還是需要時間的，而且中間會阻塞客戶端的請求，假如我們的選舉消耗了1秒（實際可能幾秒，高則幾十秒），就在這1秒的時候來了客戶端的請求，那個請求也是不可用的，並且我們的讀寫的節點實際還是單節點的，這時我們有了更好的方案，我們的Redis集群架構，並且現在Redis的集群架構做的也很成熟了。
也就是我們Redis的集群其實就是一個個小的主從結合在一起（官方建議小於1000個小主從），變成了我們的Redis集群，每個小主從也就是我們的Redis數據分片，每個小主從的數據存儲是不一樣的，內部是有一套他自己的運算規則的。我們還是先來看一下如何配置，上文提過的簡單的我就直接過了啊。
1.準備9台伺服器，保證互通，下載解壓。
2.編輯我們的redis.conf文件
(1)daemonize yes # 設置後台啟動，大概在136行
(2)cluster-enabled yes # 是否開啟集群模式，大概在832行
(3)cluster-config-file nodes‐8001.conf #集群節點資訊文件，這裡800x最好和port對應上，方便後期查找。大概在840行
(4)cluster-node-timeout 5000 # 節點離線超時時間，5000毫秒，大概在846行
(5)bind 0.0.0.0 #去掉bind綁定訪問ip資訊，大概在69行
(6)protected-mode no #關閉保護模式，大概在88行
(7)appendonly yes # 打開AOF，大概在699行
(8)requirepass xiaocai #設置redis訪問密碼，大概在507行
(9)masterauth xiaocai # 設置集群節點間訪問密碼，跟上面一致，大概在293行
3. 配置完成全部啟動./src/redis-server redis.conf 檢查是否啟動成ps -ef|grep redis。我們會看到這樣的資訊
這裡顯示cluster，說到這我們只差最後一步了。
4.我們在任意伺服器輸入./src/redis-cli -a xiaocai –cluster create –cluster-replicas 2 172.31.179.185:6379 172.31.179.178:6379 172.31.179.184:6379 172.31.179.183:6379 172.31.179.180:6379 172.31.179.181:6379 172.31.179.182:6379 172.31.179.179:6379 172.31.179.177:6379命令，意思是要組建我們的集群環境了，-a後面是密碼xiaocai，–cluster-replicas 2這個數字2表示我們每個主節點有幾個從節點，一般來說前三個IP會設置為master，輸入之後會有確認資訊。我們會看到這樣的資訊，我們輸入yes繼續
靜靜等待一會（時間也不會太久，時間太久的，你去檢查一下網路之間互通嗎），當我們出現【ok】的畫面也就是成功了。
5.我們隨便找一個客戶端輸入./src/redis-cli -a xiaocai，進入我們的客戶端，輸入cluster info，就可以查看到節點資訊
我們看到cluster_known_nodes：9就是我們一共擁有多少節點，cluster_size：3就是我們擁有多少組主從架構。配置完成~！
擴展：輸入cluster nodes還可以查看我們的節點關聯資訊。
我們在剛才輸入我們的cluster info時，我們看到了一個16384，其實就是一個Redis集群的片區，我們在單節點來執行set命令時，並不一定會成功，你可以嘗試不同的key試一下，這就是我們的Redis分片區的存儲，當你的key屬於那個片區下，就會存儲到哪個小主從內，其餘的並不需要重複存儲。在輸入cluster nodes時會返回我們的片區資訊。片區是從0開始計算，最大到16383的。
今天就說到這裡吧，下次我們說下java程式碼來操作我們的Redis。
最進弄了一個公眾號，小菜技術，歡迎大家的加入
