1. redis主從複製(master/slave)
通過持久化功能，redis保證了即使在服務器重啓的情況下也不會丟失（或少量丟失）數據，但是由於數據是存儲在一臺服務器上的，如果這臺服務器出現故障，比如硬盤損壞，也會導致數據丟失。
爲了避免單點故障，需要將數據複製多份部署在多臺不同的服務器上，即使有一臺服務器出現故障，其他服務器依然可以繼續提供服務。
redis提供了複製(replication)功能來自動實現多臺redis服務器的數據同步。
可通過部署多臺redis，並在配置文件中指定這幾臺redis之間的主從關係，主負責寫入數據，同時把寫入的數據實時同步到從機器，這種模式叫做主從複製。並且redis默認master用於讀寫，slave只能用於讀。
一個master可以有多個slave。
當slave宕掉後，讀請求的處理性能下降。
當master宕掉後，寫請求無法執行。
當master發生故障，需手動將其中一臺slave使用slaveof no one命令提升爲master，其他slave執行slaveof命令指向這個新的master，從新的master處同步數據。
主從複製模式的故障轉移需要手動操作，要實現自動化處理，需要sentine哨兵，實現故障自動轉移。
1.1 主從複製實例
| 名稱 | IP |
| master（主服務器） | 192.168.146.102/24 |
| slave1（從服務器1） | 192.168.146.111/24 |
| slave2（從服務器2） | 192.168.146.112/24 |
首先，修改redis對應的redis.conf配置文件。master和slave均需修改。
# master主服務器配置文件修改以下幾項
[root@CentOS7 src]# vim ../redis.conf
bind 192.168.146.102
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile ""
dbfilename dump.rdb
# slave1從服務器1配置文件修改以下幾項
[root@server1 src]# vim ../redis.conf
bind 192.168.146.111
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile ""
dbfilename dump.rdb
#將當前服務器轉變爲master主服務器的從服務器
slaveof 192.168.146.102 6379
# slave2從服務器2配置文件修改以下幾項
[root@server2 src]# vim ../redis.conf
bind 192.168.146.112
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile ""
dbfilename dump.rdb
#將當前服務器轉變爲master主服務器的從服務器
slaveof 192.168.146.102 6379
然後在所有設備上重啓redis服務。
[root@CentOS7 src]# ./redis-cli shutdown
[root@CentOS7 src]# nohup ./redis-server ../redis.conf
使用info replication命令查看master主服務器的角色
在master主服務器上寫入數據，然後去slave從服務器上去查看。
192.168.146.102:6379> set k1 v1
OK
192.168.146.102:6379> set k2 v2
OK
192.168.146.111:6379> mget k1 k2
1) "v1"
2) "v2"
# slave從服務器可以獲取值，但是無法寫入數據
192.168.146.111:6379> set k3 v3
(error) READONLY You can't write against a read only replica.
192.168.146.112:6379> mget k1 k2
1) "v1"
2) "v2"
1.2 容災處理
當master主服務器出現故障，需手動將slave中的一個提升爲master，剩下的slave掛至新的master上（冷處理）。
slaveof no one：將一臺slave服務器提升至master
slaveof 192.168.146.111 6379：將slave掛至新的master
# 將slave1從服務器1提升至新的master主服務器
192.168.146.111:6379> slaveof no one
OK
# 將slave2從服務器2掛至新的master主服務器
192.168.146.112:6379> slaveof 192.168.146.111 6379
OK
然後將原來的master主服務器重新啓動，掛到新的master主服務器下，成爲slave服務器，然後查看新的master主服務器的角色
1.3 高可用sentinel哨兵
sentinel哨兵是redis官方提供的高可用解決方案，可以用它來監控多個redis服務實例的運行情況。
sentinel會不斷檢查master和slave是否正常。
如果sentinel掛了，就無法監控，所有需要多個sentinel，組成sentinel網絡.
監控同一個master的sentinel會自動連接，組成一個分佈式的sentinel網絡，互相通信並交換彼此關於被監控服務器的信息。
當一個sentinel認爲被監控的服務器已經下線時，它會像網絡中的其他sentinel進行確認，判斷該服務器是否真的已經下線。
如果下線的服務器爲master，那麼sentinel網絡將對下線主服務器進行自動故障轉移，通過將下線主服務器的某個從服務器提升爲新的主服務器，並讓其他從服務器轉移到新的主服務器，以此來讓系統重新回到正常狀態。
下線的舊主服務器重新上線，sentinel會讓它成爲從服務器，掛到新的主服務器下。
sentinel會在master下線後自動執行故障轉移操作，提升一臺slave爲master，並讓其它slave成爲新master的slave。
1. sentinel配置
由於在上述實驗之上做的，所以master/slave發生變化。
| 名稱 | IP |
| master（主服務器） | 192.168.146.111/24 |
| slave1（從服務器1） | 192.168.146.102/24 |
| slave2（從服務器2） | 192.168.146.112/24 |
修改所有服務器的sentinel.conf配置文件
# master主服務器的sentinel.conf文件配置
[root@server1 src]# vim ../sentinel.conf
bind 192.168.146.111
port 26379
daemonize yes
logfile "/var/log/sentinel.log"
sentinel monitor mymaster 192.168.146.111 6379 2
# slave1從服務器1的sentinel.conf文件配置
[root@CentOS7 src]# vim ../sentinel.conf
bind 192.168.146.102
port 26379
daemonize yes
pidfile "/var/run/redis-sentinel.pid"
logfile "/var/log/sentinel.log"
dir "/tmp"
sentinel monitor mymaster 192.168.146.111 6379 2
# slave2從服務器2的sentinel.conf文件配置
[root@server2 src]# vim ../sentinel.conf
bind 192.168.146.112
port 26379
daemonize yes
logfile "/var/log/sentinel.log"
sentinel monitor mymaster 192.168.146.111 6379 2
所有服務器上均啓動sentinel
[root@server1 src]# ./redis-sentinel ../sentinel.conf
當把master（192.168.146.111）關閉後，再重新打開，查看master（192.168.146.111）日誌。
[root@server1 ~]# tailf /var/log/sentinel.log
9384:X 07 Sep 2019 03:50:31.604 * +slave slave 192.168.146.112:6379 192.168.146.112 6379 @ mymaster 192.168.146.111 6379
9384:X 07 Sep 2019 03:50:31.604 * +slave slave 192.168.146.102:6379 192.168.146.102 6379 @ mymaster 192.168.146.111 6379
9412:X 07 Sep 2019 03:52:42.426 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
9412:X 07 Sep 2019 03:52:42.426 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=9412, just started
9412:X 07 Sep 2019 03:52:42.426 # Configuration loaded
9413:X 07 Sep 2019 03:52:42.429 * Increased maximum number of open files to 10032 (it was originally set to 1024).
9413:X 07 Sep 2019 03:52:42.430 * Running mode=sentinel, port=26379.
9413:X 07 Sep 2019 03:52:42.431 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
9413:X 07 Sep 2019 03:52:42.431 # Sentinel ID is fc778fd4228b6fdbf8d61ec1d6c8fb0ccf938794
9413:X 07 Sep 2019 03:52:42.431 # +monitor master mymaster 192.168.146.111 6379 quorum 2
9413:X 07 Sep 2019 03:55:35.232 # +sdown master mymaster 192.168.146.111 6379
9413:X 07 Sep 2019 03:55:35.337 # +new-epoch 5
9413:X 07 Sep 2019 03:55:35.339 # +vote-for-leader af085d0b19173d717da2910283fc07f42dd0947e 5
9413:X 07 Sep 2019 03:55:35.343 # +odown master mymaster 192.168.146.111 6379 #quorum 2/2
9413:X 07 Sep 2019 03:55:35.343 # Next failover delay: I will not start a failover before Sat Sep 7 04:01:35 2019
9413:X 07 Sep 2019 03:55:36.205 # +config-update-from sentinel af085d0b19173d717da2910283fc07f42dd0947e 192.168.146.112 26379 @ mymaster 192.168.146.111 6379
9413:X 07 Sep 2019 03:55:36.206 # +switch-master mymaster 192.168.146.111 6379 192.168.146.102 6379
9413:X 07 Sep 2019 03:55:36.206 * +slave slave 192.168.146.112:6379 192.168.146.112 6379 @ mymaster 192.168.146.102 6379
9413:X 07 Sep 2019 03:55:36.207 * +slave slave 192.168.146.111:6379 192.168.146.111 6379 @ mymaster 192.168.146.102 6379