Redis高可用及分片集羣

1、主從複製

• 使用異步複製
• 一個服務器能夠有多個從服務器
• 從服務器也能夠有本身的從服務器
• 複製功能不會阻塞主服務器
• 能夠經過服務功能來上主服務器免於持久化操做，由從服務器去執行持久化操做便可。

如下是關於Redis複製功能的幾個重要方面：

• Redis使用異步複製。從Redis 2.8開始，從服務器會以每秒一次的頻率向主服務器報告複製流（replication stream）的處理進度。
• 一個主服務器能夠有多個從服務器。
• 不只主服務器能夠有從服務器，從服務器也能夠有本身的從服務器，多個從服務器之間能夠構成一個圖狀結構。
• 複製功能不會阻塞主服務器： 即便有一個或多個從服務器正在進行初次同步， 主服務器也能夠繼續處理命令請求。
• 複製功能也不會阻塞從服務器： 只要在 redis.conf 文件中進行了相應的設置， 即便從服務器正在進行初次同步， 服務器也可使用舊版本的數據集來處理命令查詢。
• 不過， 在從服務器刪除舊版本數據集並載入新版本數據集的那段時間內， 鏈接請求會被阻塞。
• 你還能夠配置從服務器， 讓它在與主服務器之間的鏈接斷開時， 向客戶端發送一個錯誤。
• 複製功能能夠單純地用於數據冗餘（data redundancy）， 也能夠經過讓多個從服務器處理只讀命令請求來提高擴展性（scalability）： 好比說， 繁重的  SORT  命令能夠交給附屬節點去運行。
• 能夠經過複製功能來讓主服務器免於執行持久化操做： 只要關閉主服務器的持久化功能， 而後由從服務器去執行持久化操做便可。

Redis主從複製實踐

環境：

/data/6380/redis-server
/data/6380/redis.conf
/data/6381/redis-server
/data/6381/redis.conf
/data/6382/redis-server
/data/6382/redis.conf

配置文件示例：

配置文件示例：
redis.conf
bind 127.0.0.1 192.168.29.128
port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
slowlog-log-slower-than 10000
slowlog-max-len 128
protected-mode no

啓動

/data/6380/redis-server /data/6380/redis.conf
/data/6381/redis-server /data/6381/redis.conf
/data/6382/redis-server /data/6382/redis.conf

主節點：6380
從節點：638一、6382
開啓主從：
6381/6382命令行:
redis-cli -p 6381
SLAVEOF 127.0.0.1 6380

運行原理

從服務器以每秒一次的頻率PING主服務器一次，並報告複製流的處理狀況。主服務器記錄各個從服務器最後一次向它發送PING的時間。用戶能夠經過配置，指定網絡延遲的最大值min-slaves-max-lag，以及執行操做所需的至少從服務器數量min-slaves-to-write。
若是至少有min-slaves-to-write個從服務器，而且這些服務器的延遲值都少於min-slaves-max-lag秒，那麼主服務器就會執行客戶端請求的寫操做。你能夠將這個特性看做CAP理論的C的條件放寬版本：儘管不能保證寫操做的持久性，但起碼丟失數量的窗口會被嚴格限制在指定的描述中。
另外一方面，若是條件達不到min-slaves-to-write和min-slaves-max-lag所指定的條件，那麼寫操做就不會執行，主服務器會向請求執行寫操做的客戶端返回一個錯誤。

Redis主從複製管理

主從複製狀態監控：
info replication

主從切換：
slaveof no one

2、Redis Sentinel

Redis-Sentinel是Redis官方推薦的高可用性(HA)接近方案，當用Redis作Master-slave的高可用方案時，假如master宕機了，Redis自己(包括它的不少客戶端)都沒有實現自動進行主備切換，而Redis-sentinel自己也是一個獨立運行的進程，他能監控多個master-slave集羣，發現master宕機後能進行自動切換。

Sentinel的構造

Sentinel是一個監視器，它能夠根據被監視實例的身份和狀態來判斷應該執行何種動做。

功能

• 監控(Monitoring)

Sentinel會不斷地檢查你的主服務器和從服務器是否運做正常。

• 提醒(Notification)

當被監控的某個Redis服務器出現問題時，Sentinel能夠經過API向管理員或者其餘應用程序發送通知。

• 自動故障遷移(Automatic failover)

