? ? 通過持久化功能，Redis保證了即使在服務(wù)器重啟的情況下也不會丟失(或少量丟失)數(shù)據(jù)，因為持久化會把內(nèi)存中數(shù)據(jù)保存到硬盤上，重啟會從硬盤上加載數(shù)據(jù)。但是由于數(shù)據(jù)是存儲在一臺服務(wù)器上的，如果這臺服務(wù)器出現(xiàn)硬盤故障等問題，也會導(dǎo)致數(shù)據(jù)都是。

? ? 為了避免單點故障，通常的做法是將數(shù)據(jù)庫復(fù)制多個副本以部署在不同的服務(wù)器上，這樣即使有一臺服務(wù)器出現(xiàn)故障，其他服務(wù)器已讓可以繼續(xù)提供服務(wù)。為此，Redis提供了復(fù)制(replication)功能，可以實現(xiàn)當(dāng)一臺數(shù)據(jù)庫中的數(shù)據(jù)更新后，自動將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫上。

? ? 在復(fù)制的概念中，數(shù)據(jù)庫分為兩類,一類是主數(shù)據(jù)庫(master),另一類是從數(shù)據(jù)庫(slave)。主數(shù)據(jù)庫可以進行讀寫操作，當(dāng)寫操作導(dǎo)致數(shù)據(jù)變化會自動將數(shù)據(jù)同步給從數(shù)據(jù)庫。而從數(shù)據(jù)庫一般是只讀的，并接受主數(shù)據(jù)庫同步過來的數(shù)據(jù)。一個主數(shù)據(jù)庫可以擁有多個從數(shù)據(jù)庫，而一個從數(shù)據(jù)庫只能擁有一個主數(shù)據(jù)庫。

主從數(shù)據(jù)庫的配置：

　　主數(shù)據(jù)庫不用配置，從數(shù)據(jù)庫的配置文件（redis.conf）中可以加載主數(shù)據(jù)庫的信息，也可以在啟動時，使用 redis-server --port 6380 --slaveof 127.0.0.1 6379 命令指明主數(shù)據(jù)庫的 IP 和端口。從數(shù)據(jù)庫一般是只讀，可以改為可寫，但寫入的數(shù)據(jù)很容易被主同步?jīng)]，所以還是只讀就可以。也可以在運行時使用 slaveof ip port 命令，停止原來的主，切換成剛剛設(shè)置的主 slaveof no one會把自己變成主。

主從復(fù)制原理：

• 從數(shù)據(jù)庫連接主數(shù)據(jù)庫，發(fā)送SYNC命令;
• 主數(shù)據(jù)庫接收到SYNC命令后，可以執(zhí)行BGSAVE命令生成RDB文件并使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令;
• 主數(shù)據(jù)庫BGSAVE執(zhí)行完后，向所有從數(shù)據(jù)庫發(fā)送快照文件，并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令;
• 從數(shù)據(jù)庫收到快照文件后丟棄所有舊數(shù)據(jù)，載入收到的快照;
• 主數(shù)據(jù)庫快照發(fā)送完畢后開始向從數(shù)據(jù)庫發(fā)送緩沖區(qū)中的寫命令;
• 從數(shù)據(jù)庫完成對快照的載入，開始接受命令請求，并執(zhí)行來自主數(shù)據(jù)庫緩沖區(qū)的寫命令;(從數(shù)據(jù)庫初始化完成)
• 主數(shù)據(jù)庫每執(zhí)行一個寫命令就會向從數(shù)據(jù)庫發(fā)送相同的寫命令，從數(shù)據(jù)庫接收并執(zhí)行收到的寫命令(從數(shù)據(jù)庫初始化完成后的操作)
• 出現(xiàn)斷開重連后，2.8之后的版本會將斷線期間的命令傳給從數(shù)據(jù)庫，增量復(fù)制。
• 主從剛剛連接的時候，進行全量同步;全同步結(jié)束后，進行增量同步。當(dāng)然，如果有需要，slave在任何時候都可以發(fā)起全量同步。Redis的策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

優(yōu)點:

• 支持主從復(fù)制，主機會自動將數(shù)據(jù)同步到從機，可以進行讀寫分離;
• 為了分載Master的讀操作壓力，Slave服務(wù)器可以為客戶端提供只讀操作的服務(wù)，寫服務(wù)依然必須由Master來完成;
• Slave同樣可以接受其他Slaves的連接和同步請求，這樣可以有效地分載Master的同步壓力;
• Master Server是以非阻塞的方式為Slaves提供服務(wù)。所以在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請求;
• Slave Server同樣是以阻塞的方式完成數(shù)據(jù)同步。在同步期間，如果有客戶端提交查詢請求，Redis則范湖同步之前的數(shù)據(jù)。

?

缺點:

