目錄
一、Redis高可用
二、redis持久化
2.1 持久化的功能
2.2 Redis 提供兩種方式進行持久化
2.3?RDB 持久化
2.3.1 觸發(fā)條件
?2.3.2 執(zhí)行流程
2.3.3?啟動時加載
2.4?AOF持久化
2.5?執(zhí)行流程
2.5.1?命令追加(append)
?2.5.2 文件寫入(write)和文件同步(sync)
2.5.3?文件重寫(rewrite)
2.5.3.1?文件重寫的觸發(fā)，分為手動觸發(fā)和自動觸發(fā)
2.5.3.2?文件重寫的流程如下
2.5.3.3?啟動時加載
2.6?RDB和AOF的優(yōu)缺點
2.6.1 RDB持久化
2.6.2 AOF持久化
2.7?Redis 性能管理
2.7.1 查看Redis內(nèi)存使用
2.7.2內(nèi)存碎片率
2.7.3 內(nèi)存使用率?
2.7.4 內(nèi)回收key?
三、redis主從復(fù)制
3.1 Redis主從復(fù)制的概念
3.2 Redis主從復(fù)制的作用
3.3 Redis主從復(fù)制的流程
3.4?Redis主從復(fù)制的搭建
3.4.1 環(huán)境配置/安裝包
3.4.2 安裝Redis（所有主機)?
3.4.3 修改Master節(jié)點Redis配置文件【192.168.19.3】
3.4.4 修改Slave節(jié)點Redis配置文件[192.168.19.6和7]
3.4.5 驗證主從效果
一、Redis高可用
在web服務(wù)器中
- 高可用是指服務(wù)器可以正常訪問的時間
- 衡量的標準是在多長時間內(nèi)可以提供正常服務(wù)（99.9%、99.99%、99.999%等等）。
但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)（如主從分離、快速容災(zāi)技術(shù)），還需要考慮數(shù)據(jù)容量的擴展、數(shù)據(jù)安全不會丟失等。
在Redis中，實現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和 Cluster集群，下面分別說明它們的作用，以及解決了什么樣的問題。
- 持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲在硬盤，保證數(shù)據(jù)不會因進程退出而丟失。
- 主從復(fù)制：主從復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在主從復(fù)制基礎(chǔ)上實現(xiàn)高可用的。主從復(fù)制主要實現(xiàn)了數(shù)據(jù)的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復(fù)。缺陷：故障恢復(fù)無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
- 哨兵：在主從復(fù)制的基礎(chǔ)上，哨兵實現(xiàn)了自動化的故障恢復(fù)。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
- Cluster集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現(xiàn)了較為完善的高可用方案。
二、redis持久化
2.1 持久化的功能
redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中，為了避免服務(wù)器服務(wù)器斷電等導(dǎo)致redis進程異常退出后數(shù)據(jù)的永久丟失，需要定期將redis中的數(shù)據(jù)以某種形式（數(shù)據(jù)或命令）從內(nèi)存保存到硬盤；
當下次redis重啟時，利用持久化文件實現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進行災(zāi)難備份，可以將持久化文件拷貝到一個遠程位置。
2.2 Redis 提供兩種方式進行持久化
- RDB 持久化：原理是將 Reids在內(nèi)存中的數(shù)據(jù)庫記錄定時保存到磁盤上。
- AOF 持久化（append only file）：原理是將 Reids 的操作日志以追加的方式寫入文件，類似于MySQL的binlog。
由于AOF持久化的實時性更好，即當進程意外退出時丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。
2.3?RDB 持久化
RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中當前進程中的數(shù)據(jù)生成快照保存到硬盤(因此也稱作快照持久化)，用二進制壓縮存儲，保存的文件后綴是rdb；當Redis重新啟動時，可以讀取快照文件恢復(fù)數(shù)據(jù)。2.3.1 觸發(fā)條件
RDB持久化的觸發(fā)分為手動觸發(fā)和自動觸發(fā)兩種。
- 手動觸發(fā)
save命令和bgsave命令都可以生成RDB文件。
save命令會阻塞Redis服務(wù)器進程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請求。
而bgsave命令會創(chuàng)建一個子進程，由子進程來負責創(chuàng)建RDB文件，父進程(即Redis主進程)則繼續(xù)處理請求。
bgsave命令執(zhí)行過程中，只有fork子進程時會阻塞服務(wù)器，而對于save命令，整個過程都會阻塞服務(wù)器，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用。
- 自動觸發(fā)
在自動觸發(fā)RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化。
save m n
自動觸發(fā)最常見的情況是在配置文件中通過save m n，指定當m秒內(nèi)發(fā)生n次變化時，會觸發(fā)bgsave。
vim /etc/redis/6379.conf
--219行--以下三個save條件滿足任意一個時，都會引起bgsave的調(diào)用
save 900 1 ：當時間到900秒時，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave
save 300 10 ：當時間到300秒時，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsave
save 60 10000 ：當時間到60秒時，如果redis數(shù)據(jù)發(fā)生了至少10000次變化，則執(zhí)行bgsave
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目錄
dir /var/lib/redis/6379
--242行--是否開啟RDB文件壓縮
rdbcompression yes
##其他自動觸發(fā)機制##
除了save m n 以外，還有一些其他情況會觸發(fā)bgsave：
●在主從復(fù)制場景下，如果從節(jié)點執(zhí)行全量復(fù)制操作，則主節(jié)點會執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點。
●執(zhí)行shutdown命令時，自動執(zhí)行rdb持久化。?2.3.2 執(zhí)行流程
- Redis父進程首先判斷：當前是否在執(zhí)行save，或bgsave/bgrewriteaof的子進程，如果在執(zhí)行則bgsave命令直接返回。bgsave/bgrewriteaof的子進程不能同時執(zhí)行，主要是基于性能方面的考慮： 兩個并發(fā)的子進程同時執(zhí)行大量的磁盤寫操作，可能引起嚴重的性能問題。
- 父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令
- 父進程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父進程，并可以響應(yīng)其他命令
- 子進程創(chuàng)建RDB文件，根據(jù)父進程內(nèi)存快照生成臨時快照文件，完成后對原有文件進行原子替換
- 子進程發(fā)送信號給父進程表示完成，父進程更新統(tǒng)計信息
2.3.3?啟動時加載
- RDB文件的載入工作是在服務(wù)器啟動時自動執(zhí)行的，并沒有專門的命令。但是由于AOF的優(yōu)先級更高，因此當AOF開啟時，Redis會優(yōu)先載入 AOF文件來恢復(fù)數(shù)據(jù)；只有當AOF關(guān)閉時， 才會在Redis服務(wù)器啟動時檢測RDB文件，并自動載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。
- Redis載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。?
2.4?AOF持久化
RDB持久化?是將進程數(shù)據(jù)寫入文件，而AOF持久化，則是將Redis執(zhí)行的每次寫、刪除命令記錄到單獨的日志文件中，查詢操作不會記錄；
當Redis重啟時?再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。
開啟AOF
Redis服務(wù)器默認開啟RDB，關(guān)閉AOF；要開啟AOF，需要在配置文件中配置：
vim /etc/redis/6379.conf
--700行--修改，開啟AOF
appendonly yes
--704行--指定AOF文件名稱
appendfilename "appendonly.aof"
--796行--是否忽略最后一條可能存在問題的指令
aof-load-truncated yes
/etc/init.d/redis_6379 restart2.5?執(zhí)行流程
由于需要記錄Redis的每條寫命令，因此AOF不需要觸發(fā)，下面介紹AOF的執(zhí)行流程。
AOF的執(zhí)行流程
- 命令追加(append)：將Redis的寫命令追加到緩沖區(qū)aof_buf；
- 文件寫入(write)和文件同步(sync)：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤；
- 文件重寫(rewrite)：定期重寫AOF文件，達到壓縮的目的。
2.5.1?命令追加(append)
- Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導(dǎo)致硬盤IO成為Redis負載的瓶頸。
- 命令追加的格式是: Redis命令請求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優(yōu)點。在AOF文件中，除了用于指定數(shù)據(jù)庫的select命令（如select 0為選中0號數(shù)據(jù)庫）是由Redis添加的，其他都是客戶端發(fā)送來的寫命令。?
?2.5.2 文件寫入(write)和文件同步(sync)
Redis提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)，說明如下：
為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時，操作系統(tǒng)通常會將數(shù)據(jù)暫存到一個內(nèi)存緩沖區(qū)里，當緩沖區(qū)被填滿或超過了指定時限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會丟失；因此系統(tǒng)同時提供了fsync、fdatasync等同步函數(shù)，可以強制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保數(shù)據(jù)的安全性。AOF緩存區(qū)的同步文件策略存在三種同步方式，它們分別是：
vim /etc/redis/6379.conf
–729–
● appendfsync always[一直觸發(fā)]： 命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固態(tài)硬盤（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
● appendfsync no【不觸發(fā)】： 命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步；同步由操作系統(tǒng)負責，通常同步周期為30秒。這種情況下，文件同步的時間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會很多，數(shù)據(jù)安全性無法保證。
● appendfsync everysec【每秒觸發(fā)】： 命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回；fsync同步文件操作由專門的線程每秒調(diào)用一次。everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認配置，也是我們推薦的配置。2.5.3?文件重寫(rewrite)
- 隨著時間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務(wù)器的正常運行，也會導(dǎo)致數(shù)據(jù)恢復(fù)需要的時間過長。
- 文件重寫是指定期重寫AOF文件，減小AOF文件的體積。
AOF重寫是把Redis進程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令，同步到新的AOF文件；不會對舊的AOF文件進行任何讀取、寫入操作!關(guān)于文件重寫需要注意的另一點是： 對于AOF持久化來說，文件重寫雖然是強烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動的時候?qū)?；因此在一些現(xiàn)實中，會關(guān)閉自動的文件重寫，然后通過定時任務(wù)在每天的某一時刻定時執(zhí)行。
文件重寫之所以能夠壓縮AOF文件，原因
- 過期的數(shù)據(jù)不再寫入文件
- 無效的命令不再寫入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值(set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(set myset v1, del myset)等。
- 多條命令可以合并為一個：如sadd myset v1, sadd myset v2,?sadd myset v3可以合并為sadd myset v1 v2 v3。
通過上述內(nèi)容可以看出，由于重寫后AOF執(zhí)行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復(fù)速度。?
2.5.3.1?文件重寫的觸發(fā)，分為手動觸發(fā)和自動觸發(fā)
- 手動觸發(fā)： 直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進程進行具體的工作，且都只有在fork時阻塞。
- 自動觸發(fā)： 通過設(shè)置auto-aof-rewrite-min-size選項和auto-aof-rewrite-percentage選項來自動執(zhí)行BGREWRITEAOF。 只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項同時滿足時，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作。
vim /etc/redis/6379.conf
–729–
●auto-aof-rewrite-percentage 100 ： 當前AOF文件大小(即aof_current_size)是上次日志重寫時AOF文件大小(aof_base_size)兩倍時，發(fā)生BGREWRITEAOF操作
●auto-aof-rewrite-min-size 64mb ： 當前AOF文件執(zhí)行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由于文件尺寸較小導(dǎo)致頻繁的BGREWRITEAOF
關(guān)于文件重寫的流程，有兩點需要特別注意：
(1)重寫由父進程fork子進程進行；
(2)重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存。2.5.3.2?文件重寫的流程如下
（1）Redis父進程首先判斷當前是否存在正在執(zhí)行bgsave/bgrewriteaof的子進程，
如果存在則bgrewriteaof命令直接返回，如果存在 bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行。
（2）父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的。
（3.1）父進程fork后，bgrewriteaof命令返回”Background append only file rewrite started”
信息并不再阻塞父進程， 并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，
并根據(jù)appendfsync策略同步到硬盤，保證原有AOF機制的正確。
（3.2）由于fork操作使用寫時復(fù)制技術(shù)，子進程只能共享fork操作時的內(nèi)存數(shù)據(jù)。
由于父進程依然在響應(yīng)命令，因此Redis使用AOF重寫緩沖區(qū)(aof_rewrite_buf)保存這部分數(shù)據(jù)，
防止新AOF文件生成期間丟失這部分數(shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，
Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區(qū)。
（4）子進程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件。
（5.1）子進程寫完新的AOF文件后，向父進程發(fā)信號，父進程更新統(tǒng)計信息，
具體可以通過info persistence查看。
（5.2）父進程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，
這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當前狀態(tài)一致。
（5.3）使用新的AOF文件替換老文件，完成AOF重寫。
2.5.3.3?啟動時加載
- 當AOF開啟時，Redis啟動時會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù)；只有當AOF關(guān)閉時，才會載入RDB文件恢復(fù)數(shù)據(jù)。
- 當AOF開啟，但AOF文件不存在時，即使RDB文件存在也不會加載。
- Redis載入AOF文件時，會對AOF文件進行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結(jié)尾不完整(機器突然宕機等容易導(dǎo)致文件尾部不完整)，且aof-load-truncated參數(shù)開啟，則日志中會輸出警告，Redis忽略掉AOF文件的尾部，啟動成功。aof-load-truncated參數(shù)默認是開啟的。
2.6?RDB和AOF的優(yōu)缺點
2.6.1 RDB持久化
優(yōu)點
- RDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制；
- 恢復(fù)速度比AOF快很多。
- 當然，與AOF相比，RDB最重要的優(yōu)點之一是對性能的影響相對較小。
缺點
- RDB文件的致命缺點在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實時持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。
- 此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
- 對于RDB持久化，一方面是bgsave在進行fork操作時Redis主進程會阻塞，另一方面，子進程向硬盤寫數(shù)據(jù)也會帶來IO壓力。
2.6.2 AOF持久化
優(yōu)點在于支持秒級持久化、兼容性好，缺點是文件大、恢復(fù)速度慢、對性能影響大。對于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題。
AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進程的IO壓力問題。
相對來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對 Redis主進程性能的影響會更大。
2.7?Redis 性能管理
2.7.1 查看Redis內(nèi)存使用
info memory2.7.2內(nèi)存碎片率
操作系統(tǒng)分配的內(nèi)存值 used_memory_rss 除以 Redis 使用的內(nèi)存總量值 used_memory 計算得出。 內(nèi)存值used_memory_rss 表示該進程所占物理內(nèi)存的大小，即為操作系統(tǒng)分配給 Redis 實例的內(nèi)存大小。除了用戶定義的數(shù)據(jù)和內(nèi)部開銷以外，used_memory_rss 指標還包含了內(nèi)存碎片的開銷，內(nèi)存碎片 是由操作系統(tǒng)低效的分配/回收物理內(nèi)存導(dǎo)致的（不連續(xù)的物理內(nèi)存分配）。
舉例來說： Redis 需要分配連續(xù)內(nèi)存塊來存儲 1G 的數(shù)據(jù)集。如果物理內(nèi)存上沒有超過 1G 的連續(xù)內(nèi)存塊， 那操作系統(tǒng)就不得不使用多個不連續(xù)的小內(nèi)存塊來分配并存儲這 1G 數(shù)據(jù)，該操作就會導(dǎo)致內(nèi)存碎片的產(chǎn)生。
跟蹤內(nèi)存碎片率對理解Redis實例的資源性能是非常重要的：
●內(nèi)存碎片率稍大于1是合理的，這個值表示內(nèi)存碎片率比較低，也說明 Redis 沒有發(fā)生內(nèi)存交換。
●內(nèi)存碎片率超過1.5，說明Redis消耗了實際需要物理內(nèi)存的150%，其中50%是內(nèi)存碎片率。
需要在redis-cli工具上輸入shutdown save 命令，讓 Redis 數(shù)據(jù)庫執(zhí)行保存操作并關(guān)閉 Redis 服務(wù)，
再重啟服務(wù)器。
●內(nèi)存碎片率低于1的，說明Redis內(nèi)存分配超出了物理內(nèi)存，操作系統(tǒng)正在進行內(nèi)存交換。
需要增加可用物理內(nèi)存或減少 Redis 內(nèi)存占用。2.7.3 內(nèi)存使用率?
redis實例的內(nèi)存使用率超過可用最大內(nèi)存，操作系統(tǒng)將開始進行內(nèi)存與swap空間交換。避免內(nèi)存交換發(fā)生的方法
●針對緩存數(shù)據(jù)大小選擇安裝 Redis 實例
●盡可能的使用Hash數(shù)據(jù)結(jié)構(gòu)存儲
●設(shè)置key的過期時間2.7.4 內(nèi)回收key?
內(nèi)存清理策略，保證合理分配redis有限的內(nèi)存資源。當達到設(shè)置的最大閥值時，需選擇一種key的回收策略，默認情況下回收策略是禁止刪除。
配置文件中修改 maxmemory-policy 屬性值：
vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
●volatile-lru：使用LRU算法從已設(shè)置過期時間的數(shù)據(jù)集合中淘汰數(shù)據(jù)(移除最近最少使用的key，
針對設(shè)置了TTL的key)
●volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰（移除最近過期的key）
●volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集合中隨機挑選數(shù)據(jù)淘汰（在設(shè)置了TTL的key里隨機移除）
●allkeys-lru：使用LRU算法從所有數(shù)據(jù)集合中淘汰數(shù)據(jù)（移除最少使用的key，針對所有的key）
●allkeys-random：從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰（隨機移除key）
●noenviction：禁止淘汰數(shù)據(jù)（不刪除直到寫滿時報錯）三、redis主從復(fù)制
3.1 Redis主從復(fù)制的概念
- **主從復(fù)制，是指：**將一臺Redis服務(wù)器的數(shù)據(jù)，復(fù)制到其他的Redis服務(wù)器。前者稱為主節(jié)點(Master)，后者稱為從節(jié)點(Slave)；數(shù)據(jù)的復(fù)制是單向的，只能由主節(jié)點到從節(jié)點。
- 默認情況下，每臺Redis服務(wù)器都是主節(jié)點；且一個主節(jié)點可以有多個從節(jié)點(或沒有從節(jié)點)，但一個從節(jié)點只能有一個主節(jié)點。
3.2 Redis主從復(fù)制的作用
- 數(shù)據(jù)冗余： 主從復(fù)制實現(xiàn)了數(shù)據(jù)的熱備份，是持久化之外的一種數(shù)據(jù)冗余方式。
- 故障恢復(fù)： 當主節(jié)點出現(xiàn)問題時，可以由從節(jié)點提供服務(wù)，實現(xiàn)快速的故障恢復(fù)；實際上是一種服務(wù)的冗余。
- 負載均衡： 在主從復(fù)制的基礎(chǔ)上，配合讀寫分離，可以由主節(jié)點提供寫服務(wù)，由從節(jié)點提供讀服務(wù)（即寫Redis數(shù)據(jù)時應(yīng)用連接主節(jié)點，讀Redis數(shù)據(jù)時應(yīng)用連接從節(jié)點），分擔服務(wù)器負載；尤其是在寫少讀多的場景下，通過多個從節(jié)點分擔讀負載，可以大大提高Redis服務(wù)器的并發(fā)量。
- 高可用基石： 除了上述作用以外，主從復(fù)制還是哨兵和集群能夠?qū)嵤┑幕A(chǔ)，因此說主從復(fù)制是Redis高可用的基礎(chǔ)。
3.3 Redis主從復(fù)制的流程
若啟動一個Slave機器進程，則它會向Master機器發(fā)送一個“sync command”命令，請求同步連接。
無論是第一次連接還是重新連接，Master機器都會啟動一個后臺進程，將數(shù)據(jù)快照保存到數(shù)據(jù)文件中（執(zhí)行rdb操作），同時Master還會記錄修改數(shù)據(jù)的所有命令并緩存在數(shù)據(jù)文件中。
后臺進程完成緩存操作之后，Maste機器就會向Slave機器發(fā)送數(shù)據(jù)文件，Slave端機器將數(shù)據(jù)文件保存到硬盤上，然后將其加載到內(nèi)存中，接著Master機器就會將修改數(shù)據(jù)的所有操作一并發(fā)送給Slave端機器。若Slave出現(xiàn)故障導(dǎo)致宕機，則恢復(fù)正常后會自動重新連接。
Master機器收到Slave端機器的連接后，將其完整的數(shù)據(jù)文件發(fā)送給Slave端機器，如果Mater同時收到多個Slave發(fā)來的同步請求，則Master會在后臺啟動一個進程以保存數(shù)據(jù)文件，然后將其發(fā)送給所有的Slave端機器，確保所有的Slave端機器都正常。
主從復(fù)制、SYNC同步：
- 從Redis服務(wù)器啟動，向主服務(wù)器發(fā)送SYNC同步數(shù)據(jù)請求
- 主redis會fork一個子進程，然后產(chǎn)生出一個RDB文件（完全備份的過程）客戶端還在持續(xù)寫入redis
- RDB文件持久化完后，主Redis會將RDB文件和緩存起來的命令推送給服務(wù)器
- 復(fù)制、推送完成后，主Redis會持續(xù)同步操作命令，利用AOF增備的部分做持久化功能
- 在下一臺從Redis接入主從復(fù)制的集群之前，會持續(xù)利用AOF的方式同步數(shù)據(jù)給從Redis?
3.4?Redis主從復(fù)制的搭建
3.4.1 環(huán)境配置/安裝包
安裝包鏈接：redis-5.0.7.tar.gz?
| 主機 | 操作系統(tǒng) | IP地址 | 軟件 / 安裝包 / 工具 |
|---|---|---|---|
| Master | CentOS7 | 192.168.19.3 | redis-5.0.7.tar.gz |
| Slave1 | CentOS7 | 192.168.19.6 | redis-5.0.7.tar.gz |
| Slave2 | CentOS7 | 192.168.19.7 | redis-5.0.7.tar.gz |
3.4.2 安裝Redis（所有主機)?
systemctl stop firewalld
setenforce 0
yum install -y gcc gcc-c++ make
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils
./install_server.sh
回車四次，下一步需要手動輸入
Please select the redis executable path [] /usr/local/redis/bin/redis-server
ln -s /usr/local/redis/bin/* /usr/local/bin/3.4.3 修改Master節(jié)點Redis配置文件【192.168.19.3】
vim /etc/redis/6379.conf
bind 0.0.0.0?? ??? ??? ??? ??? ??? ?#70行，修改bind 項，0.0.0.0監(jiān)聽所有網(wǎng)段
daemonize yes?? ??? ??? ??? ??? ??? ?#137行，開啟守護進程
logfile /var/log/redis_6379.log?? ??? ?#172行，指定日志文件目錄
dir /var/lib/redis/6379?? ??? ??? ??? ?#264行，指定工作目錄
appendonly yes?? ??? ??? ??? ??? ??? ?#700行，開啟AOF持久化功能
/etc/init.d/redis_6379 restart?
3.4.4 修改Slave節(jié)點Redis配置文件[192.168.19.6和7]
vim /etc/redis/6379.conf
bind 0.0.0.0?? ??? ??? ??? ??? ??? ?#70行，修改bind 項，0.0.0.0監(jiān)聽所有網(wǎng)卡
daemonize yes?? ??? ??? ??? ??? ??? ?#137行，開啟守護進程
logfile /var/log/redis_6379.log?? ??? ?#172行，指定日志文件目錄
dir /var/lib/redis/6379?? ??? ??? ??? ?#264行，指定工作目錄
replicaof 192.168.10.27 6379?? ??? ?#288行，指定要同步的Master節(jié)點IP和端口
appendonly yes?? ??? ??? ??? ??? ??? ?#700行，開啟AOF持久化功能
/etc/init.d/redis_6379 restart
??
?
3.4.5 驗證主從效果
在Master節(jié)點上看日志
tail -f /var/log/redis_6379.log ?在Master節(jié)點上驗證從節(jié)點
redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.19.6,port=6379,state=online,offset=518,lag=1
slave1:ip=192.168.19.7,port=6379,state=online,offset=518,lag=1
?
四、redis哨兵模式
- 主從切換技術(shù)的方法是： 當服務(wù)器宕機后，需要手動一臺從機換為主機，這需要人工干預(yù)，不僅費時費力而且還會造成一段時間內(nèi)服務(wù)器不可用。為了解決主從復(fù)制的缺點，就有了哨兵機制。
- 哨兵的核心功能： 在主從復(fù)制的基礎(chǔ)上，哨兵引入了主節(jié)點的自動故障轉(zhuǎn)移
4.1 哨兵 模式原理
哨兵（sentinel）： 是一個分布式系統(tǒng)，用于 對主從結(jié)構(gòu)中的每臺服務(wù)器進行監(jiān)控，當出現(xiàn) 故障時，通過投票機制選擇新的master并將所有slave連接到新的master。所以整個運行哨兵的集群的數(shù)量不得少于三個節(jié)點。（哨兵必須是奇數(shù)）
4.2 哨兵模式的作用
- 監(jiān)控： 哨兵會不斷地檢測主節(jié)點和從節(jié)點是否運行正常。
- 自動故障轉(zhuǎn)移： 當主節(jié)點不能正常工作時，哨兵會開始自動故障轉(zhuǎn)移操作，她會將失效主節(jié)點的其中一個從節(jié)點升級為新的主節(jié)點，并讓其他從節(jié)點改為新的主節(jié)點。
- 通知（提醒）： 哨兵可以將故障轉(zhuǎn)移的結(jié)果發(fā)送給客戶端。
哨兵結(jié)構(gòu)由兩部分組成： 哨兵節(jié)點和數(shù)據(jù)節(jié)點
- 哨兵節(jié)點：哨兵系統(tǒng)由一個或者多個哨兵節(jié)點組成，哨兵節(jié)點是特殊的redis節(jié)點，不存儲數(shù)據(jù)。
- 數(shù)據(jù)節(jié)點：主節(jié)點和從節(jié)點都是數(shù)據(jù)節(jié)點。
4.3 故障轉(zhuǎn)移機制
由哨兵節(jié)點定期監(jiān)控發(fā)現(xiàn)主節(jié)點是否出現(xiàn)了故障
- 每個哨兵節(jié)點每隔1秒會向主節(jié)點、從節(jié)點以及它哨兵節(jié)點發(fā)送一次ping命令做一次心跳檢測。
如果主節(jié)點在一定時間范圍內(nèi)不回復(fù)或者是回復(fù)一個錯誤消息，那么這個哨兵就會認為這個主節(jié)點主觀下線了（單方面的）。 當超過一半哨兵節(jié)點認為該主節(jié)點主觀下線了，這樣就是客觀下線了。 - 當主節(jié)點出現(xiàn)故障時， 此時哨兵節(jié)點會通過raft算法（選舉算法）實現(xiàn)選舉機制共同選舉出一個哨兵節(jié)點為leader，來負責處理主節(jié)點的故障轉(zhuǎn)移和通知，所以整個運行哨兵的集群的數(shù)量不得少于3個節(jié)點。
- 由leader哨兵節(jié)點執(zhí)行故障轉(zhuǎn)移
- 將某一個從節(jié)點升級為新的主節(jié)點，讓其他從節(jié)點指向新的主節(jié)點；
- 若原主節(jié)點恢復(fù)也變成從節(jié)點，并指向新的主節(jié)點
- 通知客戶端主節(jié)點已經(jīng)更換。
需要特別注意的是，客觀下線是主節(jié)點才有的概念；如果從節(jié)點和哨兵節(jié)點發(fā)生故障時，被哨兵主觀線下后，不會再有后續(xù)的客觀下線和故障轉(zhuǎn)移操作。
故障轉(zhuǎn)移： 就相當于一個黑幫社會，里面會有幾個分社老大，然后有一個最大的老大，定期去最大的老大那里開會，如果最大的老大犯了錯被開了，由其余的分老大代替了，那么即使后期這個原本的最大的老大想恢復(fù)原身份，不能夠直接恢復(fù)，也是需要選舉的。
主節(jié)點的選舉：
1.過濾掉不健康的（已經(jīng)下線的），沒有回復(fù)哨兵ping響應(yīng)的從節(jié)點。
2.選擇配置文件中從節(jié)點優(yōu)先級配置最高的。（replica-priority，默認值為100）
3.選擇復(fù)制偏移量最大，也就是復(fù)制最完美的從節(jié)點。哨兵的啟動依賴于主從模式，所以必須把主從模式安裝好的情況下再去做哨兵模式。
4.4 哨兵模式的搭建
4.4.1 環(huán)境配置
基于主從復(fù)制已搭建完成| 主機 | 操作系統(tǒng) | IP地址 | 軟件 / 安裝包 / 工具 |
|---|---|---|---|
| Master | CentOS7 | 192.168.19.3 | redis-5.0.7.tar.gz |
| Slave1 | CentOS7 | 192.168.19.6 | redis-5.0.7.tar.gz |
| Slave2 | CentOS7 | 192.168.19.7 | redis-5.0.7.tar.gz |
4.4.2 修改 Redis 配置文件（所有節(jié)點操作）?
systemctl stop firewalld
setenforce 0
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no #17行，關(guān)閉保護模式
port 26379 #21行，Redis哨兵默認的監(jiān)聽端口
daemonize yes #26行，指定sentinel為后臺啟動
logfile "/var/log/sentinel.log" #36行，指定日志存放路徑
dir "/var/lib/redis/6379" #65行，指定數(shù)據(jù)庫存放路徑
sentinel monitor mymaster 192.168.19.3 6379 2 #84行，修改 指定該哨兵節(jié)點監(jiān)控192.168.19.3:6379這個主節(jié)點，該主節(jié)點的名稱是mymaster，最后的2的含義與主節(jié)點的故障判定有關(guān)：至少需要2個哨兵節(jié)點同意，才能判定主節(jié)點故障并進行故障轉(zhuǎn)移
sentinel down-after-milliseconds mymaster 30000 #113行，判定服務(wù)器down掉的時間周期，默認30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 #146行，故障節(jié)點的最大超時時間為180000（180秒）?
?
?4.4.3?啟動哨兵模式
先啟master，再啟slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
注意！先啟動主服務(wù)器，再啟動從服務(wù)器
?
?
4.4.4 故障模擬
查看redis-server進程號??
?
殺死 Master 節(jié)點上redis-server的進程號
kill -9 1162 #Master節(jié)點上redis-server的進程號
4.4.5 驗證結(jié)果
tail -f /var/log/sentinel.log?
redis-cli -p 26379 INFO Sentinel?
五、Redis 群集模式
集群，即Redis Cluster，是Redis 3.0開始引入的分布式存儲方案。
- 集群由多個節(jié)點(Node)組成，Redis的數(shù)據(jù)分布在這些節(jié)點中。
- 集群中的節(jié)點分為主節(jié)點和從節(jié)點： 只有主節(jié)點負責讀寫請求和集群信息的維護；從節(jié)點只進行主節(jié)點數(shù)據(jù)和狀態(tài)信息的復(fù)制。
5.1 集群的作用
- 數(shù)據(jù)分區(qū)： 數(shù)據(jù)分區(qū)(或稱數(shù)據(jù)分片)是集群最核心的功能。
集群將數(shù)據(jù)分散到多個節(jié)點，一方面突破了Redis單機內(nèi)存大小的限制，存儲容量大大增加；另一方面每個主節(jié)點都可以對外提供讀服務(wù)和寫服務(wù)，大大提高了集群的響應(yīng)能力。
Redis單機內(nèi)存大小受限問題，在介紹持久化和主從復(fù)制時都有提及；例如，如果單機內(nèi)存太大，bgsave和bgrewriteaof的fork操作可能導(dǎo)致主進程阻塞，主從環(huán)境下主機切換時可能導(dǎo)致從節(jié)點長時間無法提供服務(wù)，全量復(fù)制階段主節(jié)點的復(fù)制緩沖區(qū)可能溢出。
- 高可用： 集群支持主從復(fù)制和主節(jié)點的自動故障轉(zhuǎn)移（與哨兵類似）；當任一節(jié)點發(fā)生故障時，集群仍然可以對外提供服務(wù)。
5.2 Redis集群的數(shù)據(jù)分片
- Redis集群引入了哈希槽的概念
- Redis集群有16384個哈希槽（編號0-16383）
- 集群的每個節(jié)點負責一部分哈希槽
- 每個Key通過CRC16校驗后對16384取余來決定放置哪個哈希槽，通過這個值，去找到對應(yīng)的插槽所對應(yīng)的節(jié)點，然后直接自動跳轉(zhuǎn)到這個對應(yīng)的節(jié)點上進行存取操作
以3個節(jié)點組成的集群為例：
節(jié)點A包含0到5460號哈希槽
節(jié)點B包含5461到10922號哈希槽
節(jié)點C包含10923到16383號哈希槽
edis集群的主從復(fù)制模型
集群中具有A、B、C三個節(jié)點，如果節(jié)點B失敗了，整個集群就會因缺少5461-10922這個范圍的槽而不可以用。
為每個節(jié)點添加一個從節(jié)點A1、B1、C1整個集群便有三個Master節(jié)點和三個slave節(jié)點組成，在節(jié)點B失敗后，集群選舉B1位為的主節(jié)點繼續(xù)服務(wù)。當B和B1都失敗后，集群將不可用5.3 搭建Redis 群集模式
redis的集群一般需要6個節(jié)點，3主3從。方便起見，這里所有節(jié)點在6臺服務(wù)器上模擬：
以IP及端口號進行區(qū)分：3個主節(jié)點端口號：7001、7003、7005，對應(yīng)的從節(jié)點端口號：7002、7004、7006。
??六臺服務(wù)器都需要安裝redis數(shù)據(jù)庫
?文章來源地址http://www.zghlxwxcb.cn/news/detail-612762.html
5.3.1 所有節(jié)點都要做
cd /etc/redis/
mkdir -p redis-cluster/redis6379
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6379/
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6379/??
5.3.2 Master1節(jié)點?
#其他5個文件夾的配置文件以此類推修改，注意6個端口都要不一樣。
cd /etc/redis/redis-cluster/redis6379
vim redis.conf
bind 192.168.19.3 #69行，修改bind項，監(jiān)聽自己的IP
protected-mode no #88行，修改，關(guān)閉保護模式
port 7001 #92行，修改，redis監(jiān)聽端口，
daemonize yes #136行，以獨立進程啟動
cluster-enabled yes #832行，取消注釋，開啟群集功能
cluster-config-file nodes-6379.conf #840行，取消注釋，群集名稱文件設(shè)置，無需修改
cluster-node-timeout 15000 #846行，取消注釋群集超時時間設(shè)置
appendonly yes #699行，修改，開啟AOF持久化?
?
?
?
?
5.3.3 其余節(jié)點
vim /etc/redis/redis-cluster/redis6379/redis.conf5.3.4 所有節(jié)點
啟動redis節(jié)點
cd /etc/redis/redis-cluster/redis6379/
redis-server redis.conf
?
?文章來源：http://www.zghlxwxcb.cn/news/detail-612762.html
?
?
?
到了這里，關(guān)于Redis（主從復(fù)制、哨兵模式、集群）概述及部署的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
