通過持久化功能，Redis保證了即使在服務器重啓的情況下也不會丟失(或少量丟失)數據，因爲持久化會把內存中數據保存到硬盤上，重啓會從硬盤上加載數據。但是由於數據是存儲在一臺服務器上的，如果這臺服務器出現硬盤故障等問題，也會導致數據都是。
爲了避免單點故障，通常的做法是將數據庫複製多個副本以部署在不同的服務器上，這樣即使有一臺服務器出現故障，其他服務器已讓可以繼續提供服務。爲此，Redis提供了複製(replication)功能，可以實現當一臺數據庫中的數據更新後，自動將更新的數據同步到其他數據庫上。
在複製的概念中，數據庫分爲兩類,一類是主數據庫(master),另一類是從數據庫(slave)。主數據庫可以進行讀寫操作，當寫操作導致數據變化會自動將數據同步給從數據庫。而從數據庫一般是隻讀的，並接受主數據庫同步過來的數據。一個主數據庫可以擁有多個從數據庫，而一個從數據庫只能擁有一個主數據庫。
主從數據庫的配置：
主數據庫不用配置，從數據庫的配置文件（redis.conf）中可以加載主數據庫的信息，也可以在啓動時，使用 redis-server --port 6380 --slaveof 127.0.0.1 6379 命令指明主數據庫的 IP 和端口。從數據庫一般是隻讀，可以改爲可寫，但寫入的數據很容易被主同步沒，所以還是隻讀就可以。也可以在運行時使用 slaveof ip port 命令，停止原來的主，切換成剛剛設置的主 slaveof no one會把自己變成主。
主從複製原理：
- 從數據庫連接主數據庫，發送SYNC命令;
- 主數據庫接收到SYNC命令後，可以執行BGSAVE命令生成RDB文件並使用緩衝區記錄此後執行的所有寫命令;
- 主數據庫BGSAVE執行完後，向所有從數據庫發送快照文件，並在發送期間繼續記錄被執行的寫命令;
- 從數據庫收到快照文件後丟棄所有舊數據，載入收到的快照;
- 主數據庫快照發送完畢後開始向從數據庫發送緩衝區中的寫命令;
- 從數據庫完成對快照的載入，開始接受命令請求，並執行來自主數據庫緩衝區的寫命令;(從數據庫初始化完成)
- 主數據庫每執行一個寫命令就會向從數據庫發送相同的寫命令，從數據庫接收並執行收到的寫命令(從數據庫初始化完成後的操作)
- 出現斷開重連後，2.8之後的版本會將斷線期間的命令傳給從數據庫，增量複製。
- 主從剛剛連接的時候，進行全量同步;全同步結束後，進行增量同步。當然，如果有需要，slave在任何時候都可以發起全量同步。Redis的策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。
優點:
- 支持主從複製，主機會自動將數據同步到從機，可以進行讀寫分離;
- 爲了分載Master的讀操作壓力，Slave服務器可以爲客戶端提供只讀操作的服務，寫服務依然必須由Master來完成;
- Slave同樣可以接受其他Slaves的連接和同步請求，這樣可以有效地分載Master的同步壓力;
- Master Server是以非阻塞的方式爲Slaves提供服務。所以在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請求;
- Slave Server同樣是以阻塞的方式完成數據同步。在同步期間，如果有客戶端提交查詢請求，Redis則範湖同步之前的數據。
缺點:
- Redis不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啓或者手動切換前端的IP才能恢復;
- 主機宕機，宕機前有部分數據未能及時同步到從機，切換IP後還會引入數據不一致的問題，降低了系統的可用性;
- 如果多個Slave斷線了，需要重啓的時候，儘量不要在同一時間段進行重啓。因爲只要Slave啓動，就會發送sync請求和主機全量同步，當多個Slave重啓的時候，可能會導致Master IO劇增從而宕機。
- Redis較難支持在線擴容，在集羣容量達到上限時在線擴容會變得很複雜;
二、哨兵模式
第一種主從同步/複製的模式，當主服務器宕機後，需要手動把一臺從服務器切換爲主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作爲進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
哨兵模式的作用:
- 通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器;
- 當哨兵監測到master宕機，會自動將slave切換到master，然後通過發佈訂閱模式通過其他的從服務器，修改配置文件，讓它們切換主機;
- 然而一個哨兵進程對Redis服務器進行監控，也可能會出現問題，爲此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
故障切換的過程：
假設主服務器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行 failover 過程，僅僅是哨兵1主觀的認爲主服務器不可用，這個現象成爲主觀下線。當後面的哨兵也檢測到主服務器不可用，並且數量達到一定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行 failover 操作。切換成功後，就會通過發佈訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱爲客觀下線。這樣對於客戶端而言，一切都是透明的。
哨兵模式的配置：
配置一主二從和三個哨兵的 Redis 服務器來演示這個過程
主從服務器配置
# 使用Redis服務器可以跨網絡訪問
bind 0.0.0.0
# 設置密碼
requirepass "123456"
# 以下有關slaveof的配置只是配置從服務器，主服務器不需要配置
# 指定主服務器
slaveof 192.168.11.128 6379
# 主服務器密碼
masterauth 123456
哨兵配置
# 禁止保護模式
protected-mode no
# 配置監聽的主服務器，這裏sentinel monitor代表監控，mymaster代表服務器的名稱，可以自定義，
192.168.11.128代表監控的主服務器，6379代表端口，2代表只有兩個或兩個以上的哨兵認爲主服務器不可用的時候，纔會進行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定義服務的密碼，mymaster是服務名稱，123456是Redis服務器密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
配置3個哨兵，每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.conf文件，copy一份進行修改
啓動
注意啓動的順序。首先是主機（192.168.11.128）的 Redis 服務進程，然後啓動從機的 Redis 服務進程，最後啓動3個哨兵的服務進程。
哨兵模式的工作方式：
- 每個Sentinel（哨兵）進程以每秒鐘一次的頻率向整個集羣中的Master主服務器，Slave從服務器以及其他Sentinel（哨兵）進程發送一個 PING 命令。
- 如果一個實例（instance）距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel（哨兵）進程標記爲主觀下線（SDOWN）
- 如果一個Master主服務器被標記爲主觀下線（SDOWN），則正在監視這個Master主服務器的所有 Sentinel（哨兵）進程要以每秒一次的頻率確認Master主服務器的確進入了主觀下線狀態
- 當有足夠數量的 Sentinel（哨兵）進程（大於等於配置文件指定的值）在指定的時間範圍內確認Master主服務器進入了主觀下線狀態（SDOWN）， 則Master主服務器會被標記爲客觀下線（ODOWN）
- 在一般情況下， 每個 Sentinel（哨兵）進程會以每 10 秒一次的頻率向集羣中的所有Master主服務器、Slave從服務器發送 INFO 命令。
- 當Master主服務器被 Sentinel（哨兵）進程標記爲客觀下線（ODOWN）時，Sentinel（哨兵）進程向下線的 Master主服務器的所有 Slave從服務器發送 INFO 命令的頻率會從 10 秒一次改爲每秒一次。
- 若沒有足夠數量的 Sentinel（哨兵）進程同意 Master主服務器下線， Master主服務器的客觀下線狀態就會被移除。若 Master主服務器重新向 Sentinel（哨兵）進程發送 PING 命令返回有效回覆，Master主服務器的主觀下線狀態就會被移除。
優點：
- 哨兵模式是基於主從模式的，所有主從的優點，哨兵模式都具有。
- 主從可以自動切換，系統更健壯，可用性更高。
缺點:
- Redis較難支持在線擴容，在集羣容量達到上限時在線擴容會變得很複雜。
三、Cluster 集羣
Redis 的哨兵模式基本已經可以實現高可用，讀寫分離 ，但是在這種模式下每臺 Redis 服務器都存儲相同的數據，很浪費內存，所以在redis3.0上加入了 Cluster 集羣模式，實現了 Redis 的分佈式存儲，也就是說每臺 Redis 節點上存儲不同的內容。
集羣的配置
根據官方推薦，集羣部署至少要 3 臺以上的master節點，最好使用 3 主 3 從六個節點的模式。在測試環境中，只能在一臺機器上面開啓6個服務實例來模擬。
1、修改配置文件
將 redis.conf 的配置文件複製6份（文件名最好加上端口後綴），然後開始修改配置文件中的參數
# 開啓redis的集羣模式
cluster-enabled yes
# 配置集羣模式下的配置文件
cluster-config-file nodes-6379.conf
# 集羣內幾點之間支持最長響應時間
cluster-node-timeout 15000
2、修改完畢之後啓動 6 個 Redis 服務
3、快速部署集羣
6個 Redis 服務啓動成功之後，藉助 redis-tri.rb 工具可以快速的部署集羣，如果本機沒有該命令行需要自行安裝，只需要執行/redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 就可以成功創建集羣。
創建集羣可能會出現的錯誤
#這是由於創建集羣中的某一個服務中曾經插入過數據，並且已經產生了持久化文件，此時需要flushall命令清空所有數據 [ERR] Node 127.0.0.1:6380 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0 #這是由於之前創建集羣遺留的配置文件導致的問題，使用命令cluster reset即可 redis-4.1.0/lib/redis/client.rb:124:in `call': ERR Slot 935 is already busy
集羣的部署會在後續的文章中進行詳細的說明和測試，這裏就不詳細說明了
集羣的特點
- 所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬。
- 節點的fail是通過集羣中超過半數的節點檢測失效時才生效。
- 客戶端與Redis節點直連，不需要中間代理層，客戶端不需要連接集羣所有節點，連接集羣中任何一個可用節點即可。
集羣的工作方式
在 Redis 的每一個節點上，都有這麼兩個東西，一個是插槽（slot），它的的取值範圍是：0-16383。還有一個就是cluster，可以理解爲是一個集羣管理的插件。當我們的存取的 Key到達的時候，Redis 會根據 crc16的算法得出一個結果，然後把結果對 16384 求餘數，這樣每個 key 都會對應一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應的插槽所對應的節點，然後直接自動跳轉到這個對應的節點上進行存取操作。
爲了保證高可用，redis-cluster集羣引入了主從模式，一個主節點對應一個或者多個從節點，當主節點宕機的時候，就會啓用從節點。當其它主節點ping一個主節點A時，如果半數以上的主節點與A通信超時，那麼認爲主節點A宕機了。如果主節點A和它的從節點A1都宕機了，那麼該集羣就無法再提供服務了。
分類: 中間件