目錄
環境：
redis-4.0.14，centos7
摘要說明：
redis主從配置：部署多臺redis，將一臺作爲master、其他配置成slave，數據修改時，主從同時修改；當master掛掉之後會從slave中選出一臺作爲master；
哨兵配置：當主從配置成功後，有個問題來了，如何監控master的狀態，這裏就引入了哨兵模式；由一個或多個Sentinel實例組成的Sentinel系統可以監視任意多個主服務器，以及所有從服務器，並在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級爲新的主服務器，然後由新的主服務器代替已下線的主服務器繼續處理命令請求 。
步驟：
一、安裝redis
1、從redis官網下載redis版本如：redis-4.0.14.tar.gz
2、解壓編譯
tar -zxvf redis-4.0.14.tar.gz
cd redis-4.0.14
make && make install
3、單機配置啓動：
使用vi命令配置redis.conf:
#bind 127.0.0.1-如果需要配置外網連接
bind 0.0.0.0
#關閉保護模式-如果需要配置外網連接
daemonize no
protected-mode no
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
啓動：
cd redis-4.0.14/src
./redis-server &
redis.conf的詳細配置爲：
#綁定ip，外網訪問0.0.0.0
bind 127.0.0.1
#保護模式是否開啓
protected-mode yes
#監聽端口
port 6379
# TCP接收隊列長度，受/proc/sys/net/core/somaxconn和tcp_max_syn_backlog這兩個內核參數的影響
tcp-backlog 511
# 一個客戶端空閒多少秒後關閉連接(0代表禁用，永不關閉)
timeout 0
# 如果非零，則設置SO_KEEPALIVE選項來向空閒連接的客戶端發送ACK
tcp-keepalive 300
################################# GENERAL #####################################
# 守護進程模式
daemonize no
supervised no
# pid file 修改pidfile指向路徑
pidfile /var/run/redis_6379.pid
# 指定服務器調試等級
# 可能值：
# debug （大量信息，對開發/測試有用）
# verbose （很多精簡的有用信息，但是不像debug等級那麼多）
# notice （適量的信息，基本上是你生產環境中需要的）
# warning （只有很重要/嚴重的信息會記錄下來）
loglevel notice
# 指明日誌文件名
logfile ""
# 設置數據庫個數
databases 16
# By default Redis shows an ASCII art logo only when started to log to the
# standard output and if the standard output is a TTY. Basically this means
# that normally a logo is displayed only in interactive sessions.
#
# However it is possible to force the pre-4.0 behavior and always show a
# ASCII art logo in startup logs by setting the following option to yes.
always-show-logo yes
# 會在指定秒數和數據變化次數之後把數據庫寫到磁盤上
# 900秒（15分鐘）之後，且至少1次變更
# 300秒（5分鐘）之後，且至少10次變更
# 60秒之後，且至少10000次變更
save 900 1
save 300 10
save 60 10000
# 默認如果開啓RDB快照(至少一條save指令)並且最新的後臺保存失敗，Redis將會停止接受寫操作
# 這將使用戶知道數據沒有正確的持久化到硬盤，否則可能沒人注意到並且造成一些災難
stop-writes-on-bgsave-error yes
# 當導出到 .rdb 數據庫時是否用LZF壓縮字符串對象
rdbcompression yes
# 版本5的RDB有一個CRC64算法的校驗和放在了文件的最後。這將使文件格式更加可靠。
rdbchecksum yes
# 持久化數據庫的文件名
dbfilename dump.rdb
# 工作目錄
dir ./
# 當master服務設置了密碼保護時，slav服務連接master的密碼
# masterauth <master-password>
# 當一個slave失去和master的連接，或者同步正在進行中，slave的行爲可以有兩種：
#
# 1) 如果 slave-serve-stale-data 設置爲 "yes" (默認值)，slave會繼續響應客戶端請求，
# 可能是正常數據，或者是過時了的數據，也可能是還沒獲得值的空數據。
# 2) 如果 slave-serve-stale-data 設置爲 "no"，slave會回覆"正在從master同步
# （SYNC with master in progress）"來處理各種請求，除了 INFO 和 SLAVEOF 命令。
slave-serve-stale-data yes
# 你可以配置salve實例是否接受寫操作。可寫的slave實例可能對存儲臨時數據比較有用(因爲寫入salve
# 的數據在同master同步之後將很容易被刪除
slave-read-only yes
# 是否在slave套接字發送SYNC之後禁用 TCP_NODELAY？
# 如果你選擇“yes”Redis將使用更少的TCP包和帶寬來向slaves發送數據。但是這將使數據傳輸到slave
# 上有延遲，Linux內核的默認配置會達到40毫秒
# 如果你選擇了 "no" 數據傳輸到salve的延遲將會減少但要使用更多的帶寬
repl-diskless-sync no
#repl無磁盤同步延遲
repl-diskless-sync-delay 5
# 是否在slave套接字發送SYNC之後禁用 TCP_NODELAY？
# 如果你選擇“yes”Redis將使用更少的TCP包和帶寬來向slaves發送數據。但是這將使數據傳輸到slave
# 上有延遲，Linux內核的默認配置會達到40毫秒
# 如果你選擇了 "no" 數據傳輸到salve的延遲將會減少但要使用更多的帶寬
repl-disable-tcp-nodelay no
# slave的優先級是一個整數展示在Redis的Info輸出中。如果master不再正常工作了，哨兵將用它來
# 選擇一個slave提升=升爲master。
# 優先級數字小的salve會優先考慮提升爲master，所以例如有三個slave優先級分別爲10，100，25，
# 哨兵將挑選優先級最小數字爲10的slave。
# 0作爲一個特殊的優先級，標識這個slave不能作爲master，所以一個優先級爲0的slave永遠不會被
# 哨兵挑選提升爲master
slave-priority 100
# 密碼驗證
# 警告：因爲Redis太快了，所以外面的人可以嘗試每秒150k的密碼來試圖破解密碼。這意味着你需要
# 一個高強度的密碼，否則破解太容易了
# requirepass foobared
# redis實例最大佔用內存，不要用比設置的上限更多的內存。一旦內存使用達到上限，Redis會根據選定的回收策略（參見：maxmemmory-policy）刪除key
# maxmemory <bytes>
# 最大內存策略：如果達到內存限制了，Redis如何選擇刪除key。你可以在下面五個行爲裏選：
# volatile-lru -> 根據LRU算法刪除帶有過期時間的key。
# allkeys-lru -> 根據LRU算法刪除任何key。
# volatile-random -> 根據過期設置來隨機刪除key, 具備過期時間的key。
# allkeys->random -> 無差別隨機刪, 任何一個key。
# volatile-ttl -> 根據最近過期時間來刪除（輔以TTL）, 這是對於有過期時間的key
# noeviction -> 誰也不刪，直接在寫操作時返回錯誤。
# maxmemory-policy noeviction
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no
# 默認情況下，Redis是異步的把數據導出到磁盤上。這種模式在很多應用裏已經足夠好，但Redis進程
# 出問題或斷電時可能造成一段時間的寫操作丟失(這取決於配置的save指令)。
#
# AOF是一種提供了更可靠的替代持久化模式，例如使用默認的數據寫入文件策略（參見後面的配置）
# 在遇到像服務器斷電或單寫情況下Redis自身進程出問題但操作系統仍正常運行等突發事件時，Redis
# 能只丟失1秒的寫操作。
#
# AOF和RDB持久化能同時啓動並且不會有問題。
# 如果AOF開啓，那麼在啓動時Redis將加載AOF文件，它更能保證數據的可靠性。
appendonly no
# aof文件名
appendfilename "appendonly.aof"
# fsync() 系統調用告訴操作系統把數據寫到磁盤上，而不是等更多的數據進入輸出緩衝區。
# 有些操作系統會真的把數據馬上刷到磁盤上；有些則會盡快去嘗試這麼做。
#
# Redis支持三種不同的模式：
#
# no：不要立刻刷，只有在操作系統需要刷的時候再刷。比較快。
# always：每次寫操作都立刻寫入到aof文件。慢，但是最安全。
# everysec：每秒寫一次。折中方案。
appendfsync everysec
# appendfsync no
# 如果AOF的同步策略設置成 "always" 或者 "everysec"，並且後臺的存儲進程（後臺存儲或寫入AOF
# 日誌）會產生很多磁盤I/O開銷。某些Linux的配置下會使Redis因爲 fsync()系統調用而阻塞很久。
# 注意，目前對這個情況還沒有完美修正，甚至不同線程的 fsync() 會阻塞我們同步的write(2)調用。
#
# 爲了緩解這個問題，可以用下面這個選項。它可以在 BGSAVE 或 BGREWRITEAOF 處理時阻止主進程進行fsync()。
#
# 這就意味着如果有子進程在進行保存操作，那麼Redis就處於"不可同步"的狀態。
# 這實際上是說，在最差的情況下可能會丟掉30秒鐘的日誌數據。（默認Linux設定）
#
# 如果你有延時問題把這個設置成"yes"，否則就保持"no"，這是保存持久數據的最安全的方式
no-appendfsync-on-rewrite no
# 自動重寫AOF文件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# AOF文件可能在尾部是不完整的（這跟system關閉有問題，尤其是mount ext4文件系統時
# 沒有加上data=ordered選項。只會發生在os死時，redis自己死不會不完整）。
# 那redis重啓時load進內存的時候就有問題了。
# 發生的時候，可以選擇redis啓動報錯，並且通知用戶和寫日誌，或者load儘量多正常的數據。
# 如果aof-load-truncated是yes，會自動發佈一個log給客戶端然後load（默認）。
# 如果是no，用戶必須手動redis-check-aof修復AOF文件纔可以。
# 注意，如果在讀取的過程中，發現這個aof是損壞的，服務器也是會退出的，
# 這個選項僅僅用於當服務器嘗試讀取更多的數據但又找不到相應的數據時。
aof-load-truncated yes
aof-use-rdb-preamble no
# Lua 腳本的最大執行時間，毫秒爲單位
lua-time-limit 5000
# Redis慢查詢日誌可以記錄超過指定時間的查詢
slowlog-log-slower-than 10000
# 這個長度沒有限制。只是要主要會消耗內存。你可以通過 SLOWLOG RESET 來回收內存。
slowlog-max-len 128
# redis延時監控系統在運行時會採樣一些操作，以便收集可能導致延時的數據根源。
# 通過 LATENCY命令 可以打印一些圖樣和獲取一些報告，方便監控
# 這個系統僅僅記錄那個執行時間大於或等於預定時間（毫秒）的操作,
# 這個預定時間是通過latency-monitor-threshold配置來指定的，
# 當設置爲0時，這個監控系統處於停止狀態
latency-monitor-threshold 0
# Redis能通知 Pub/Sub 客戶端關於鍵空間發生的事件，默認關閉
notify-keyspace-events ""
# 當hash只有少量的entry時，並且最大的entry所佔空間沒有超過指定的限制時，會用一種節省內存的
# 數據結構來編碼。可以通過下面的指令來設定限制
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
# 與hash和list相似，有序集合也可以用一種特別的編碼方式來節省大量空間。
# 這種編碼只適合長度和元素都小於下面限制的有序集合
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
# HyperLogLog稀疏結構表示字節的限制。該限制包括
# 16個字節的頭。當HyperLogLog使用稀疏結構表示
# 這些限制，它會被轉換成密度表示。
# 值大於16000是完全沒用的，因爲在該點
# 密集的表示是更多的內存效率。
# 建議值是3000左右，以便具有的內存好處, 減少內存的消耗
hll-sparse-max-bytes 3000
# 啓用哈希刷新，每100個CPU毫秒會拿出1個毫秒來刷新Redis的主哈希表（頂級鍵值映射表）
activerehashing yes
# 客戶端的輸出緩衝區的限制，可用於強制斷開那些因爲某種原因從服務器讀取數據的速度不夠快的客戶端
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
# 默認情況下，“hz”的被設定爲10。提高該值將在Redis空閒時使用更多的CPU時，但同時當有多個key
# 同時到期會使Redis的反應更靈敏，以及超時可以更精確地處理
hz 10
# 當一個子進程重寫AOF文件時，如果啓用下面的選項，則文件每生成32M數據會被同步
aof-rewrite-incremental-fsync yes
二、主從配置
主從一般部署在不同機器上，複製時存在網絡延時問題即傳輸延遲問題，redis提供repl-disable-tcp-nodelay參數決定是否關閉TCP_NODELAY：
參數關閉時：默認爲關閉 無論大小都會及時發佈到從節點，佔帶寬，適用於主從網絡好的場景；
參數啓用時：主節點合併所有數據成TCP包節省帶寬，默認爲40毫秒發一次，取決於內核，主從的同步延遲40毫秒，適用於網絡環境複雜或帶寬緊張，如跨機房；
通常的主從有以下幾種模式：
一主一從：用於主節點故障轉移從節點，當主節點的“寫”命令併發高且需要持久化，可以只在從節點開啓AOF（主節點不需要）
一主多從：針對“讀”較多的場景，“讀”由多個從節點來分擔，但節點越多，主節點同步到多節點的次數也越多，影響帶寬，也加重主節點的穩定
樹狀主從（級聯主從）：一主多從的缺點（主節點推送次數多壓力大）可用些方案解決，主節點只推送一次數據到從節點1，再由從節點2推送到11，減輕主節點推送的壓力
通常的主從配置爲一主二從，假設我們現在有三臺機器（一般需要不同的節點）：
192.168.1.131
192.168.1.132
192.168.1.133
假如使用192.168.1.131當作master，配置redis.conf:
bind 192.168.1.131
protected-mode yes
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
masterauth test123456
192.168.1.132當作slave，配置redis.conf：
bind 192.168.1.132
protected-mode yes
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
slaveof 192.168.1.131 6379
masterauth test123456
192.168.1.132當作slave，配置redis.conf：
bind 192.168.1.133
protected-mode yes
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "/var/log/redis.log"
dir /var/redis/
slaveof 192.168.1.131 6379
masterauth test123456
先後啓動192.168.1.131、192.168.1.132、192.168.1.133的redis;
三、哨兵配置
高可用的另一個點就是如果主節點掛了，如何主動切換到從節點？這裏就要使用哨兵模式；
原理：當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，並通知應用方，實現高可用性。
主要作用：
-
監控：Sentinel會不斷的檢查主服務器和從服務器是否正常運行。
-
通知：當被監控的某個Redis服務器出現問題，Sentinel通過API腳本向管理員或者其他的應用程序發送通知。
-
自動故障轉移：當主節點不能正常工作時，Sentinel會開始一次自動的故障轉移操作，它會將與失效主節點是主從關係的其中一個從節點升級爲新的主節點， 並且將其他的從節點指向新的主節點。
-
配置提供者：在Redis Sentinel模式下，客戶端應用在初始化時連接的是Sentinel節點集合，從中獲取主節點的信息。
哨兵有三個定時監控任務完成對各節點的發現和監控：
假設現在我們有三臺機器來配置哨兵：
192.168.1.134
192.168.1.135
192.168.1.136
Sentinel.conf配置文件主要參數解析：
# 端口
port 26379
# 工作路徑，sentinel一般指定/tmp比較簡單
dir /tmp
# 哨兵監控這個master，在至少quorum個哨兵實例都認爲master down後把master標記爲odown
# （objective down客觀down；相對應的存在sdown，subjective down，主觀down）狀態。
# slaves是自動發現，所以你沒必要明確指定slaves。
sentinel monitor mymaster 127.0.0.1 6379 2
## 設置master和slaves驗證密碼
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# master或slave多長時間（默認30秒）不能使用後標記爲s_down狀態。
sentinel down-after-milliseconds mymaster 30000
# 如果master重新選出來後，其它slave節點能同時並行從新master同步數據的臺數有多少個，顯然該值越大，所有slave節點完成同步切換的整體速度越快，但如果此時正好有人在訪問這些slave，可能造成讀取失敗，影響面會更廣。最保守的設置爲1，同一時間，只能有一臺幹這件事，這樣其它slave還能繼續服務，但是所有slave全部完成緩存更新同步的進程將變慢。
sentinel parallel-syncs mymaster 1
# 該參數指定一個時間段，在該時間段內沒有實現故障轉移成功，則會再一次發起故障轉移的操作，單位毫秒
sentinel failover-timeout mymaster 180000
# 不允許使用SENTINEL SET設置notification-script和client-reconfig-script。
sentinel deny-scripts-reconfig yes
三臺可以統一配置爲：
port 26379
daemonize yes
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/sentinel.log"
dir "/tmp"
sentinel monitor mymaster 192.168.1.131 6379 2
sentinel auth-pass mymaster01 test123456
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
切記配置 sentinel monitor mymaster 192.168.1.131 6379 2時不要配置成127.0.0.1
先後使用下列命令先後啓動三臺哨兵：
cd /src
./redis-sentinel ../sentinel.conf
