Redis ==> 集羣的三種模式

1、主從同步/複製

　　經過持久化功能，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較難支持在線擴容，在集羣容量達到上限時在線擴容會變得很複雜；

2、哨兵模式

　　第一種主從同步/複製的模式，當主服務器宕機後，須要手動把一臺從服務器切換爲主服務器，這就須要人工干預，費事費力，還會形成一段時間內服務不可用。這不是一種推薦的方式，更多時候，咱們優先考慮哨兵模式。

　　哨兵模式是一種特殊的模式，首先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較難支持在線擴容，在集羣容量達到上限時在線擴容會變得很複雜。

3、Cluster 集羣

　　Redis 的哨兵模式基本已經能夠實現高可用，讀寫分離 ，可是在這種模式下每臺 Redis 服務器都存儲相同的數據，很浪費內存，因此在redis3.0上加入了 Cluster 集羣模式，實現了 Redis 的分佈式存儲，也就是說每臺 Redis 節點上存儲不一樣的內容。

集羣的配置

根據官方推薦，集羣部署至少要 3 臺以上的master節點，最好使用 3 主 3 從六個節點的模式。在測試環境中，只能在一臺機器上面開啓6個服務實例來模擬。

一、修改配置文件

將 redis.conf 的配置文件複製6份（文件名最好加上端口後綴），而後開始修改配置文件中的參數

#開啓redis的集羣模式
cluster-enabled yes

#配置集羣模式下的配置文件
cluster-config-file nodes-6379.conf

#集羣內節點之間支持最長響應時間
cluster-node-timeout 15000

二、修改完畢以後啓動 6 個 Redis 服務

三、快速部署集羣

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都宕機了，那麼該集羣就沒法再提供服務了。