RDB和AOF的優缺點
RDB優點：
（1）RDB會生成多個資料檔案，每個資料檔案都代表了某個時刻中redis的資料，這種多個資料
檔案方式，非常适合冷備份。
（2）RBD可以最小化redis的性能，父程序在儲存RBD檔案時唯一要做的就是fork出一個子程序，
讓子程序對磁盤IO進行RDB持久化。
（3）RDB在恢複大資料集時的速度比AOF的恢複速度要快
RDB缺點：
（1）不能實時儲存資料，可能會丢失上一次執行RDB備份到目前的記憶體資料
（2）當資料量非常大的時候，從父程序fork子程序進行儲存RDB檔案需要一段時間，可能是毫秒或者秒，取決于
磁盤IO性能。而且可能會造成伺服器在一定時間内停止處理用戶端，如果資料非常龐大并且CPU使用率高
那麼這種時間可能會長達一秒或更久。
AOF優點：
（1）更好的保護資料不丢失，一般AOF每隔一秒，通過背景線程執行一次fsync操作，最多丢失一秒資料。
（2）日志檔案以append-only模式寫入，是以沒有任何磁盤尋址的開銷，寫入性能非常高，而且檔案不容易破損，
即使檔案尾部破損，也很容易修複。
（3） AOF檔案體積變得過大時，自動地在背景對AOF進行重寫:重寫後的新AOF檔案包含了
恢複目前資料集所需的最小指令集合。整個重寫操作是絕對安全的，因為Redis在建立新 AOF檔案
的過程中，append模式不斷的将修改資料追加到現有的 AOF檔案裡面，即使重寫過程中發生停
機，現有的 AOF檔案也不會丢失。而一旦新AOF檔案建立完畢，Redis就會從舊AOF檔案切換到新
AOF檔案，并開始對新AOF檔案進行追加操作。
（4）AOF日志檔案的指令通過非常可讀的方式進行記錄，這個特性非常适合做災難性的誤删除的緊急恢複。
比如某人不小心用flushall指令清空了所有資料，隻要這個時候背景rewrite還沒有發生，那麼就可以立即拷貝AOF檔案，
将最後一條flushall指令給删了，然後再将該AOF檔案放回去，就可以通過恢複機制，自動恢複所有資料
AOF缺點：
（1）即使有些操作是重複的也會全部記錄，AOF 的檔案大小要大于 RDB 格式的檔案
（2）AOF 在恢複大資料集時的速度比 RDB 的恢複速度要慢
（3）根據fsync政策不同,AOF速度可能會慢于RDB
（4）bug 出現的可能性更多
master:
slave1
slave2
同步日志
測試同步
哨兵的使用和實作機制
bind 0.0.0.0
masterauth 123456
requirepass 123456
#以上三個配置選項必須一緻
master伺服器狀态
配置slave1
配置slave2
sentinel配置Sentinel實際上是一個特殊的redis伺服器,有些redis指令支援,但很多指令并不支援.預設監聽在26379/tcp端口.
哨兵可以不和Redis伺服器部署在一起，但一般部署在一起，所有redis節點使用相同的以下示例的配置檔案
三個哨兵伺服器的配置都如下
三台哨兵伺服器都要啟動
在sentinel狀态中尤其是最後一行，涉及到masterIP是多少，有幾個slave，有幾個sentinels，必須是符合全部伺服器數量
故障轉移時sentinel的資訊：
故障轉移後slave節點redis.conf中的replicaof行會自動指向新的master IP位址
哨兵配置檔案的sentinel monitor IP 同樣也會被修改
在原 master上觀察狀态
有新的slave加入
每個redis 節點采用相同的硬體配置、相同的密碼、相同的redis版本
所有redis伺服器必須沒有任何資料
準備六台主機，位址如下：
192.168.80.125
192.168.80.126
192.168.80.127
192.168.80.128
192.168.80.129
192.168.80.130
所有6台主機都執行以下配置
[root@centos8 ~]#dnf -y install redis
每個節點修改redis配置，必須開啟cluster功能的參數