記錄一下，轉載於：https://www.cnblogs.com/L-Test/p/11626124.html
一、主從同步/復制
通過持久化功能，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都宕機了，那么該集群就無法再提供服務了。