配置文件中的各個參數，詳解
2、主機(master)配置:
bind：0.0.0.0 #表示允許所有遠程訪問。如果想指定限制訪問，可設置對應的 ip。
port：6379 #關閉保護模式，可以外部訪問。
daemonize：yes # 設置為后臺啟動。
logfile：./redis.log # 日志文件。
requirepass：pwdtest@2019 #設置 redis 連接密碼。
masterauth：pwdtest@2019 #slave 服務連接 master 的密碼
3、從機(slave)的配置和主機相似，不同的地方是需要使用replicaof指定主機（master）的IP地址和端口，需要注意的是老版本使用的是 slaveof
當本機為 slave 服務時，設置 master 服務的IP地址及端口，在 redis 啟動的時候會自動跟 master 進行數據同步
4、啟動:切換到 bin 目錄，使用./redis-server即可啟動 redis 服務，但是這種方式沒有指明配置文件，redis 將采用默認配置，所以我們需要讓 redis 按照我們的配置文件來啟動,啟動時指定剛才我們復制到 etc 文件夾下的redis.conf
三、Sentinel(哨兵)模式:
1、哨兵模式詳解
Redis Sentinel是Redis 的高可用性解決方案，由一個或多個Sentinel（哨兵）實例組成。它可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器，并在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級為新的主服務器，它的主要功能如下：
監控(Monitoring)：Sentinel會不斷地檢查你的主服務器和從服務器是否運作正常。
通知(Notification)：當被監控的某個 Redis 服務器出現問題時， Sentinel可以通過API向管理員或者其他應用程序發送通知。
故障遷移：當主服務器不能正常工作時，Sentinel會自動進行故障遷移，也就是主從切換。
統一的配置管理：連接者詢問sentinel取得主從的地址。
2、原理:
Sentinel 使用的算法核心是 Raft 算法，主要用途就是用于分布式系統，系統容錯，以及Leader選舉，每個Sentinel都需要定期的執行以下任務：
每個 Sentinel 會自動發現其他 Sentinel 和從服務器，它以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發送一個 PING 命令。
如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那么這個實例會被 Sentinel 標記為主觀下線。 有效回復可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一個主服務器被標記為主觀下線， 那么正在監視這個主服務器的所有Sentinel要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。
如果一個主服務器被標記為主觀下線， 并且有足夠數量的Sentinel（至少要達到配置文件指定的數量）在指定的時間范圍內同意這一判斷， 那么這個主服務器被標記為客觀下線。
在一般情況下， 每個Sentinel會以每 10 秒一次的頻率向它已知的所有主服務器和從服務器發送 INFO 命令。 當一個主服務器被Sentinel標記為客觀下線時，Sentinel向下線主服務器的所有從服務器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次。
當沒有足夠數量的Sentinel同意主服務器已經下線， 主服務器的客觀下線狀態就會被移除。 當主服務器重新向Sentinel的 PING 命令返回有效回復時， 主服務器的主管下線狀態就會被移除。
3、哨兵的配置主要就是修改sentinel.conf配置文件中的參數，在Redis安裝目錄即可看到此配置文件
參數詳解
# 哨兵sentinel實例運行的端口，默認26379
port 26379
# 哨兵sentinel的工作目錄
dir ./
# 是否開啟保護模式，默認開啟。
protected-mode:no
# 是否設置為后臺啟動。
daemonize:yes
# 哨兵sentinel的日志文件
logfile:./sentinel.log
# 哨兵sentinel監控的redis主節點的
## ip：主機ip地址
## port：哨兵端口號
## master-name：可以自己命名的主節點名字（只能由字母A-z、數字0-9 、這三個字符".-_"組成。）
## quorum：當這些quorum個數sentinel哨兵認為master主節點失聯 那么這時 客觀上認為主節點失聯了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 當在Redis實例中開啟了requirepass，所有連接Redis實例的客戶端都要提供密碼。
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
# 指定主節點應答哨兵sentinel的最大時間間隔，超過這個時間，哨兵主觀上認為主節點下線，默認30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 指定了在發生failover主備切換時，最多可以有多少個slave同時對新的master進行同步。這個數字越小，完成failover所需的時間就越長；反之，但是如果這個數字越大，就意味著越多的slave因為replication而不可用。可以通過將這個值設為1，來保證每次只有一個slave，處于不能處理命令請求的狀態。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障轉移的超時時間failover-timeout，默認三分鐘，可以用在以下這些方面：
## 1. 同一個sentinel對同一個master兩次failover之間的間隔時間。
## 2. 當一個slave從一個錯誤的master那里同步數據時開始，直到slave被糾正為從正確的master那里同步數據時結束。
## 3. 當想要取消一個正在進行的failover時所需要的時間。
## 4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時，slaves依然會被正確配置為指向master，但是就不按parallel-syncs所配置的規則來同步數據了
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# 當sentinel有任何警告級別的事件發生時（比如說redis實例的主觀失效和客觀失效等等），將會去調用這個腳本。一個腳本的最大執行時間為60s，如果超過這個時間，腳本將會被一個SIGKILL信號終止，之后重新執行。
# 對于腳本的運行結果有以下規則：
## 1. 若腳本執行后返回1，那么該腳本稍后將會被再次執行，重復次數目前默認為10。
## 2. 若腳本執行后返回2，或者比2更高的一個返回值，腳本將不會重復執行。
## 3. 如果腳本在執行過程中由于收到系統中斷信號被終止了，則同返回值為1時的行為相同。
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 這個腳本應該是通用的，能被多次調用，不是針對性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/
4、搭建：編輯 sentinel.conf，配置文件修改如
//端口默認為26379。
port:26379
//關閉保護模式，可以外部訪問。
protected-mode:no
//設置為后臺啟動。
daemonize:yes
//日志文件。
logfile:./sentinel.log
//指定主機IP地址和端口，并且指定當有2臺哨兵認為主機掛了，則對主機進行容災切換。
sentinel monitor mymaster 192.168.231.130 6379 2
//當在Redis實例中開啟了requirepass，這里就需要提供密碼。
sentinel auth-pass mymaster pwdtest@2019
//這里設置了主機多少秒無響應，則認為掛了。
sentinel down-after-milliseconds mymaster 3000
//主備切換時，最多有多少個slave同時對新的master進行同步，這里設置為默認的1。
sentinel parallel-syncs mymaster 1
//故障轉移的超時時間，這里設置為三分鐘。
sentinel failover-timeout mymaster 180000
5、啟動：redis-sentinel ./entinel.conf(配置文件路徑)三、缺點:資源使用：每個 Sentinel 實例也會占用系統資源，包括 CPU 和內存，尤其是在大型集群中。
網絡依賴性：Sentinel 的效果很大程度上依賴于網絡的可靠性。網絡分區或是延遲高的情況可能會導致誤判或故障轉移延遲。
冷啟動問題：如果所有 Redis 節點同時宕機，Sentinel 系統無法自動恢復，需要手動干預來重新設置主節點和從節點。
數據丟失風險：在發生故障轉移時，如果還有未同步到從節點的數據，那么這部分數據可能會丟失。這是因為 Redis 使用異步復制。
四、寫操作局限性
單點瓶頸：在一主多從架構中，所有寫操作都必須由主節點處理。這意味著主節點的處理能力和資源（CPU、內存、網絡帶寬）將直接限制系統的寫入吞吐量。
數據同步延遲：盡管從節點可以提供讀擴展性，它們依賴于與主節點的數據同步。高寫負載情況下，數據復制到從節點可能會經歷延遲,影響了數據的最終一致性。
故障風險：如主節點出現故障，整個系統的寫能力會喪失直到故障轉移完成并且一個從節點被提升為新的主節點。這個過程可能會導致服務中斷。