Redis的常見四種部署方案
這篇文章介紹Reids最為常見的四種部署模式，其實Reids和數據庫的集群模式差不多，可以分為 Redis單機模式部署、Redis主從模式部署、Redis哨兵模式部署、Cluster集群模式部署，其他的部署方式基本都是圍繞以下幾種方式在進行調整到適應的生產環(huán)境，最常見的還是集群模式的部署
接下來我們來主要分析和學習一下的部署方式和利弊。
約定信息：
系統：Linux CentOS 7.9
Redis版本：Redis 7.2.2
方案一：單機模式部署 編譯部署
# 設置內核參數 [root@redis ~]# echo "vm.overcommit_memory=1" >> /etc/sysctl.conf [root@redis ~]# echo "net.core.somaxconn=511" >> /etc/sysctl.conf [root@redis ~]# sysctl # 查看生效情況 # 下載二進制包并編譯 [root@redis ~]# wget http://download.redis.io/releases/redis-7.2.2.tar.gz [root@redis ~]# tar zxf redis-7.2.2.tar.gz -C /usr/local/ [root@redis ~]# cd /usr/local/redis-7.2.2/ [root@redis redis-7.2.2]# make # 編輯redis.conf配置文件 [root@redis redis-7.2.2]# vim redis.conf # 綁定主機iP bind 0.0.0.0 # 設置端口號 port 6379 # 啟用后臺運行 daemonize yes # 設置redis密碼 requirepass 123123 # 啟動并查看監(jiān)聽和進程 [root@redis ~]# /usr/local/redis-7.2.2/src/redis-server /usr/local/redis-7.2.2/redis.conf [root@redis ~]# ps -ef | grep redis root 878 1 0 23:24 ? 00:00:00 /sbin/dhclient -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid -H redis eth0 root 12429 1 0 23:42 ? 00:00:00 /usr/local/redis-7.2.2/src/redis-server 0.0.0.0:6379 root 12505 12289 0 23:43 pts/1 00:00:00 grep --color=auto redis [root@redis ~]# netstat -tnlp | grep redis tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 12429/redis-server # 停止 [root@redis ~]# ./redis-cli -p 6379 -a 123123 shutdown # 客戶端連接測試測試 [root@redis ~]# /usr/local/redis-7.2.2/src/redis-cli 127.0.0.1:6379> auth 123123 OK 127.0.0.1:6379> set flag if010.com OK 127.0.0.1:6379> get flag "if010.com" 127.0.0.1:6379>
使用systemctl進行管理
[root@redis ~]# cp ../utils/redis_init_script /etc/init.d/redis #不同版本可能位置不同
[root@redis ~]# vim /etc/init.d/redis
Port : 6379
Config file : /usr/local/redis/conf/redis.conf
Log file : /usr/local/redis/log/redis.log
Data dir : /usr/local/redis/data
Executable : /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
Cli Executable : /usr/local/redis/bin/redis-cli
# redis Start up the redis server daemon
#
# chkconfig: 2345 55 25
添加chkconfig 開機啟動
....
redis.service
[Unit]
Description=Redis Server
After=network-online.target
[Service]
Type=forking
PIDFile=/var/run/redis_6379.pid
ExecStart=/etc/init.d/redis start
ExecStop=/etc/init.d/redis stop
ExecReload=/etc/init.d/redis reload
PrivateTmp=true
[Install]
WantedBy=multi-user.target至此單機模式就部署完成了，優(yōu)點嘛就是能用，缺點就是故障了就無法提供服務，且沒有備份，所以接下來介紹第二種方案—主從模式部署
單點服務器帶來的問題
- 單點故障，服務不可用
- 無法處理大量的并發(fā)數據
- 數據丟失----大災難
- 開啟多Redis進程
- Redis默認單進程
- 開啟多進程導致CPU壓力過大
- 對于服務器（縱向）消耗服務器硬件性能CPU
方案二：主從模式部署 Redis主從原理
和MySQL需要主從復制的原因一樣，Redis雖然讀取寫入的速度都特別快，但是也會產生性能瓶頸，特別是在讀壓力上，為了分擔壓力，Redis支持主從復制。Redis的主從結構一主一從，一主多從或級聯結構，復制類型可以根據是否是全量而分為全量同步和增量同步。
下圖為級聯結構：
Redis主從同步的策略
主從同步剛連接的時候進行全量同步；全量同步結束后開始增量同步。如果有需要，slave在任何時候都可以發(fā)起全量同步，其主要策略就是無論如何首先會嘗試進行增量同步，如果不成功，則會要求slave進行全量同步，之后再進行增量同步。
注意：如果多個slave同時斷線需要重啟的時候，因為只要slave啟動，就會和master建立連接發(fā)送SYNC請求和主機全量同步，如果多個同時發(fā)送SYNC請求，可能導致master IO突增而發(fā)送宕機。
全量同步
Redis全量同步一般發(fā)生在slave的初始階段，這時slave需要將master上的數據都復制一份，具體步驟如下：
- slave連接master，發(fā)送SYNC命令；
- master街道SYNC命令后，執(zhí)行BGSAVE命令生產RDB文件并使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令；
- master的BGSAVE執(zhí)行完成后，向所有的slave發(fā)送快照文件，并在發(fā)送過程中繼續(xù)記錄執(zhí)行的寫命令；
- slave收到快照后，丟棄所有的舊數據，載入收到的數據；
- master快照發(fā)送完成后就會開始向slave發(fā)送緩沖區(qū)的寫命令；
- slave完成對快照的載入，并開始接受命令請求，執(zhí)行來自master緩沖區(qū)的寫命令；
- slave完成上面的數據初始化后就可以開始接受用戶的讀請求了。
大致流程如下：
增量復制
增量復制實際上就是在slave初始化完成后開始正常工作時master發(fā)生寫操作同步到slave的過程。增量復制的過程主要是master每執(zhí)行一個寫命令就會向slave發(fā)送相同的寫命令，slave接受并執(zhí)行寫命令，從而保持主從一致。
Redis主從同步的特點
- 采用異步復制；
- 可以一主多從；
- 主從復制對于master來說是非阻塞的，也就是說slave在進行主從復制的過程中，master依然可以處理請求；
- 主從復制對于slave來說也是非阻塞的，也就是說slave在進行主從復制的過程中也可以接受外界的查詢請求，只不過這時候返回的數據不一定是正確的。為了避免這種情況發(fā)生，可以在slave的配置文件中配置，在同步過程中阻止查詢；
- 每個slave可以接受來自其他slave的連接；
- 主從復制提高了Redis服務的擴展性，避免單節(jié)點問題，另外也為數據備份冗余提供了一種解決方案；
- 為了降低主redis服務器寫磁盤壓力帶來的開銷，可以配置讓主redis不在將數據持久化到磁盤，而是通過連接讓一個配置的從redis服務器及時的將相關數據持久化到磁盤，不過這樣會存在一個問題，就是主redis服務器一旦重啟，因為主redis服務器數據為空，這時候通過主從同步可能導致從redis服務器上的數據也被清空；
部署方式
環(huán)境約定：Master節(jié)點：172.17.0.100、Slave1節(jié)點：172.17.0.101、Slave2節(jié)點：172.17.0.102
部署思路：先配置好Master節(jié)點，然后拷貝到Slave1節(jié)點上，在Master節(jié)點的配置基礎上再配置replicaof和masterauth，其他節(jié)點直接拷貝Slave1節(jié)點上的配置文件即可
編譯安裝
編譯安裝好Redis環(huán)境(所有節(jié)點操作)
# 下載軟件包 [root@Redis-Test1 ~]# wget http://download.redis.io/releases/redis-7.2.2.tar.gz # 解壓軟件包 [root@Redis-Test1 ~]# tar zxf redis-7.2.2.tar.gz -C /usr/local/ [root@Redis-Test1 ~]# cd /usr/local/redis-7.2.2/ [root@Redis-Test1 redis-7.2.2]# ls 00-RELEASENOTES CODE_OF_CONDUCT.md COPYING INSTALL MANIFESTO redis.conf runtest-cluster runtest-sentinel sentinel.conf tests utils BUGS CONTRIBUTING.md deps Makefile README.md runtest runtest-moduleapi SECURITY.md src TLS.md # 編譯 [root@redis-master-01 ~]# make
編輯配置文件
修改Redis的配置文件（Master節(jié)點操作）
[root@Redis-Test1 redis-7.2.2]# vim redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /data/redis/redis.pid logfile "/data/redis/logs/redis.log" appendonly yes #開啟AOF持久化 requirepass 123123 dir /data/redis/
修改Redis的配置文件（Slave節(jié)點操作）
[root@Redis-Test2 redis-7.2.2]# vim redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /data/redis/redis.pid logfile "/data/redis/logs/redis.log" appendonly yes requirepass 123123 dir /data/redis/ replicaof 172.17.0.100 6379 #指定要同步的master節(jié)點ip和端口 masterauth 123123 #指定master的認證口令
啟動
這里要注意一下，先啟動Master節(jié)點，然后在啟動Slave節(jié)點
[root@Redis-Test2 redis-7.2.2]# vim redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /data/redis/redis.pid logfile "/data/redis/logs/redis.log" appendonly yes requirepass 123123 dir /data/redis/ replicaof 172.17.0.100 6379 #指定要同步的master節(jié)點ip和端口 masterauth 123123 #指定master的認證口令
驗證主從效果
從日志上分析驗證
[root@Redis-Test2 logs]# tailf redis.log 9025:S 01 Nov 2023 17:45:28.450 * Done loading RDB, keys loaded: 0, keys expired: 0. 9025:S 01 Nov 2023 17:45:28.450 * DB loaded from base file appendonly.aof.1.base.rdb: 0.001 seconds 9025:S 01 Nov 2023 17:45:28.450 * DB loaded from append only file: 0.001 seconds 9025:S 01 Nov 2023 17:45:28.450 * Opening AOF incr file appendonly.aof.1.incr.aof on server start 9025:S 01 Nov 2023 17:45:28.450 * Ready to accept connections tcp 9025:S 01 Nov 2023 17:45:28.450 * Connecting to MASTER 172.17.0.100:6379 9025:S 01 Nov 2023 17:45:28.450 * MASTER <-> REPLICA sync started 9025:S 01 Nov 2023 17:45:28.451 * Non blocking connect for SYNC fired the event. 9025:S 01 Nov 2023 17:45:28.451 * Master replied to PING, replication can continue... 9025:S 01 Nov 2023 17:45:28.451 * Partial resynchronization not possible (no cached master) 9025:S 01 Nov 2023 17:45:33.418 * Full resync from master: d9da2499f5cdb878a424e33159ec2b795ea7db17:14 9025:S 01 Nov 2023 17:45:33.419 * MASTER <-> REPLICA sync: receiving streamed RDB from master with EOF to disk 9025:S 01 Nov 2023 17:45:33.419 * MASTER <-> REPLICA sync: Flushing old data 9025:S 01 Nov 2023 17:45:33.419 * MASTER <-> REPLICA sync: Loading DB in memory 9025:S 01 Nov 2023 17:45:33.422 * Loading RDB produced by version 7.2.2 9025:S 01 Nov 2023 17:45:33.422 * RDB age 0 seconds 9025:S 01 Nov 2023 17:45:33.422 * RDB memory usage when created 0.94 Mb 9025:S 01 Nov 2023 17:45:33.422 * Done loading RDB, keys loaded: 0, keys expired: 0. 9025:S 01 Nov 2023 17:45:33.422 * MASTER <-> REPLICA sync: Finished with success 9025:S 01 Nov 2023 17:45:33.422 * Creating AOF incr file temp-appendonly.aof.incr on background rewrite 9025:S 01 Nov 2023 17:45:33.423 * Background append only file rewriting started by pid 9031 9031:C 01 Nov 2023 17:45:33.424 * Successfully created the temporary AOF base file temp-rewriteaof-bg-9031.aof 9031:C 01 Nov 2023 17:45:33.425 * Fork CoW for AOF rewrite: current 4 MB, peak 4 MB, average 4 MB 9025:S 01 Nov 2023 17:45:33.466 * Background AOF rewrite terminated with success 9025:S 01 Nov 2023 17:45:33.466 * Successfully renamed the temporary AOF base file temp-rewriteaof-bg-9031.aof into appendonly.aof.2.base.rdb 9025:S 01 Nov 2023 17:45:33.466 * Successfully renamed the temporary AOF incr file temp-appendonly.aof.incr into appendonly.aof.2.incr.aof 9025:S 01 Nov 2023 17:45:33.469 * Removing the history file appendonly.aof.1.incr.aof in the background 9025:S 01 Nov 2023 17:45:33.469 * Removing the history file appendonly.aof.1.base.rdb in the background 9025:S 01 Nov 2023 17:45:33.472 * Background AOF rewrite finished successfully
從Master節(jié)點上查看節(jié)點信息
[root@Redis-Test1 redis-7.2.2]# ./src/redis-cli 127.0.0.1:6379> auth 123123 OK 127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 slave0:ip=172.17.0.101,port=6379,state=online,offset=98,lag=1 slave1:ip=172.17.0.102,port=6379,state=online,offset=98,lag=1 master_failover_state:no-failover master_replid:d9da2499f5cdb878a424e33159ec2b795ea7db17 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:98 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:98
方案三：哨兵模式部署
Sentinel是Redis官方為集群提供的高可用解決方案。 在實際項目中可以使用sentinel去做redis自動故障轉移，減少人工介入的工作量，另外sentinel也給客戶端提供了監(jiān)控消息的通知，這樣客戶端就可根據消息類型去判斷服務器的狀態(tài)，去做對應的適配操作
Sentinel 哨兵的作用
- Monitoring（集群監(jiān)控）：Sentinel持續(xù)檢查集群中的master、slave狀態(tài)，判斷是否存活
- Notification（消息通知）：在發(fā)現某個redis實例死的情況下，Sentinel能通過API通知系統管理員或其他程序腳本
- Automatic failover（故障轉移）：如果一個master掛掉后，sentinel會啟動故障轉移，把某個slave提升為master，其他的slave重新配置指向新master
- Configuration provider（配置中心）：對于客戶端來說sentinel通知是有效可信賴的，客戶端會連接sentinel去請求當前master的地址，一旦發(fā)生故障sentinel會提供新地址給客戶端
核心功能：在主從復制的基礎上，哨兵引入了主節(jié)點的自動故障轉移
哨兵的核心
- 哨兵至少需要 3 個實例，來保證自己的健壯性
- 哨兵 + redis 主從的部署架構，是不保證數據零丟失的，只能保證 redis 集群的高可用性
對于哨兵 + redis 主從這種復雜的部署架構，盡量在測試環(huán)境和生產環(huán)境，都進行充足的測試和演練
哨兵模式的故障遷移
主觀下線
哨兵(Sentinel)節(jié)點會每秒一次的頻率向建立了命令連接的實例發(fā)送PING命令，如果在down-after-milliseconds毫秒內沒有做出有效響應包括(PONG/ LOADING/MASTERDOWN)以外的響應，哨兵就會將該實例在本結構體中的狀態(tài)標記為SRI_s_DOWN主觀下線
客觀下線
當一個哨兵節(jié)點發(fā)現主節(jié)點處于主觀下線狀態(tài)是，會向其他的哨兵節(jié)點發(fā)出詢問，該節(jié)點是不是已經主觀下線了。如果超過配置參數quorum個節(jié)點認為是主觀下線時，該哨兵節(jié)點就會將自己維護的結構體中該主節(jié)點標記為SRIO DOWN客觀下線詢問命令SENTINEL is-master-down-by-addr
master選舉
在認為主節(jié)點客觀下線的情況下，哨兵節(jié)點節(jié)點間會發(fā)起一次選舉，命令為:SENTINEL is-master-down-by-addr只是runid這次會將自己的runid帶進去， 希望接受者將自己設置為主節(jié)點。如果超過半數以上的節(jié)點返回將該節(jié)點標記為leacer的情況下，會有該leader對故障進行遷移 master選舉規(guī)則
新主庫選擇：哨兵在選擇新主庫時,先按照一定的篩選條件，把不符合條件的從庫去掉，再按照一定的規(guī)則，給剩下的從庫逐個打分，將得分最高的從庫選為新主庫
從庫篩選
在選主時，除了要檢查從庫的當前在線狀態(tài)，還要判斷它之前的網絡連接狀態(tài)，如果從庫總是和主庫斷連，而且斷連次數超出了一定的閾值，表明這個從庫的網絡狀況并不是太好，就可以把這個從庫去掉了
在sentinel配置項down-after-milliseconds * 10中，down-after-milliseconds 是認定主從庫斷連的最大連接超時時間，如果在down-aftermilliseconds毫秒內，主從節(jié)點都沒有通過網絡聯系上，就可以認為主從節(jié)點斷連了，如果發(fā)生斷連的次數超過了10次，就說明這個從庫的網絡狀況不好，不適合作為新主庫
從庫分數判斷
Sentinle集群選主中，分別按照三個規(guī)則依次進行三輪打分，這三個規(guī)則分別是從庫優(yōu)先級、從庫復制進度以及從庫 ID 號，只要在某一輪中，有從庫得分最高，那么它就是主庫了，選主過程到此結束，如果沒有出現得分最高的從庫，那么就繼續(xù)進行下一輪
第一輪：優(yōu)先級最高的從庫得分高
用戶可以通過slave-priority配置項，給不同的從庫設置不同優(yōu)先級，比如，有兩個從庫，它們的內存大小不一樣，可以手動給內存大的實例設置一個高優(yōu)先級，在選主時， 哨兵會給優(yōu)先級高的從庫打高分，如果有一個從庫優(yōu)先級最高，那么它就是新主庫了，如果從庫的優(yōu)先級都一樣，那么哨兵開始第二輪打分
第二輪：和舊主庫同步程度最接近的從庫得分高
這個規(guī)則的依據是，如果選擇和舊主庫同步最接近的那個從庫作為主庫，那么，這個新主庫上就有最新的數據
如何判斷從庫和舊主庫間的同步進度呢？
主從庫同步時有個命令傳播的過程。在這個過程中，主庫會用master_repl_offset記錄當前的最新寫操作在 repl_backlog_buffer中的位置，而從庫會用slave_repl_offset這個值記錄當前的復制進度
此時，我們想要找的從庫，它的slave_repl_offset需要最接近master_repl_offset，如果在所有從庫中，有從庫的slave_repl_offset最接近master_repl_offset，那么它的得分就最高，可以作為新主庫，但并不是取slave_repl_offset與master_repl_offset做對比，而是不同從庫的slave_repl_offset進行對比的，因為這個時候master已經掛掉了，無法獲取master_repl_offset，所以在實際的選主代碼中，哨兵在這一步，是通過比較不同從庫的slave_repl_offset，找出最大slave_repl_offset的從庫，也就是選擇salve_repl_offset最大的那個從庫
master_repl_offset機制：master_repl_offset是單調增加的，它的值可以大于repl_backlog_size。Redis會用一個名為repl_backlog_idx的值記錄在環(huán)形緩沖區(qū)中的最新寫入位置
舉個例子，例如寫入len的數據，那么 master_repl_offset += len > repl_backlog_idx += len，但是，如果repl_backlog_idx等于repl_backlog_size時，repl_backlog_idx會被置為0，表示從環(huán)形緩沖區(qū)開始位置繼續(xù)寫入
第三輪：ID 號小的從庫得分高
每個實例都會有一個 ID，這個 ID 就類似于這里的從庫的編號，目前Redis在選主庫時，有一個默認的規(guī)定：在優(yōu)先級和復制進度都相同的情況下，ID 號最小的從庫得分最高，會被選為新主庫，Redis server啟動時，會生成一個40字節(jié)長的隨機字符串作為runID，具體算法用的是 SHA-1算法
部署方式
環(huán)境約定：Master節(jié)點：172.17.0.100、Slave1節(jié)點：172.17.0.101、Slave2節(jié)點：172.17.0.102
部署思路：先配置好主從模式的環(huán)境，然后再修改sentinel.conf配置文件，最后啟動即可
編譯安裝
編譯安裝好Redis環(huán)境(所有節(jié)點操作)
# 下載軟件包 [root@Redis-Test1 ~]# wget http://download.redis.io/releases/redis-7.2.2.tar.gz # 解壓軟件包 [root@Redis-Test1 ~]# tar zxf redis-7.2.2.tar.gz -C /usr/local/ [root@Redis-Test1 ~]# cd /usr/local/redis-7.2.2/ [root@Redis-Test1 redis-7.2.2]# ls 00-RELEASENOTES CODE_OF_CONDUCT.md COPYING INSTALL MANIFESTO redis.conf runtest-cluster runtest-sentinel sentinel.conf tests utils BUGS CONTRIBUTING.md deps Makefile README.md runtest runtest-moduleapi SECURITY.md src TLS.md # 編譯 [root@redis-master-01 ~]# make
編輯redis配置文件
修改Redis的配置文件（Master節(jié)點操作）
[root@Redis-Test1 redis-7.2.2]# vim redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /data/redis/redis.pid logfile "/data/redis/logs/redis.log" appendonly yes #開啟AOF持久化 requirepass 123123 dir /data/redis/
修改Redis的配置文件（Slave節(jié)點操作）
[root@Redis-Test2 redis-7.2.2]# vim redis.conf bind 0.0.0.0 port 6379 daemonize yes pidfile /data/redis/redis.pid logfile "/data/redis/logs/redis.log" appendonly yes requirepass 123123 dir /data/redis/ replicaof 172.17.0.100 6379 #指定要同步的master節(jié)點ip和端口 masterauth 123123 #指定master的認證口令
啟動Redis服務
這里要注意一下，先啟動Master節(jié)點，然后在啟動Slave節(jié)點
/usr/local/redis-7.2.2/src/redis-server /usr/local/redis-7.2.2/redis.conf
到此結束主從環(huán)境的配置，接下來配置哨兵環(huán)節(jié)
配置Sentinel配置文件
修改Redis哨兵模式的配置文件（所有節(jié)點操作）
[root@Redis-Test1 redis-7.2.2]# vim sentinel.conf bind 0.0.0.0 port 26379 daemonize yes #哨兵的啟動模式，yes是后臺啟動 pidfile /data/redis/redis-sentinel.pid #哨兵的pid文件存放位置 logfile "/data/redis/logs/redis-sentinel.log" #哨兵的日志文件存放位置 dir /data #哨兵進程的工作目錄，默認就是/tmp #哨兵監(jiān)聽的master數據庫，mymaster是為主數據庫起的名稱，可以隨便起個名字，后面是master的ip和端口 # 最后面的1表示選舉個數，含義是需要多少個哨兵認為master掛了才認定master掛掉，這里我設置為1是因為我只有一個哨兵，如果你配置了多個哨兵，建議配置2以上數字。 sentinel monitor mymaster 172.17.0.100 6379 1 sentinel auth-pass mymaster 123123 #配置master的登陸密碼，mymaster是你配置的master名稱 sentinel down-after-milliseconds mymaster 30000 #30秒內master無響應則認為master掛掉 acllog-max-len 128 #保持默認即可 #master重新選舉之后，其它節(jié)點能同時并行進行數據同步的臺數有多少臺 #顯然該值越大，則所有slave能同步完成的速度越快，但如果此時剛好有人訪問slave數據，可能造成讀取失敗，最保守的值建議設為1 #即同一時間只能有一臺進行數據同步，這樣其它slave還能繼續(xù)提供服務，但是所有的slave數據同步完成就會顯得緩慢。 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 #故障轉移超時時間，指在該時間內如果故障轉移沒有成功，則會再發(fā)起一次故障轉移 sentinel deny-scripts-reconfig yes #保持默認即可 SENTINEL resolve-hostnames no #保持默認即可 SENTINEL announce-hostnames no #保持默認即可
啟動哨兵服務
先啟master的哨兵，再啟slave的哨兵
/usr/local/redis-7.2.2/src/redis-sentinel /usr/local/redis-7.2.2/sentinel.conf
查看相關信息
[root@Redis-Test3 redis-7.2.2]# ./src/redis-cli -p 26379 127.0.0.1:26379> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_tilt_since_seconds:-1 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=172.17.0.100:6379,slaves=2,sentinels=1
驗證故障轉移
關閉Master節(jié)點，觀察日志和sentinel信息
12697:X 01 Nov 2023 19:45:57.990 # +monitor master mymaster 172.17.0.100 6379 quorum 1 12697:X 01 Nov 2023 19:47:10.430 # +sdown master mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:10.430 # +odown master mymaster 172.17.0.100 6379 #quorum 1/1 12697:X 01 Nov 2023 19:47:10.430 # +new-epoch 1 12697:X 01 Nov 2023 19:47:10.430 # +try-failover master mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:10.434 * Sentinel new configuration saved on disk 12697:X 01 Nov 2023 19:47:10.434 # +vote-for-leader 02f863db4ebd9962c4557bcad9ec78afd2b86613 1 12697:X 01 Nov 2023 19:47:10.434 # +elected-leader master mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:10.434 # +failover-state-select-slave master mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:10.517 # +selected-slave slave 172.17.0.102:6379 172.17.0.102 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:10.517 * +failover-state-send-slaveof-noone slave 172.17.0.102:6379 172.17.0.102 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:10.690 * +failover-state-wait-promotion slave 172.17.0.102:6379 172.17.0.102 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:11.607 * Sentinel new configuration saved on disk 12697:X 01 Nov 2023 19:47:11.607 # +promoted-slave slave 172.17.0.102:6379 172.17.0.102 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:11.607 # +failover-state-reconf-slaves master mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:11.703 * +slave-reconf-sent slave 172.17.0.101:6379 172.17.0.101 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:12.814 * +slave-reconf-inprog slave 172.17.0.101:6379 172.17.0.101 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:12.814 * +slave-reconf-done slave 172.17.0.101:6379 172.17.0.101 6379 @ mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:12.866 # +failover-end master mymaster 172.17.0.100 6379 12697:X 01 Nov 2023 19:47:12.866 # +switch-master mymaster 172.17.0.100 6379 172.17.0.102 6379 12697:X 01 Nov 2023 19:47:12.867 * +slave slave 172.17.0.101:6379 172.17.0.101 6379 @ mymaster 172.17.0.102 6379 12697:X 01 Nov 2023 19:47:12.867 * +slave slave 172.17.0.100:6379 172.17.0.100 6379 @ mymaster 172.17.0.102 6379 12697:X 01 Nov 2023 19:47:12.871 * Sentinel new configuration saved on disk 12697:X 01 Nov 2023 19:47:42.911 # +sdown slave 172.17.0.100:6379 172.17.0.100 6379 @ mymaster 172.17.0.102 6379
[root@Redis-Test3 redis-7.2.2]# ./src/redis-cli -p 26379 127.0.0.1:26379> info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_tilt_since_seconds:-1 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=172.17.0.102:6379,slaves=2,sentinels=1 [root@Redis-Test3 redis-7.2.2]# ./src/redis-cli 127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=172.17.0.101,port=6379,state=online,offset=55358,lag=0 master_failover_state:no-failover master_replid:1bc5d3796192e6c518baa423a3d24573a0360abd master_replid2:0963bdef90dddf0294c0972160a9476e40345768 master_repl_offset:55358 second_repl_offset:8434 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:55358
關于切換不成功常見的問題
無法切換，有幾種情況：
- redis保護模式開啟了
- 選舉個數多了或者少了
- 端口沒有放開
- master密碼和從密碼不一致
- master節(jié)點的redis.conf沒有添加masterauth
方案四：集群模式部署
集群，即Redis Cluster，是Redis 3.0開始引入的分布式存儲方案，集群由多個節(jié)點(Node)組成，Redis的數據分布在這些節(jié)點中，集群中的節(jié)點分為主節(jié)點和從節(jié)點:只有主節(jié)點負責讀寫請求和集群信息的維護，從節(jié)點只進行主節(jié)點數據和狀態(tài)信息的復制
Redis-Cluster集群的作用
數據分區(qū)： 數據分區(qū)(或稱數據分片)是集群最核心的功能，集群將數據分散到多個節(jié)點，一方面突破了Redis單機內存大小的限制，存儲容量大大增加，另一方面每個主節(jié)點都可以對外提供讀服務和寫服務，大大提高了集群的響應能力，Redis單機內存大小受限問題，在介紹持久化和主從復制時都有提及，例如，如果單機內存太大，bgsave和bgrewriteaof 的保存操作可能導致主進程阻塞，主從環(huán)境下主機切換時可能導致從節(jié)點長時間無法提供服務，全量復制階段主節(jié)點的復制緩沖區(qū)可能溢出
高可用： 集群支持主從復制和主節(jié)點的自動故障轉移（與哨兵類似）當任一節(jié)點發(fā)生故障時，集群仍然可以對外提供服務 Redis集群的數據分片
Redis集群引入了哈希槽的概念，Redis集群有16384個哈希槽（編號0-16383)集群的每個節(jié)點負責部分哈希槽，每個Key通過CRc16校驗后對16384取余來決定放置哪個哈希槽，通過這個值，去找到對應的插槽所對應的節(jié)點，然后直接自動跳轉到這個對應的節(jié)點上進行存取操作
以3個節(jié)點組成的集群為例:
節(jié)點A包含0到5460號哈希槽
節(jié)點B包含5461到10922號哈希槽
節(jié)點C包含10923到16383號哈希槽
Redis集群的主從復制模型
集群中具有A、B、C三個節(jié)點，如果節(jié)點B失敗了，整個集群就會因缺少5461-10922這個范圍的槽而不可以用，為每個節(jié)點添加一個從節(jié)點A1、B1、C1整個集群便有三個Master節(jié)點和三個slave 節(jié)點組成，在節(jié)點B失敗后，集群選舉一位為主節(jié)點繼續(xù)服務，但是要注意的是當B和B1都失敗后，集群將不可用
Redis Cluster的工作原理
在哨兵sentinel機制中，可以解決redis高可用問題，即當master故障后可以自動將slave提升為master，從而可以保證redis服務的正常使用，但是無法解決redis單機寫入的瓶頸問題，即單機redis寫入性能受限于單機的內存大小、并發(fā)數量、網卡速率等因素
部署方式
環(huán)境約定：
- Master節(jié)點：172.17.0.101、172.17.0.103、172.17.0.105
- Slave節(jié)點：172.17.0.102、172.17.0.104、172.17.0.106
部署思路：安裝部署好所有節(jié)點的redis服務并啟動，然后使用自動部署集群工具設定集群
編譯安裝
# 下載軟件包 [root@redis-master-01 ~]# wget http://download.redis.io/releases/redis-7.2.2.tar.gz # 解壓軟件包 [root@redis-master-01 ~]# tar zxf redis-7.2.2.tar.gz -C /usr/local/ [root@redis-master-01 ~]# cd /usr/local/redis-7.2.2/ [root@redis-master-01 redis-7.2.2]# ls 00-RELEASENOTES CODE_OF_CONDUCT.md COPYING INSTALL MANIFESTO redis.conf runtest-cluster runtest-sentinel sentinel.conf tests utils BUGS CONTRIBUTING.md deps Makefile README.md runtest runtest-moduleapi SECURITY.md src TLS.md # 編譯 [root@redis-master-01 ~]# make
編輯配置文件
# 編輯配置文件 vim /usr/local/redis-7.2.2/redis.conf # 監(jiān)聽端口 port 6379 # IP不限制，習慣改成0了，必須，避免后面出現麻煩，如果是外網，必須! bind 0.0.0.0 # 設置Redis實例pid文件 pidfile /data/redis/redis.pid # 后臺模式，必須 daemonize yes # 僅追加 appendonly yes appendfsync always # 集群開啟，必須 cluster-enabled yes # 節(jié)點信息，可選，因為系統會默認 cluster-config-file nodes.conf # 設置當前節(jié)點連接超時毫秒數 cluster-node-timeout 15000 # 數據存放目錄 dir /data/redis/ # 認證密碼 requirepass 123123 # 設置客戶端連接時的超時時間，單位為秒 timeout 60 # 日志等級：debug，revbose，notice和warning loglevel notice # 配置log文件地址，默認使用標準輸出 logfile "/data/redis/logs/redis.log" # 設置數據庫的個數，默認使用的數據庫是0 databases 16 # 設置redis進行數據庫鏡像的頻率 save 900 1 300 10 60 10000 # 鏡像備份文件的文件名 dbfilename dump.rdb
啟動Redis
# 啟動Redis [root@redis-master-01 redis-7.2.2]# /usr/local/redis-7.2.2/src/redis-server /usr/local/redis-7.2.2/redis.conf [root@redis-master-01 ~]# netstat -tnlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1083/sshd tcp 0 0 0.0.0.0:16379 0.0.0.0:* LISTEN 10980/redis-server tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 10980/redis-server
驗證服務
驗證沒有問題后其余的節(jié)點也是這么配置即可~
自動搭建集群
Redis 3.0 版本之后官方發(fā)布了一個集群管理工具 redis-trib.rb，集成在 Redis 源碼包的src目錄下。其封裝了 Redis 提供的集群命令，使用簡單、便捷。不過 redis-trib.rb 是 Redis 作者使用 Ruby 語言開發(fā)的，故使用該工具之前還需要先在機器上安裝 Ruby 環(huán)境。后面作者可能意識到這個問題，Redis 5.0 版本開始便把這個工具集成到 redis-cli 中，以–cluster參數提供使用，其中create命令可以用來創(chuàng)建集群。如果您安裝的 Redis 是 3.x 和 4.x 的版本可以使用 redis-trib.rb 搭建，不過之前需要安裝 Ruby 環(huán)境。先使用 yum 安裝 Ruby 環(huán)境以及其他依賴項：
yum -y install ruby ruby-devel rubygems rpm-build
查看ruby版本
ruby -v
確認沒有問題之后，我們就可以創(chuàng)建集群了
./redis-cli -a 123123 --cluster create 172.17.0.101:6379 172.17.0.103:6379 172.17.0.105:6379 172.17.0.102:6379 172.17.0.104:6379 172.17.0.106:6379 --cluster-replicas 1
注意：主節(jié)點在前，從節(jié)點在后。其中–cluster-replicas參數用來指定一個主節(jié)點帶有的從節(jié)點個數，如上–cluster-replicas 1即表示 1 個主節(jié)點有 1 個從節(jié)點
至此，Redis集群搭建完畢！
我們可以查看一下節(jié)點信息，用一下命令或者可查看redis任意一個目錄下的 nodes.conf配置文件
[root@redis-master-01 ~]# cat /data/redis/nodes.conf 5f2ce841ecf51d58be0120f7132e1abff2f3b8bc 172.17.0.102:6379@16379,,tls-port=0,shard-id=327de171b1a685bf6f4741253bb8dc7c3134b7b4 slave 78f722a1b410336219fafbe1813fdb5456d9cf0a 0 1698661133000 3 connected 25115e9cb55c0981f16165f19ade5b9de5c6ce87 172.17.0.103:6379@16379,,tls-port=0,shard-id=19c2b46d9a0d0038ae1b57f6c7c4449eb6647c6f master - 0 1698661133000 2 connected 5461-10922 f7cf16beffbb991aa1a2de43b6738289904d683b 172.17.0.104:6379@16379,,tls-port=0,shard-id=8d019b1cdda30d0ad959a197c7cf6308016d1999 slave 278629f1ab3f5d1fcfdbb1274d3000d03be102a7 0 1698661131000 1 connected 2ab90783a1275af9e1fbcee0d3207bea36953e89 172.17.0.106:6379@16379,,tls-port=0,shard-id=19c2b46d9a0d0038ae1b57f6c7c4449eb6647c6f slave 25115e9cb55c0981f16165f19ade5b9de5c6ce87 1698661126915 1698661124000 2 disconnected 278629f1ab3f5d1fcfdbb1274d3000d03be102a7 172.17.0.101:6379@16379,,tls-port=0,shard-id=8d019b1cdda30d0ad959a197c7cf6308016d1999 myself,master - 0 1698661124000 1 connected 0-5460 78f722a1b410336219fafbe1813fdb5456d9cf0a 172.17.0.105:6379@16379,,tls-port=0,shard-id=327de171b1a685bf6f4741253bb8dc7c3134b7b4 master - 0 1698661133000 3 connected 10923-16383 vars currentEpoch 6 lastVoteEpoch 0
或者
[root@redis-master-01 ~]# cat /data/redis/nodes.conf 5f2ce841ecf51d58be0120f7132e1abff2f3b8bc 172.17.0.102:6379@16379,,tls-port=0,shard-id=327de171b1a685bf6f4741253bb8dc7c3134b7b4 slave 78f722a1b410336219fafbe1813fdb5456d9cf0a 0 1698661133000 3 connected 25115e9cb55c0981f16165f19ade5b9de5c6ce87 172.17.0.103:6379@16379,,tls-port=0,shard-id=19c2b46d9a0d0038ae1b57f6c7c4449eb6647c6f master - 0 1698661133000 2 connected 5461-10922 f7cf16beffbb991aa1a2de43b6738289904d683b 172.17.0.104:6379@16379,,tls-port=0,shard-id=8d019b1cdda30d0ad959a197c7cf6308016d1999 slave 278629f1ab3f5d1fcfdbb1274d3000d03be102a7 0 1698661131000 1 connected 2ab90783a1275af9e1fbcee0d3207bea36953e89 172.17.0.106:6379@16379,,tls-port=0,shard-id=19c2b46d9a0d0038ae1b57f6c7c4449eb6647c6f slave 25115e9cb55c0981f16165f19ade5b9de5c6ce87 1698661126915 1698661124000 2 disconnected 278629f1ab3f5d1fcfdbb1274d3000d03be102a7 172.17.0.101:6379@16379,,tls-port=0,shard-id=8d019b1cdda30d0ad959a197c7cf6308016d1999 myself,master - 0 1698661124000 1 connected 0-5460 78f722a1b410336219fafbe1813fdb5456d9cf0a 172.17.0.105:6379@16379,,tls-port=0,shard-id=327de171b1a685bf6f4741253bb8dc7c3134b7b4 master - 0 1698661133000 3 connected 10923-16383 vars currentEpoch 6 lastVoteEpoch 0
注意：
鏈接時候，務必選擇集群模式鏈接（如果你鏈接失敗，可以重新看上面配置文件部分，或者往下看）
由于自動生成的nodes.conf文件里面，會默認生成帶有內網IP，所以你如果是要使用外網鏈接，就去把每一個Redis目錄下的
/data/redis/nodes.conf配置文件里面IP為內網的改成外網，并且16379端口也要被允許訪問（注意防火墻問題），然后再重啟所有Redis！不用再重新創(chuàng)建集群！
附錄：Redis配置參數介紹
基礎配置
bind
默認配置：bind 127.0.0.1，如果沒用通過bind命令明確綁定ip，redis可以監(jiān)聽到請求過來的所有網絡接口，
bind后面拼接1個或多個ip地址，那么該redis實例只能監(jiān)聽到來自這幾個ip的請求，
# 舉例 bind 192.168.1.100 10.0.0.1 bind 127.0.0.1 ::1 # redis默認配置的是只允許本機訪問：bind 127.0.0.1 # 如果需要redis允許其他ip訪問，那么注釋掉默認配置即可：#bind 127.0.0.1
port
默認配置：port 6379，port用來配置redis接受連接的端口，即監(jiān)聽端口
protected-mode
默認配置：protected-mode yes，protected mode是一個安全保護層，用來避免redis實例暴漏在互聯網被訪問或者利用，如果開啟保護模式并且沒有通過bind綁定外部的ip地址并且沒有通過requirepass配置密碼，那么該redis實例只能接受本地127.0.0.1回環(huán)地址的連接，如果想運行其他主機訪問，那么可以將保護模式關閉：protected-mode no
daemonize
默認配置：daemonize no，redis默認不是以守護進程的方式后臺運行，如果想后臺運行，開啟配置：daemonize yes
supervised
默認配置：supervised no，是否Supervised模式運行Redis
pidfile
默認值：pidfile /var/run/redis_6379.pid，如果配置指定了pid 文件，Redis就用該配置的pid文件寫入，退出的時候移除對應的pid文件。如果Redis是以非守護進程模式的運行，又沒有配置指定的pid文件，那么不會創(chuàng)建pid文件。如果Redis是守護進程的模式，即使沒有配置指定的pid文件，會默認使用 /var/run/redis.pid文件
loglevel
默認配置：loglevel notice，指定Server的日志級別，有以下四種級別：
- debug（包含許多具體信息，開發(fā)/測試環(huán)境下很方便）
- verbose（包含許多不常用的信息，但沒有debug級別那么混亂）
- notice（適中的信息，很適合生產環(huán)境）
- warning（只記錄重要或者非常的信息）
logfile
默認值：logfile “”，指定log文件名。配置成空串的話可以強制Redis在標準輸出記錄日志。如果使用標準輸出進行日志記錄且是以守護進程的模式運行，日志會在/dev/null中。
syslog-enabled
默認配置：syslog-enabled no，想讓日志記錄到系統日志，設置syslog-enabled成yes
syslog-ident
默認配置：syslog-ident redis，指定syslog的身份
syslog-facility
默認配置：syslog-facility local0，指定syslog工具（facility）,一定要是USER或者在LOCAL0 - LOCAL7之間
databases
默認配置：databases 16，設置數據庫的數量。默認的數據庫號是DB 0
always-show-logo
默認配置：always-show-logo yes，Redis會在啟動的時候，如果標準輸出日志是TTY，則會在開始記錄標準輸出日志的時候展示一個ASCII字符組成的Redis Logo，也就是說，通常只在交互的會話中會展示該Logo
持久化配置配置 RDB
save
默認配置：save 900 1 300 10 60 10000，rdb保存數據,如果時間秒數seconds和寫的次數都配置了，那么一旦達到了配置條件Redis會將DB保存到硬盤
以默認配置舉例，達到了以下條件會觸發(fā)寫磁盤：
900秒內（15分鐘）且數據庫中至少有1個key被改變。
300秒內（5分鐘）且數據庫中至少有10個key被改變。
60秒內（1分鐘）且數據庫中只有一個10000個key被改變。
可以通過添加一個帶空串的save指令來讓配置的save選擇失效，比如：save ""
stop-writes-on-bgsave-error
默認配置：stop-writes-on-bgsave-error yes，在開啟了RDB快照后，如果最近的一次RDB快照在后臺生成失敗的話，Redis默認會拒絕所有的寫請求。這么做的目的是為了讓用戶注意到后臺持久化可能出現了問題。否則用戶可能一直無法注意到問題，進而可能導致災難級別的事情發(fā)生。如果bgsave正常，Redis會自動的繼續(xù)處理寫請求。如果已經為Redis實例和持久化配置了合適的監(jiān)控手段，且希望Redis在非理想情況下（比如硬盤問題，權限問題等等）仍繼續(xù)提供服務，可以將此項配置為no
rdbcompression
默認配置：rdbcompression yes，想要在生成rdb文件的時候使用LZF壓縮String對象，將該配置保持默認為yes幾乎不會出現意外狀況，可以將該配置設置為no來節(jié)省CPU開銷，但是那些原本可以被壓縮的key和value會讓數據集更大
dbchecksum
默認配置：rdbchecksum yes，從5.0版本開始RDB文件的末尾會默認放置一個CRC64的校驗碼，這會讓文件的格式更加容易檢驗驗證，代價是生成和加載RDB文件的性能會損失10%左右，你可以把該配置關閉以求更佳的性能，沒有開啟校驗碼配置的RDB文件會將校驗碼設置為0，加載該文件的程序就會跳過校驗過程
dbfilename
默認配置：dbfilename dump.rdb，配置rdb文件的名稱
dir
默認配置：dir ./，工作目錄，存儲rdb文件的目錄，數據庫會使用該配置放置rdb文件，文件的名字使用上面的dbfilename指定的文件名，AOF文件的存儲位置也會使用這個配置項，但要注意是配置一個目錄而不是文件名
AOF
appendonly
Redis默認使用異步方式轉儲數據到硬盤，但在Redis處理出現問題或者設備斷電的意外期間可能丟失相應的寫操作（取決于save配置的時間點），AOF文件是Redis提供的另外一種提供更好的持久性的持久化模式，例如如果使用默認的數據傳輸策略（根據之后提供的配置）Redis在發(fā)生意外情況下比如設備斷電，或者Redis本身的進程出現了一些問題的情況下（操作系統正常運行），Redis可以僅僅丟失1秒鐘的寫操作，AOF和RDB的持久化策略可以同時啟用，如果打開了AOF，Redis啟動時會加載AOF
常見配置： appendonly yes #開啟AOF appendfilename "appendonly.aof" #AOF 的文件名
appendfsync
默認配置：appendfsync everysec，函數fsync()會告訴操作系統立即把數據寫到磁盤上而不是等輸出緩沖區(qū)有更多的數據時才進行，有些OS會馬上把數據刷到硬盤，有些OS只保證盡快進行刷盤操作
Redis 支持三種模式：
- no：不fsync，讓操作系統來決定什么時候進行刷盤，最不會影響Server響應
- always：每寫入aof文件就進行fsync，影響Server響應，但是數據更安全
- everysec：默認模式，每秒進行fsync，最穩(wěn)健的形式，在響應速度和數據安全方面最穩(wěn)妥的選擇，選擇no，讓OS選擇寫入時機，這樣有更好的性能表現，又或者使用always，可以會讓響應變慢一些但是數據的安全性會更高，如果不確定選哪種的話，那就用everysec吧
no-appendfsync-on-rewrite
默認配置：no-appendfsync-on-rewrite no，當AOF fsync策略是always或者everysec，會啟動一個后臺進程（后臺進行保存或者AOF文件的后臺重寫），該進程會在磁盤上頻繁的I/O，在一些Linux配置下Redis的fsync() 調用可能會阻塞太久，需要注意的是目前還沒有相應的優(yōu)化策略，極端情況下在不同線程進行的fsync可能阻塞同步的write(2)調用，為了減緩上面提到的問題，可以在主線程調用BGSAVE或者BGREWRITEAOF命名避免fsync()在主線程上調用，這意味著當其他的子節(jié)點在保存的時候，Redis的持久化就和appendfsync no策略一樣，這意味著在實際中的最糟糕的場景下（在默認的Linux配置下）有可能丟失超過30s時間粒度的log，如果應用不能忍受延遲問題，將選項配置為yes，否則保持為no，這樣在持久化的角度上是最安全的選擇。
auto-aof-rewtire-percentage、auto-aof-rewrite-min-size
默認配置：auto-aof-rewtire-percentage 100 、 auto-aof-rewrite-min-size 64mb 自動重寫aof文件，Redis支持調用BGREWRITEAOF命名，并在AOF文件達到特定的百分比的時候自動重寫AOF文件，一般是這么工作的：Redis會記錄最近一次重寫后的AOF文件大小（如果啟動后沒有重寫過，則記錄啟動時的AOF文件大小），基礎的文件大小和當前的文件大小進行比較，如果當前的大小比配置的百分比大，則觸發(fā)重寫操作。同時也應該配置一個觸發(fā)重寫的最小文件大小，這么做可以避免當AOF文件達到了配置的百分比，但是AOF文件還是很小的情況觸發(fā)重寫操作，配置百分比為0意味著關閉自動重寫AOF的特性。
aof-load-truncated
默認值：aof-load-truncated yes，當AOF文件的數據加載到內存的時候，AOF文件可能在Redis啟動的時候在末尾被截斷，這可能在跑Redis進程的系統崩潰的情況下出現，特別是當一個ext4文件系統掛載的時候沒有使用data=ordered選項（但是在Redis進程自己崩潰或者中止，但是操作系統還正常運行時，這種情況就不會發(fā)生）,當Redis發(fā)現AOF在末尾被截斷的時候，Redis可以主動退出進程或者盡可能的加載更多的數據（目前的默認行為）并正常啟動，如果aof-load-truncated設置成yes，Redis加載被截斷的AOF文件，redis啟動并將相關的信息寫到log中通知用戶有這一現象發(fā)生。如果設置成no，Redis錯誤充電并拒絕啟動，當該配置設置為no的時候，就要求用戶在重啟服務前使用redis-check-aof來修復AOF文件。
注意：如果AOF文件的中間位置出現了問題，Redis仍會錯誤退出。這個配置選項只在Redis想從AOF文件中讀取更多數據但是實在沒有新的可以讀取的情況下才有作用。
aof-use-rdb-preamble
默認配置：aof-use-rdb-preamble yes，當重寫AOF文件的時候，Redis也可以在AOF文件在開頭應用RDB文件來更快的重寫和恢復。當該配置選項開啟，AOF文件的重寫組成由這兩部分組成：[RDB file][AOF tail]，Redis加載AOF文件的時候發(fā)現AOF文件里由"REDIS"字符串打頭，Redis就會加載預先的RDB文件，接著在尾部加載AOF文件。
生產常見配置
安全配置
requirepass
配置格式：requirepass password，要求客戶端先使用命令AUTH進行認證，才能處理其他命令
rename-command
配置格式：rename-command CONFIG abcdef，命令重命名，可以在環(huán)境中重命名那些比較危險的命令，比如把CONFIG命令重命名成一個不好猜的名字，這樣內部的功能還可以使用，且可以避免大部分的客戶端使用
客戶端配置
maxclients
默認配置：maxclients 10000，設置可以同時連接客戶端的最大數量，一旦達到該限制數Redis會拒絕所有的新連接并返回錯誤信息max number of clients reached
內存管理
maxmemory
配置格式：maxmemory，設置限定的最大內存使用，當內存使用達到限制Redis會根據配置的淘汰策略（見maxmemory-policy）移除鍵值對，如果根據淘汰策略，Redis不能移除鍵值對，Redis會拒絕那些申請更大內存的命令，比如SET，LPUSH等等，但是仍可以處理讀請求，比如GET等，該選項對那些使用Redis進行LRU，LFU緩存系統或者硬性限制內存很友好（使用noeviction策略），如果為實例配置了maxmemory，且該實例配置了子節(jié)點，那么已使用內存的大小就需要加上為副本配置的輸出緩沖區(qū)的大小。這樣因為網絡問題/重新同步不會一直觸發(fā)鍵的淘汰行為。相反的，副本緩沖區(qū)中充滿了對鍵的刪除或淘汰的情況可能觸發(fā)更多key被淘汰，以此類推直到庫完全被清空。簡單說就是，如果為實例配置了副本，那么建議設置一個較低的maxmemory值，這樣系統中就有更多的內存空間留給副本緩沖區(qū)（如果淘汰策略是‘noeviction’那上面說的就沒有必要）
maxmemory-policy
默認配置：maxmemory-policy noeviction，在內存使用達到maxmemory后，Redis如何選擇鍵值對進行淘汰。有以下幾種：
- volatile-lru：使用LRU算法，在設置了過期時間的key中選擇
- allkeys-lru：使用LRU算法，在所有的key中選擇
- volatile-lfu：使用LFU算法，在設置了過期時間key中選擇
- allkeys-lfu：使用LFU算法，在所有的key中選擇
- volatile-random：在設置了過期時間的key中隨機選擇
- allkeys-random：在所有key中隨機選擇
- volatile-ttl：在設置了過期時間的key中，選擇過期時間最近的key
- noeviction：不淘汰key，對任何寫操作（使用額外內存）返回錯誤
LRU 代表最近最少使用
LFU 代碼最近最不常使用
LRU，LFU和volatile-ttl均由近似的隨機算法實現
不管采用了以上的哪種策略，對于新的寫請求，如果沒有合適的key可以淘汰，Redis均會響應一個error
[post cid=“625” cover=“https://resource.if010.com/redis_maxmemory_policy_banner.jpg” size=“”/]
maxmemory-samples
默認配置：maxmemory-samples 5，LRU、LFU 以及最小TTL的實現都不是精確的而是比較粗略的近似算法（為了節(jié)省內存），為了速度或者精確度，可以進行相應的配置。默認Redis會檢查5個key，在其中選擇最近最少使用的，也可以直接在下面的配置項中配置 Redis 選擇的樣本數量,默認配置的值5，已經可以有一個很完美的結果,10的話可能會讓選擇策略更像真正意義上的LRU算法，但是需要更多CPU資源，3的話會更快，但是不夠精確
replica-ignore-maxmemory
默認配置：replica-ignore-maxmemory yes，從Redis 5.0之后，副本默認會忽略為其配置的maxmemory選項（除非因為故障轉移（failover）或者選擇將其晉升為主節(jié)點），也就是說key的淘汰只會由主節(jié)點執(zhí)行，副本對應的是主節(jié)點發(fā)送對應的刪除命令給副本作為key的淘汰方式，這個行為模式保證了主副節(jié)點的一致性，但是如果副本是可寫的或者你想要你的副本有不同的內存配置，而且你也很確認到達副本的寫操作能保證冪等性（idempotenet），那你可以修改這個默認值（但是最好保證你理解了這么做的原因）
提示：因為副本默認沒有maxmemory和淘汰策略，副本實際的內存占用可能比maxmemeory配置的值大（可能因為副本緩沖區(qū)，或者某些數據結構占用了額外的內存等等原因）。所以確保對副本有合適的監(jiān)控手段，保證在主節(jié)點達到配置的maxmemory設置之前，副本有足夠的內存保證不會出現真正的out-of-memory條件
主從配置
replicaof
配置格式：replicaof masterip masterport，主從復制，使用replicaof來讓一個Redis實例復制另一個Redis實例，Redis復制是異步進行的，但是可以通過配置讓Redis主節(jié)點拒絕寫請求：配置會給定一個值，主節(jié)點至少需要和大于該值的從節(jié)點個數成功連接，如果 Redis 從節(jié)點和主節(jié)點意外斷連了很少的一段時間，從節(jié)點可以向主節(jié)點進行增量復制，復制會自動進行且不需要人為介入
masterauth
配置格式：masterauth master-password，如果主節(jié)點配置了密碼（使用了"requirepass"配置項），從節(jié)點需要進行密碼認證才能進行復制同步的過程，否則主節(jié)點會直接拒絕從節(jié)點的復制請求
replica-serve-stale-data
默認配置：replica-serve-stale-data yes，當復制過程與主節(jié)點失去連接，或者當復制正在進行時，復制可以有兩種行為模式：
- 如果replica-serve-stale-data設置為’yes’（默認設置），從節(jié)點仍可以處理客戶端請求，但該從節(jié)點的數據很可能和主節(jié)點不同步，如果這是與主節(jié)點進行的第一次同步，從節(jié)點的數據也可能是空數據集
- 如果replica-serve-stale-data設置成’no’，從節(jié)點會對除了INFO、replicaOF、AUTH、PING、SHUTDOWN、REPLCONF、ROLE、CONFIG、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、PUBLISH、PUBSUB、COMMAND、POST、HOST：and LATENCY這些命令之外的請求均返回"SYNC with master in process"
replica-read-only
默認配置：replica-read-only yes，可以配置從節(jié)點是否可以處理寫請求。針對從節(jié)點開啟寫權限來存儲時效低的（ephemeral）數據可能是一種有效的方式（因為寫入到從節(jié)點的數據很可能隨著重新同步而被刪除），但是開啟該配置也會導致一些問題。從Redis 2.6開始從節(jié)點默認是僅可讀的
repl-diskless-sync
默認配置：repl-diskless-sync no，同步復制策略：硬盤或者套接字（不使用硬盤的復制策略目前還在實驗階段）新建立連接和重連的副本不會根據數據情況進行恢復傳輸，只會進行全量復制，主節(jié)點會傳輸在從節(jié)點之間傳輸RDB文件
傳輸行為有兩種方式：
硬盤備份：Redis主節(jié)點創(chuàng)建一個子進程來向硬盤寫RDB文件，之后由父進程持續(xù)的文件傳給副本
不使用硬盤：Redis主節(jié)點建立一個進程直接向副本的網絡套接字寫RDB文件，不涉及到硬盤
對于方式1，在生成RDB文件時，多個副本會進行入隊并在當前子進程完成RDB文件時立即為副本進行RDB傳輸，而對于方式2，一旦傳輸開始，新來的副本傳輸請求會入隊且只在當前的傳輸斷開后才建立新的傳輸連接，如果使用方式2，主節(jié)點會等待一段時間，根據具體的配置，等待是為了可以在開始傳輸前可以有期望的副本同步請求到達，這樣可以使用并行傳輸提高效率，對于配置是比較慢的硬盤，而網絡很快（帶寬大）的情況下，使用方式2進行副本同步會更適合
repl-diskless-sync-delay
默認配置：repl-diskless-sync-delay 5，如果diskless sync是開啟的話，就需要配置一個延遲的秒數，這樣可以服務更多通過socket傳輸RDB文件的副本，這個配置很重要，因為一旦傳輸開始，就不能為新來的副本傳輸服務，只能入隊等待下一次RDB傳輸，所以該配置一個延遲的值就是為了讓更多的副本請求到達，延遲配置的單位是秒，默認是 5 秒，不想要該延遲的話可以配置為 0 秒，傳輸就會立即開始
repl-ping-replica-period
默認配置：repl-ping-replica-period 10，副本會根據配置好的時間間隔（interval）向主節(jié)點發(fā)送PING命令，可以通過repl_ping_replica_period配置修改時間間隔，默認為10秒
repl-timeout
默認配置：repl-timeout 60，配置副本進行超時處理，在副本的角度，在同步過程中批量進行I/O傳輸，從副本s的角度，主節(jié)點超時了，從主節(jié)點的角度，副本超時了，需要重視的一點是確保該選項的配置比repl-ping-replica-period配置的值更高，否則每次主從之間的網絡比較擁擠時就容易被判定為超時
repl-disable-tcp-nodelay
默認配置：repl-disable-tcp-nodelay no，同步過后在副本套接字上關閉TCP_NODELAY，如果選擇了’yes’，Redis會使用很小的TCP包，占用很低的帶寬來想副本發(fā)送數據，但是這么做到達副本的數據會有一些延遲，使用默認的配置值且是Linux內核該延遲最多可能40毫秒，如果選擇’no’，副本的數據延遲會更低但是占用的帶寬會更多一些，默認會為了低延遲進行優(yōu)化，但是在比較擁擠網絡情況下或者是主節(jié)點和副本之間的網絡情況比較復雜，比如中間有很多路由跳轉的情況下，把選項設置為’yes’應該會比較適合
repl-backlog-size
默認配置：repl-backlog-size 1mb，配置副本的緩沖區(qū)（backlog）大小，該緩沖區(qū)用來在副本斷開連接后暫存副本數據，這樣做是因為副本重新連接后，不一定要重新進行全量復制，很多時候增量復制同步（僅同步斷連期間副本可能丟失的數據）完全足夠了，配置的緩沖區(qū)越大，副本可以承受的斷連時間可以更長，至少有一個副本連接時緩沖區(qū)才會進行分配
repl-backlog-ttl
默認配置：repl-backlog-ttl 3600，主節(jié)點如果一段時間沒有副本連接，上面提到的緩沖區(qū)會被釋放，可以通過配置一個指定的時間來釋放緩沖區(qū)，如果主節(jié)點在這個時間內還沒有與新的副本建立連接，需要注意的是副本不會因為超時釋放緩沖區(qū)，因為副本可能會被晉升（promot）為主節(jié)點，需要保持對其他副本進行增量復制的能力：因此他們總是積累緩沖區(qū)，配置為’0’意味著不釋放緩沖區(qū)
replica-priority
默認配置：replica-priority 100，副本的優(yōu)先級是一個整型數字，可以由Redis的INFO命令顯示，優(yōu)先級的作用在于當主節(jié)點無法提供服務后，Redis哨兵會使用到優(yōu)先級進行選舉副本，晉升為主節(jié)點，值越低，代表該副本晉升成為主節(jié)點的優(yōu)先級越高，比如說有三個副本，優(yōu)先級的值分別為10、100、25，Redis哨兵會選擇最低的那個，即優(yōu)先級配置為10的那個，但是，一個特殊的配置值’0’，意味著該副本不可能充當主節(jié)點的角色，故優(yōu)先級配置為0的副本永遠不會被Redis哨兵選擇晉升。默認的優(yōu)先級配置是100
min-replicas-to-write 、 min-replicas-max-lag
主節(jié)點可以根據目前連接的延遲慢于M秒的副本數量，選擇是否拒絕寫請求，數量N的副本需要是"online"的狀態(tài)，延遲的秒數（The lag（落后） in seconds）M，計算方式是根據上一次副本發(fā)送ping命令到主節(jié)點的時間計算，通常每秒都會發(fā)送ping命令，這個選項不保證N個副本會接受寫請求，但是如果沒有足夠的副本可用，則會限制那些丟失寫請求的暴露窗口至特定的秒數，比如要求至少有三個延遲小等于10秒的副本，可以這么配置：
# 配置設置為 0 會關閉該功能。 # 默認的 min-replicas-to-write 被設置為 0（功能關閉） # min-replicas-max-lag 設置為 10. min-replicas-to-write 3 min-replicas-max-lag 10
replica-announce-ip 、 replica-announce-port
主節(jié)點應該有多種方式來列舉出依附與它的副本的信息（ip和port），比如"INFO replication"就可以提供這些信息，它也會被其他的功能使用，比如Redis哨兵就會使用該命令列舉副本實例，還有一種方式是在主節(jié)點運行"ROLE"命令來獲取這些信息
副本獲取監(jiān)聽的IP和地址分別通過以下的方式：
- IP：IP地址在副本和主節(jié)點建立的socket連接中自動被檢測到
- Port：端口信息會在副本進行復制的TCP握手中交流傳遞，端口也是副本用來監(jiān)聽連接的一部分
如果使用了端口轉發(fā)或者NAT（Network Address Translation），實際連接到副本很可能通過的是不同的IP和端口對。下面的兩個配置選項用來讓副本上報特定的IP和端口集合給它連接的主節(jié)點，之后主節(jié)點使用"INFO"或者"ROLE"命令都可以輸出這些上報的值
# 如果只想上報ip或端口其中一個，就沒有必要兩個都使用 replica-announce-ip 1.1.1.1 replica-announce-port 6379
集群配置
cluster-enabled
默認配置：cluster-enabled yes，是否打開集群模式
cluster-config-file
默認配置：cluster-config-file nodes-6379.conf，設定節(jié)點配置文件名
cluster-node-timeout
默認配置：cluster-node-timeout 15000，設定節(jié)點失聯時間，超過該時間（毫秒），集群自動進行主從切換
cluster-require-full-coverage
默認配置：cluster-require-full-coverage yes，如果某一段插槽的主從都掛掉，而cluster-require-full-coverage為yes，那么 ，整個集群都掛掉，反之，cluster-require-full-coverage配置為no，那么，該插槽數據全都不能使用，也無法存儲
其他配置
CLUSTER DOCKER/NAT support
在某些部署情況中，Redis集群節(jié)點可能會出現地址發(fā)現失敗，原因是地址是NAT-ted或者端口轉發(fā)（一個典型的場景就是 Docker 或者其他容器），為了讓 Redis 集群在這種環(huán)境下正常工作，就需要個靜態(tài)的配置文件來讓集群節(jié)點知曉他們的公共地址，下面選項就有這個作用：
# 如果只想上報ip或端口其中一個，就沒有必要兩個都使用 replica-announce-ip 1.1.1.1 replica-announce-port 6379
SLOW LOG（慢日志）
默認配置：slowlog-log-slower-than 10000 、slowlog-max-len 128，Redis的慢日志用來記錄那些執(zhí)行了超過特定時間的查詢行為。這里的執(zhí)行時間不包括I/O操作，比如和客戶端的通信，發(fā)送回復的時間等等，而應該只是執(zhí)行了這個命令本身需要的時間（就是說執(zhí)行這個命令期間，線程會阻塞且不會同時響應其他的請求），慢日志有兩個屬性可以配置：一個用來告訴Redis執(zhí)行時間的定義，什么樣的執(zhí)行時間才要被記錄，另一個用來配置慢日志的長度，記錄一個新的命令，隊列中的最舊的命令會被移除，要注意的是配置的時間單位為微秒，所以1000000相當于1秒，如果配置的是負值，慢日志則不起作用，如果是0的話，慢日志則會記錄每個命令，長度的配置沒有任何限制，但是主要內存的消耗，可以使用慢日志的SLOWLOG RESET來回收內存
LATENCY MONITOR（延遲監(jiān)控）
默認配置：latency-monitor-threshold 0，Redis的延遲監(jiān)控系統會在Redis運行期間以不同的操作對象為樣本，收集和Redis實例相關的延遲行為，用戶可以通過LETENCY命令，打印相關的圖形信息和獲取相關的報告，延遲監(jiān)控系統只會收集那些執(zhí)行時間超過了我們通過latency-monitor-threshold配置的值的操作，當latency-monitor-threshold的值設置為0的時候，延遲監(jiān)控系統就會關閉，默認情況下延遲監(jiān)控是關閉的，因為大多數情況下可能沒有延遲相關的問題，而且收集數據對性能表現是有影響的，雖然影響很小，但是在系統高負載運行情況下還是不能忽視的，延遲監(jiān)控系統可以在運行期間使用CONFIG SET latency-monitor-threshold milliseconds開啟
LAZY FREEING（懶釋放）
Redis有兩個可以刪除key的原語（primitive），其中一種是調用DEL，阻塞地刪除對象。也就是說Redis Server需要通過同步的方式確認回收了所有和剛才刪除的key相關的內存后，才能處理接下來的命令。如果要刪除的key很小，執(zhí)行DEL命令的時間也很短，和其他時間復雜度為O(1)或O(log_N)的命令差不多。但是，如果要刪除的key涉及到一個存儲著百萬級別元素的集合，Redis Server就可能因此阻塞一段時間（甚至到秒的級別）
由于同步的處理方式可能帶來的問題，Redis提供了非阻塞的刪除原語比如UNLINK以及異步的選項比如FLUSHALL和FLUSHDB命名，為的就是在后臺回收內存，這些命名會在固定時間執(zhí)行（in constant time），另外的線程會在后臺以盡可能快的速度釋放這些對象
DEL、UNLINK和帶有ASYNC選項的FLUSHALL和FLUSHDB命名都可以由用戶控制，這取決于應用層面是否理解且合適的使用相應的命令來達到目的，但是還是有一些情況要注意，Redis有時會因為其他操作的副作用導致觸發(fā)key 的刪除或者刷新整個數據庫，特別是在用戶調用了對象刪除的以下場景：
- 在淘汰策略下，因為配置了maxmemory和maxmemory policy，為了在不超過配置的內存限制下騰出空間給新來的數據
- 因為過期時間的配置，當一個key配置了expire時間且時間到了，那它必須從內存中移除。命名在已經存在的key上進行數據的存儲操作的副作用。比如RENAME命名在替換的時候需要刪除原本的key的內容。類似的帶有STORE選項的SUNIONSTORE或者SORT命名可能會刪除已存在的key。SET命令本身為了用新的值替換，會將要操作的key的舊值先刪除掉。在REPLICATION期間，當副本執(zhí)行了全量同步復制，副本的整個數據庫會被清空，然后加載傳輸來的RDB文件。
上面的場景在默認情況下都是以阻塞的方式刪除對象，比如調用DEL的時候。你在本配置項中為每個場景進行配置，這樣就可以像 UNLINK 被調用時以非阻塞的方式釋放內存
lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no lazyfree-lazy-flush no
附錄：關于哨兵的常規(guī)命令
常用命令
PING
返回 PONG。
SENTINEL masters
列出所有被監(jiān)視的主服務器，以及這些主服務器的當前狀態(tài)。
SENTINEL slaves
列出給定主服務器的所有從服務器，以及這些從服務器的當前狀態(tài)。
SENTINEL get-master-addr-by-name
返回給定名字的主服務器的 IP 地址和端口號。 如果這個主服務器正在執(zhí)行故障轉移操作， 或者針對這個主服務器的故障轉移操作已經完成， 那么這個命令返回新的主服務器的 IP 地址和端口號。
SENTINEL reset
重置所有名字和給定模式 pattern 相匹配的主服務器。 pattern 參數是一個 Glob 風格的模式。 重置操作清除主服務器目前的所有狀態(tài)， 包括正在執(zhí)行中的故障轉移， 并移除目前已經發(fā)現和關聯的， 主服務器的所有從服務器和 Sentinel 。
SENTINEL failover
當主服務器失效時， 在不詢問其他 Sentinel 意見的情況下， 強制開始一次自動故障遷移 （不過發(fā)起故障轉移的 Sentinel 會向其他 Sentinel 發(fā)送一個新的配置，其他 Sentinel 會根據這個配置進行相應的更新）。
ACL（>=6.2）
此命令管理Sentinel訪問控制列表。有關更多信息，請參閱ACL文檔頁面和Sentinel訪問控制列表驗證。
AUTH（>=5.0.1）
對客戶端連接進行身份驗證。有關更多信息，請參閱AUTH命令和配置帶有身份驗證的Sentinel實例部分。
CLIENT
此命令管理客戶端連接。有關詳細信息，請參閱其子命令頁面。
COMMAND（>=6.2）
此命令返回有關命令的信息。有關詳細信息，請參閱COMMAND命令及其各種子命令。
HELLO（>=6）
切換連接的協議。有關詳細信息，請參閱HELLO命令。
INFO
返回有關Sentinel服務器的信息和統計信息。有關更多信息，請參閱INFO命令。
ROLE
此命令返回字符串“sentinel”和受監(jiān)控主機的列表。
SHUTDOWN
關閉Sentinel實例。
其他命令
SENTINEL CONFIG GET＜name＞（>=6.2）
獲取全局SENTINEL配置參數的當前值。指定的名稱可以是通配符，類似于Redis CONFIG GET命令。
SENTINEL CONFIG SET＜name＞＜value＞（>=6.2）
設置全局SENTINEL配置參數的值。
SENTINEL CKQUORUM＜master name＞
檢查當前SENTINEL配置是否能夠達到故障轉移主機所需的仲裁，以及授權故障轉移所需的多數仲裁。該命令應在監(jiān)控系統中使用，以檢查Sentinel部署是否正常。
SENTINEL FLUSHCONFIG
強制SENTINEL在磁盤上重寫其配置，包括當前的SENTINEL狀態(tài)。通常情況下，每當狀態(tài)發(fā)生變化時，Sentinel都會重寫配置（在重新啟動時保留在磁盤上的狀態(tài)子集的上下文中）。但是，有時配置文件可能會因為操作錯誤、磁盤故障、包升級腳本或配置管理器而丟失。在這些情況下，強制Sentinel重寫配置文件的方法很方便。即使以前的配置文件完全丟失，此命令也能工作。
SENTINEL FAILOVER＜master name＞
強制進行故障切換，就好像無法訪問主機一樣，并且不要求與其他SENTINEL達成一致（但是，將發(fā)布新版本的配置，以便其他Sentinels更新其配置）。
1.不會與其他Sentinel進行協商；
2.轉移完成后會通知其他Sentinel節(jié)點（根據轉移結果進行更新）；
SENTINEL GET-MASTER-ADDR-BY-NAME＜MASTER NAME＞
返回具有該名稱的主機的ip和端口號。如果此主機的故障轉移正在進行或已成功終止，它將返回升級的復制副本的地址和端口。
SENTINEL INFO-CACHE（>=3.2）
從主控和副本返回緩存的INFO輸出。
SENTINEL IS-MASTER-DOWN-BY-ADDR
檢查ip:port指定的主機是否從當前SENTINEL的角度關閉。此命令主要用于內部使用。
為*時，Sentinel節(jié)點直接交換對主節(jié)點下線的判斷；為運行ID時，Sentinel節(jié)點希望其他Sentinel節(jié)點投票自己成為領導者Sentinel(運行ID為Sentinel的運行ID)返回值由以下3個參數構成：
返回參數說明
down_state 0：代表Redis主節(jié)點仍在線 ；1：代表Redis主節(jié)點已下線
leader_runid *：不同意做為領導者運行；Sentinel ID：該運行ID代表的Sentinel同意
leader_epoch 領導者
SENTINEL MASTER＜MASTER name＞
顯示指定主機的狀態(tài)和信息。
SENTINEL MASTERS
顯示受監(jiān)控主機及其狀態(tài)的列表。
SENTINEL MONITOR
啟動SENTINEL的監(jiān)控。
SENTINEL MYID（>=6.2）
返回SENTINEL實例的ID。
SENTINEL PENDING-SCRIPTS
此命令返回有關掛起腳本的信息。
SENTINEL REMOVE
停止哨兵的監(jiān)控。
SENTINEL REPLICAS＜master name＞（>=5.0）
顯示此master的副本列表及其狀態(tài)。老版本可以用SENTINEL SENTINELS ＜master name＞
SENTINEL SENTINELS＜master name＞
顯示此master的SENTINEL實例及其狀態(tài)的列表。
SENTINEL SET
設置SENTINEL的監(jiān)控配置。
SENTINEL SIMULATE-FAILURE（選舉后崩潰|晉升后崩潰|幫助）（>=3.2）
此命令模擬不同的SENTINEL崩潰場景。
SENTINEL RESET＜pattern＞
此命令將重置具有匹配名稱的所有主機。模式參數是glob樣式的模式。重置過程會清除主機中以前的任何狀態(tài)（包括正在進行的故障轉移），并刪除已發(fā)現并與主機關聯的每個復制副本和哨兵。
到此這篇關于Redis的四種部署方案的文章就介紹到這了,更多相關Redis部署內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
這篇文章主要介紹了使用Redis實現記錄訪問次數的三種方案,文中通過代碼示例和圖文講解的非常詳細,對大家的學習或工作有一定的幫助,需要的朋友可以參考下2024-09-09
本文主要介紹了Redis數據備份與恢復方式,包含了五種方式,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2024-07-07
這篇文章主要為大家介紹了Redis慢查詢日志及慢查詢分析詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2023-01-01
Redission實現分布式鎖lock()和tryLock()方法的區(qū)別小結
Redisson是一種基于Redis的分布式鎖框架,提供了lock()和tryLock()兩種獲取鎖的方法,本文主要介紹了Redission實現分布式鎖lock()和tryLock()方法的區(qū)別小結,具有一定的參考價值,感興趣的可以了解一下2024-07-07
這篇文章主要給大家介紹了關于Redis搭建集群之Sentinel的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2018-11-11
面對越來越多的高并發(fā)場景，限流顯示的尤為重要，限流有許多種實現的方式，Redis具有很強大的功能，本文就詳細的介紹幾種方式，感興趣的可以了解一下2021-12-12
Redis序列化設置以及jetcache連接Redis序列化的設置過程
這篇文章主要介紹了Redis序列化設置以及jetcache連接Redis序列化的設置過程,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-12-12
文章介紹了如何使用熱插拔AOP、反射、Redis自定義注解和SpringEL表達式來打造一個優(yōu)雅的Redis緩存組件,通過這種方式,可以重構和簡化緩存代碼,并提供了Redis配置和自定義注解的詳細說明,文章還包含了AOP測試的總結,并鼓勵讀者參考和支持2024-12-12
本文主要介紹了redis延時隊列的項目實踐,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2024-11-11
Redis 是一種鍵值（key-value）型的緩存型數據庫,它將數據全部以鍵值對的形式存儲在內存中,本文就來介紹一下key鍵的具體使用,感興趣的可以了解一下2024-02-02