• Redis不具備自動容錯和恢復(fù)功能，主機從機的宕機都會導(dǎo)致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復(fù);
• 主機宕機，宕機前有部分?jǐn)?shù)據(jù)未能及時同步到從機，切換IP后還會引入數(shù)據(jù)不一致的問題，降低了系統(tǒng)的可用性;
• 如果多個Slave斷線了，需要重啟的時候，盡量不要在同一時間段進行重啟。因為只要Slave啟動，就會發(fā)送sync請求和主機全量同步，當(dāng)多個Slave重啟的時候，可能會導(dǎo)致Master IO劇增從而宕機。
• Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復(fù)雜;

二、哨兵模式

　　第一種主從同步/復(fù)制的模式，當(dāng)主服務(wù)器宕機后，需要手動把一臺從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費事費力，還會造成一段時間內(nèi)服務(wù)不可用。這不是一種推薦的方式，更多時候，我們優(yōu)先考慮哨兵模式。

　　哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運行的多個Redis實例。

哨兵模式的作用:

• 通過發(fā)送命令，讓Redis服務(wù)器返回監(jiān)控其運行狀態(tài)，包括主服務(wù)器和從服務(wù)器;
• 當(dāng)哨兵監(jiān)測到master宕機，會自動將slave切換到master，然后通過發(fā)布訂閱模式通過其他的從服務(wù)器，修改配置文件，讓它們切換主機;
• 然而一個哨兵進程對Redis服務(wù)器進行監(jiān)控，也可能會出現(xiàn)問題，為此，我們可以使用多個哨兵進行監(jiān)控。各個哨兵之間還會進行監(jiān)控，這樣就形成了多哨兵模式。
• ?

故障切換的過程：

　　假設(shè)主服務(wù)器宕機，哨兵1先檢測到這個結(jié)果，系統(tǒng)并不會馬上進行 failover 過程，僅僅是哨兵1主觀的認(rèn)為主服務(wù)器不可用，這個現(xiàn)象成為主觀下線。當(dāng)后面的哨兵也檢測到主服務(wù)器不可用，并且數(shù)量達到一定值時，那么哨兵之間就會進行一次投票，投票的結(jié)果由一個哨兵發(fā)起，進行 failover 操作。切換成功后，就會通過發(fā)布訂閱模式，讓各個哨兵把自己監(jiān)控的從服務(wù)器實現(xiàn)切換主機，這個過程稱為客觀下線。這樣對于客戶端而言，一切都是透明的。

哨兵模式的配置：

配置一主二從和三個哨兵的 Redis 服務(wù)器來演示這個過程

主從服務(wù)器配置

# 使用Redis服務(wù)器可以跨網(wǎng)絡(luò)訪問 bind 0.0.0.0# 設(shè)置密碼 requirepass "123456"# 以下有關(guān)slaveof的配置只是配置從服務(wù)器，主服務(wù)器不需要配置 # 指定主服務(wù)器 slaveof 192.168.11.128 6379 # 主服務(wù)器密碼 masterauth 123456

哨兵配置

# 禁止保護模式 protected-mode no # 配置監(jiān)聽的主服務(wù)器，這里sentinel monitor代表監(jiān)控，mymaster代表服務(wù)器的名稱，可以自定義， 192.168.11.128代表監(jiān)控的主服務(wù)器，6379代表端口，2代表只有兩個或兩個以上的哨兵認(rèn)為主服務(wù)器不可用的時候，才會進行failover操作。 sentinel monitor mymaster 192.168.11.128 6379 2 # sentinel author-pass定義服務(wù)的密碼，mymaster是服務(wù)名稱，123456是Redis服務(wù)器密碼 # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster 123456

配置3個哨兵，每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.conf文件，copy一份進行修改

啟動

注意啟動的順序。首先是主機（192.168.11.128）的 Redis 服務(wù)進程，然后啟動從機的 Redis 服務(wù)進程，最后啟動3個哨兵的服務(wù)進程。

哨兵模式的工作方式：