當一個主服務器不能正常工做時，Sentinel會開始一次自動故障遷移操做，它會將失效主服務器的其中一個從服務器升級爲新的主服務器，並讓失效服務器的其餘從服務器改成負值新的主服務器；當客戶端試圖鏈接失效的主服務器時，集羣也會向客戶端返回新主服務器的地址，使得集羣可使用新主服務器代替失效服務器。

sentinel配置

mkdir /data/26380
cp /usr/local/redis/src/redis-sentinel /data/26380
cd /data/26380
Vim sentinel.conf
port 26380
dir "/tmp"
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel down-after-milliseconds mymaster 60000
sentinel config-epoch mymaster 0
啓動
 ./redis-sentinel ./sentinel.conf

運行一個Sentinel所需的最少配置以下所示：

運行一個 Sentinel 所需的最少配置以下所示：
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 60000 
sentinel failover-timeout mymaster 180000 
sentinel parallel-syncs mymaster 1 
sentinel monitor resque 192.168.1.3 6380 4 
sentinel down-after-milliseconds resque 10000 
sentinel failover-timeout resque 180000 
sentinel parallel-syncs resque 5
    第一行配置指示 Sentinel 去監視一個名爲 mymaster 的主服務器， 這個主服務器的 IP 地址爲 127.0.0.1 ， 端口號爲 6379 ， 而將這個主服務器判斷爲失效至少須要 2 個 Sentinel 贊成 （只要贊成 Sentinel 的數量不達標，自動故障遷移就不會執行）。
    不過要注意， 不管你設置要多少個 Sentinel 贊成才能判斷一個服務器失效， 一個 Sentinel 都須要得到系統中多數（majority） Sentinel 的支持， 才能發起一次自動故障遷移， 並預留一個給定的配置節點 （configuration Epoch ，一個配置節點就是一個新主服務器配置的版本號）。
    換句話說， 在只有少數（minority） Sentinel 進程正常運做的狀況下， Sentinel 是不能執行自動故障遷移的。
其餘選項的基本格式以下：
sentinel <選項的名字> <主服務器的名字> <選項的值>
各個選項的功能以下：
    down-after-milliseconds 選項指定了 Sentinel 認爲服務器已經斷線所需的毫秒數。
若是服務器在給定的毫秒數以內， 沒有返回 Sentinel 發送的 Ping 命令的回覆， 或者返回一個錯誤， 那麼 Sentinel 將這個服務器標記爲主觀下線（subjectively down，簡稱 SDOWN ）。
    不過只有一個 Sentinel 將服務器標記爲主觀下線並不必定會引發服務器的自動故障遷移： 只有在足夠數量的 Sentinel 都將一個服務器標記爲主觀下線以後， 服務器纔會被標記爲客觀下線（objectively down， 簡稱 ODOWN ）， 這時自動故障遷移纔會執行。
將服務器標記爲客觀下線所需的 Sentinel 數量由對主服務器的配置決定。
parallel-syncs 選項指定了在執行故障轉移時， 最多能夠有多少個從服務器同時對新的主服務器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長。
    若是從服務器被設置爲容許使用過時數據集（參見對 redis.conf 文件中對 slave-serve-stale-data 選項的說明）， 那麼你可能不但願全部從服務器都在同一時間向新的主服務器發送同步請求， 由於儘管複製過程的絕大部分步驟都不會阻塞從服務器， 但從服務器在載入主服務器發來的 RDB 文件時， 仍然會形成從服務器在一段時間內不能處理命令請求： 若是所有從服務器一塊兒對新的主服務器進行同步， 那麼就可能會形成全部從服務器在短期內所有不可用的狀況出現。
你能夠經過將這個值設爲 1 來保證每次只有一個從服務器處於不能處理命令請求的狀態。

View Code

配置文件

指定監控master
sentinel monitor mymaster 127.0.0.1 6370 2 
{2表示多少個sentinel贊成}
安全信息
sentinel auth-pass mymaster root
超過15000毫秒後認爲主機宕機
sentinel down-after-milliseconds mymaster 15000  
當主從切換多久後認爲主從切換失敗
sentinel failover-timeout mymaster 900000
這兩個配置後面的數量主從機須要同樣，epoch爲master的版本
sentinel leader-epoch mymaster 1
sentinel config-epoch mymaster 1

Sentinel命令

PING ：返回 PONG 。
SENTINEL masters ：列出全部被監視的主服務器
SENTINEL slaves <master name> 
SENTINEL get-master-addr-by-name <master name> ： 返回給定名字的主服務器的 IP 地址和端口號。 
SENTINEL reset <pattern> ： 重置全部名字和給定模式 pattern 相匹配的主服務器。 
SENTINEL failover <master name> ： 當主服務器失效時， 在不詢問其餘 Sentinel 意見的狀況下， 強制開始一次自動故障遷移。

