是什么
行話：也就是我們所說的主從復制，主機數據更新后根據配置和策略自動同步到備機的 master/slave 機制，Master以寫為主，Slave 以讀為主
能干嘛
- 數據冗余：主從復制實現了數據的熱備份，是持久化之外的一種數據冗余方式
- 故障恢復：當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復；實際上是一種服務的冗余
- 負載均衡：在主從復制的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務（即寫Redis數據時應用連接主節點，讀Redis數據時應用連接從節點），分擔服務器負載；尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載
- 高可用基石：由於主從復制是哨兵和集群能夠實施的基礎，因此說主從復制是Redis高可用的基礎
Redis主從復制講解
info replication:查看 目標redis 主從情況
配從庫不配主庫
從庫配置：slaveof 主庫IP 主庫端口
注：slaveof 進行配置的話，每次斷開后都需要重新連接，除非配置進redis.conf文件中
一旦從庫 跟隨了 主庫，從庫可讀不可寫，首次是全量同步 (這里的首次是執行slaveof命令時 ) 之后是增量，若從庫同步之前存在 與主庫相同的 key的 數據，則主庫的 數據覆蓋從庫
常用策略
策略1：一主二從
此一主二從 可以水平擴展為一主多從，主機主要負責寫，從機主要負責讀
主機down掉在沒有哨兵機制的情況下,從機只會靜默等待 直至主機恢復運行狀態
策略2：薪火相傳
上一個Slave可以是下一個slave的Master，Slave同樣可以接收其他slaves的連接和同步請求，那么該slave作為了鏈條中下一個的master,可以有效減輕master的寫壓力。
第一個開頭的事master，其他都是slave，只是中間的slave是下一個的master
復制原理
Slave啟動成功連接到master后會發送一個sync命令
Master接到命令啟動后台的存盤進程，同時收集所有接收到的用於修改數據集命令，
在后台進程執行完畢之后，master將傳送整個數據文件到slave,以完成一次完全同步
- 全量復制：而slave服務在接收到數據庫文件數據后，將其存盤並加載到內存中。
- 增量復制：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步
但是只要是重新連接master,一次完全同步（全量復制)將被自動執行
哨兵模式
能夠后台監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫
以一主二從的策略為例:
- 自定義的/myredis目錄下新建sentinel.conf文件，名字絕不能錯
- 配置哨兵,填寫內容
sentinel monitor 被監控數據庫名字(自己起名字) 127.0.0.1 6379 1
上面最后一個數字1，表示主機掛掉后salve投票看讓誰接替成為主機，得票數多少后成為主機
啟動哨兵：Redis-sentinel /myredis/sentinel.conf
正常主從演示，原有的master掛了
投票新選,重新主從繼續開工,info replication查查看
原有的down掉主機Master恢復運轉，則輪為從機Slave
缺點：復制延時
由於所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。