• 每個Sentinel（哨兵）進程以每秒鐘一次的頻率向整個集群中的Master主服務(wù)器，Slave從服務(wù)器以及其他Sentinel（哨兵）進程發(fā)送一個 PING 命令。
• 如果一個實例（instance）距離最后一次有效回復(fù) PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel（哨兵）進程標(biāo)記為主觀下線（SDOWN）
• 如果一個Master主服務(wù)器被標(biāo)記為主觀下線（SDOWN），則正在監(jiān)視這個Master主服務(wù)器的所有 Sentinel（哨兵）進程要以每秒一次的頻率確認(rèn)Master主服務(wù)器的確進入了主觀下線狀態(tài)
• 當(dāng)有足夠數(shù)量的 Sentinel（哨兵）進程（大于等于配置文件指定的值）在指定的時間范圍內(nèi)確認(rèn)Master主服務(wù)器進入了主觀下線狀態(tài)（SDOWN）， 則Master主服務(wù)器會被標(biāo)記為客觀下線（ODOWN）
• 在一般情況下， 每個 Sentinel（哨兵）進程會以每 10 秒一次的頻率向集群中的所有Master主服務(wù)器、Slave從服務(wù)器發(fā)送 INFO 命令。
• 當(dāng)Master主服務(wù)器被 Sentinel（哨兵）進程標(biāo)記為客觀下線（ODOWN）時，Sentinel（哨兵）進程向下線的 Master主服務(wù)器的所有 Slave從服務(wù)器發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次。
• 若沒有足夠數(shù)量的 Sentinel（哨兵）進程同意 Master主服務(wù)器下線， Master主服務(wù)器的客觀下線狀態(tài)就會被移除。若 Master主服務(wù)器重新向 Sentinel（哨兵）進程發(fā)送 PING 命令返回有效回復(fù)，Master主服務(wù)器的主觀下線狀態(tài)就會被移除。

優(yōu)點：

• 哨兵模式是基于主從模式的，所有主從的優(yōu)點，哨兵模式都具有。
• 主從可以自動切換，系統(tǒng)更健壯，可用性更高。

缺點:

• Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復(fù)雜。

三、Cluster 集群

　　Redis 的哨兵模式基本已經(jīng)可以實現(xiàn)高可用，讀寫分離 ，但是在這種模式下每臺 Redis 服務(wù)器都存儲相同的數(shù)據(jù)，很浪費內(nèi)存，所以在redis3.0上加入了 Cluster 集群模式，實現(xiàn)了 Redis 的分布式存儲，也就是說每臺 Redis 節(jié)點上存儲不同的內(nèi)容。

集群的配置

根據(jù)官方推薦，集群部署至少要 3 臺以上的master節(jié)點，最好使用 3 主 3 從六個節(jié)點的模式。在測試環(huán)境中，只能在一臺機器上面開啟6個服務(wù)實例來模擬。

1、修改配置文件

將 redis.conf 的配置文件復(fù)制6份（文件名最好加上端口后綴），然后開始修改配置文件中的參數(shù)

# 開啟redis的集群模式 cluster-enabled yes# 配置集群模式下的配置文件 cluster-config-file nodes-6379.conf# 集群內(nèi)幾點之間支持最長響應(yīng)時間 cluster-node-timeout 15000

2、修改完畢之后啟動 6 個 Redis 服務(wù)

3、快速部署集群

6個 Redis 服務(wù)啟動成功之后，借助 redis-tri.rb 工具可以快速的部署集群，如果本機沒有該命令行需要自行安裝，只需要執(zhí)行/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 就可以成功創(chuàng)建集群。

創(chuàng)建集群可能會出現(xiàn)的錯誤

#這是由于創(chuàng)建集群中的某一個服務(wù)中曾經(jīng)插入過數(shù)據(jù)，并且已經(jīng)產(chǎn)生了持久化文件，此時需要flushall命令清空所有數(shù)據(jù) [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#這是由于之前創(chuàng)建集群遺留的配置文件導(dǎo)致的問題，使用命令cluster reset即可 redis-4.1.0/lib/redis/client.rb:124:in `call': ERR Slot 935 is already busy

集群的部署會在后續(xù)的文章中進行詳細的說明和測試，這里就不詳細說明了

集群的特點

• 所有的redis節(jié)點彼此互聯(lián)(PING-PONG機制),內(nèi)部使用二進制協(xié)議優(yōu)化傳輸速度和帶寬。
• 節(jié)點的fail是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效。
• 客戶端與Redis節(jié)點直連，不需要中間代理層，客戶端不需要連接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。

集群的工作方式

　　在 Redis 的每一個節(jié)點上，都有這么兩個東西，一個是插槽（slot），它的的取值范圍是：0-16383。還有一個就是cluster，可以理解為是一個集群管理的插件。當(dāng)我們的存取的 Key到達的時候，Redis 會根據(jù) crc16的算法得出一個結(jié)果，然后把結(jié)果對 16384 求余數(shù)，這樣每個 key 都會對應(yīng)一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應(yīng)的插槽所對應(yīng)的節(jié)點，然后直接自動跳轉(zhuǎn)到這個對應(yīng)的節(jié)點上進行存取操作。

　　為了保證高可用，redis-cluster集群引入了主從模式，一個主節(jié)點對應(yīng)一個或者多個從節(jié)點，當(dāng)主節(jié)點宕機的時候，就會啟用從節(jié)點。當(dāng)其它主節(jié)點ping一個主節(jié)點A時，如果半數(shù)以上的主節(jié)點與A通信超時，那么認(rèn)為主節(jié)點A宕機了。如果主節(jié)點A和它的從節(jié)點A1都宕機了，那么該集群就無法再提供服務(wù)了。

分類:?中間件

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的redis集群的三种模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。