3、Redis集羣

Redis集羣是一個能夠在多個Redis節點之間進行數據共享的設施(installation)。
Redis集羣不支持那些須要同時處理多個鍵的Redis命令，由於執行這些命令須要在多個Redis節點之間移動數據，而且在高負載的狀況下，這些命令下降Redis集羣的性能，並致使不可預測的行爲。
Redis集羣經過分區(partition)來提供必定程度的可用性(availability)：即便集羣中有一部分節點失效或者沒法進行通信，集羣也能夠繼續處理命令請求。
將數據自動切分(split)到多個節點的能力。
當集羣中的一部分節點失效或者沒法進行通信時，仍然能夠繼續處理命令請求的能力。

Redis集羣數據共享

Redis集羣使用數據分片(sharding)而非一致性哈希(consistency hashing)來實現：一個Redis集羣包含16384個哈希槽(hash slot)，數據庫中的每一個鍵都屬於這16384個哈希槽的其中一個，集羣使用公式CRC16(key)%16384來計算鍵key屬於哪一個槽，其中CRC16(key)語句用於計算鍵key的CRC16校驗和。
節點A負責處理0號至5500號哈希槽。
節點B負責處理5501號至11000號哈希槽。
節點C負責處理11001號至16384號哈希槽。

Redis Cluster

集羣組件安裝

EPEL源安裝ruby支持
yum install ruby rubygems -y
使用國內源
gem sources --add https://gems.ruby-china.org/ --remove https://rubygems.org/
gem install redis -v 3.3.3
gem sources -l
若是沒法使用，可使用aliyun
gem sources -a http://mirrors.aliyun.com/rubygems/ 
gem sources  --remove http://rubygems.org/

配置文件中包含

Redis 集羣由多個運行在集羣模式（cluster mode）下的 Redis 實例組成， 實例的集羣模式須要經過配置來開啓， 開啓集羣模式的實例將可使用集羣特有的功能和命令。

如下是一個包含了最少選項的集羣配置文件示例：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

文件中的 cluster-enabled 選項用於開實例的集羣模式， 而 cluster-conf-file 選項則設定了保存節點配置文件的路徑， 默認值爲 nodes.conf 。
節點配置文件無須人爲修改， 它由 Redis 集羣在啓動時建立， 並在有須要時自動進行更新。
要讓集羣正常運做至少須要三個主節點， 不過在剛開始試用集羣功能時， 強烈建議使用六個節點： 其中三個爲主節點， 而其他三個則是各個主節點的從節點。

cd /data
mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

建立應用

mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

拷貝應用
cp redis.conf redis-server ./7000
啓動應用
cd 7000
./redis-server ./redis.conf

建立集羣

{redis_src_home}/src/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-trib.rb 程序的命令是 create ， 這表示咱們但願建立一個新的集羣。
選項 --replicas 1 
表示咱們但願爲集羣中的每一個主節點建立一個從節點。

集羣客戶端

redis-cli -c -p 7000
set foo bar
get foo

從新分片
./redis-trib.rb reshard 127.0.0.1:7000

集羣管理

集羣狀態
redis-cli -p 7000 cluster nodes | grep master
故障轉移
redis-cli -p 7002 debug segfault
查看狀態
redis-cli -p 7000 cluster nodes | grep master


增長新的節點
./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000
刪除一個節點
redis-trib del-node ip:port '<node-id>' 
刪除master節點以前首先要使用reshard移除master的所有slot,而後再刪除當前節點
添加一個從節點
./redis-trib.rb add-node --slave --master-id $[nodeid] 127.0.0.1:7008 127.0.0.1:7000 

狀態說明

集羣最近一次向節點發送 PING 命令以後， 過去了多長時間還沒接到回覆。
節點最近一次返回 PONG 回覆的時間。
節點的配置節點（configuration epoch）：詳細信息請參考 Redis 集羣規範 。
本節點的網絡鏈接狀況：例如 connected 。
節點目前包含的槽：例如 127.0.0.1:7001 目前包含號碼爲 5960 至 10921 的哈希槽。

注：關注做者微信公衆號，瞭解更多分佈式架構、微服務、netty、MySQL、spring、、性能優化、等知識點。

公衆號：《 Java大蝸牛 》