java架構之路-（Redis專題）Redis的主從、哨兵和集羣

　　咱們使用的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的服務器，不會安裝的小夥伴能夠回到我之後的博客去看一下，超詳細http://www.javashuo.com/article/p-quotyjwx-gk.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。

 

最進弄了一個公衆號，小菜技術，歡迎你們的加入