目錄

?

一、redis概述

1.1redis是什么：

1.2redis所支持的數據類型

1.3redis性能評估：

1.4Redis與Memcache對比：

1.5Redis的優勢：

1.6 ?Memcached的優勢：

二、安裝redis

2.1下載二進制包編譯安裝

2.2配置systemd服務

?三、redis基本操作

3.1 ?redis配置文件：

3.2 ?登錄redis：

3.3 ?redis獲取幫助

3.4 ?鍵的遵循：

3.5 ?Strings的操作：

3.6 ?列表的操作：

3.7 ?認證實現方法：

3.8 ?清空數據庫：

四、redis持久化

4.1 持久化概述：

4.2 ?RDB:

4.3 ?AOF：

4.4 ?配置文件中的與RDB相關的參數：

4.5 ?配置文件中的與AOF相關的參數：

4.6 ?RDB與AOF同時啟用：

五、redis主從架構（實現讀寫分離）

5.1 ?復制的工作過程：

5.2 ?特點：

5.3 ?啟動復制功能：

5.4 ?主從相關配置：

3.6 ?使用sentinel實現主從架構高可用

6.1 ?sentinel的工作過程：

6.2 ?sentinel：

6.3 ?專用配置文件：

6.4 ?專用命令：

6.5? 修改配置文件

6.6? 啟動哨兵模式

6.7? 模擬故障

---

一、redis概述

1.1redis是什么：

redis的出現時間并不長，是NoSQL中的一種，基于鍵-值型的存儲，與memcache類似，但是memcache中只是內存的緩存，而redis不僅是內存中的緩存，還提供持久存儲，在2009年第一次發布redis。

Redis 全稱（REmote DIctionary Server）遠程字典服務器，而這個字典服務器從本質上來講，主要是提供數據結構的遠程存儲功能的，可以理解為redis是一個高級的K-V存儲，和數據結構存儲，因為redis除了能夠存儲K-V這種簡單的數據之外，還能夠存儲，列表、字典、hash表、等對應的數據結構。

在性能上redis不比memcache差，因為redis整個運行通通都是在內存中實現的，它的所有的數據集都是保存在內存中的，內存中的數據會周期性的寫入到磁盤上，以實現數據的持久功能，而這種寫磁盤并不是用于訪問，而僅是冗余功能，所以redis所有功能都在內存中完成，因為此性能也是可想而知。

redis與mamcache不同之處在于redis有一個周期性的將數據保存到磁盤上的機制，而且不只一種，有兩種機制，這也是redis持久化的一種實現，另外與mamcache有所區別的是，redis是單線程服務器，只有一個線程來響應所有的請求。

redis支持主從模式，但是redis的主從模式默認就有一個sentinel工具，從而實現主從架構的高可用，也就是說，redis能夠借助于sentinel工具來監控主從節點，當主節點發生故障時，會自己提升另外一個從節點成為新的主節點。

在redis 3.0版本發布，開始支持redis集群，從而可以實現分布式，可以將用戶的請求分散至多個不同節點。

1.2redis所支持的數據類型

支持存儲的數據類型有、String（字符串，包含整數）, List（列表）, Hash（關聯數組）, Sets（集合）, Sorted Sets（有序集合）。

1.3redis性能評估：

1、100萬較小的鍵存儲字符串，大概消耗100M內存

2、由于redis是單線程，如果服務器主機上有多個CPU，只有一個能夠使用，但并不意味著CPU會成為瓶頸，因為redis是一個比較簡單的K-V數據存儲，CPU通常不會成為瓶頸的

3、在常見的linux服務器上，500K（50萬）的并發，只需要一秒鐘處理，如果主機硬件較好的情況下，每秒鐘可以達到上百萬的并發

1.4Redis與Memcache對比：

Memcache	redis
是一個分布式的內存對象緩存系統	是可以實現持久存儲
是一個LRU的緩存	支持更多的數據類型
是多線程的	是單線程的
二者性能幾乎不相上下，實際上redis會受到硬盤持久化的影響，但是性能仍然保持在與Memcache不相上下，是非常了不起的

1.5Redis的優勢：

• 豐富的（資料形態）操作
• String（字符串，包含整數）, List（列表）, Hash（關聯數組）, Sets（集合）, Sorted Sets（有序集合）
• 內建Replication和culster（自身支持復制及集群功能）
• 支持就地更新（in-place update）操作，直接可以在內存中完成更新操作
• 支持持久化（磁盤）
• 避免雪崩效應，萬一出現雪崩效應，所有的數據都無法恢復，但redis由于有持久性的數據，可以實現恢復

1.6 ?Memcached的優勢：

• 多線程，善用多核CPU，更少的阻塞操作
• 更少的內存開銷
• 更少的內存分配壓力
• 可能有更少的內存碎片

二、安裝redis

2.1下載二進制包編譯安裝

#按需求關閉安全策略，生產環境開啟對應的端口即可。6379 26379 systemctl stop firewalld systemctl disable firewalld setenforce 0yum -y install gcc gcc-c++ makecd /opt wget -P /opt http://download.redis.io/releases/redis-5.0.9.tar.gz tar -zxvf redis-5.0.9.tar.gzcd redis-5.0.9 make && make PREFIX=/usr/local/redis install #Redis源碼包中直接提供了makefile文件 直接執行make與make install命令進行安裝cd /opt/redis-5.0.9/utils/ ./install_server.sh #回車，直到出現以下選項，手動修改為“/usr/local/redis/bin/redis-server” Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-serverln -s /usr/local/redis/bin/* /usr/local/bin/#檢查服務狀態 ss -natp | grep "redis"

2.2配置systemd服務

#編寫service文件 vim /usr/lib/systemd/system/redis.service

?內容如下：

[Unit] Description=Redis persistent key-value database After=network.target[Service] ExecStart=/usr/local/redis/bin/redis-server /etc/redis/6379.conf --supervised systemd ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID Type=notify PrivateTmp=true[Install] WantedBy=multi-user.target ln -s /usr/lib/systemd/system/redis.service /etc/systemd/system/multi-user.target.wants/redis.service #重載配置文件 systemctl daemon-reload #啟動 systemctl start redis #查看 systemctl status redis

?三、redis基本操作

3.1 ?redis配置文件：

?vim /etc/redis/6379.conf

?主要參數詳解：

daemonize no ? //表示redis并不會運行成為一個守護進程，如果需要運行成為一個守護進程，則把no，改為yes即可，如果使用服務腳本啟動，即使daemonize為no，也會運行為一個守護進程port 6379 //監聽端口：6379/tcptcp-backlog 511 //指定tcp-backlog的長度說明：任何的tcp服務都有可能使用到tcp-backlog功能，backlog是一個等待隊列，比如：redis的并發很高時，redis有可能運行不過來時，就連接本地緩存等隊列都滿了以后，就會使用額外的存儲地方，把新來的請求暫存下來，而這個位置則稱為backlogbind 127.0.0.1 //監聽的地址，默認監聽在127.0.0.1地址上，可以指定為0.0.0.0地址，或某個特定的地址，或可以指定多個，使用空格分隔即可# unixsocket /tmp/redis.sock //指定使用sock文件通信及sock文件位置，如果服務端和客戶都在同一臺主機上，建議打開此項，基于sock方式通信可以直接在內存中交換，數據不用再經過TCP/TP協議棧進行封裝、拆封# unixsocketperm 700 //定義sock文件的訪問權限timeout 0 //表示當客戶端連接成功后，空閑（非活躍、或沒有任何數據交互）多長時間則連接超時，0表示不啟用此功能tcp-keepalive 0 //定義是否啟用tcp-keepalive功能loglevel notice //定義日志級別logfile /var/log/redis_6379.log //定義日志文件databases 16 //定義redis默認有多少個databases，但是在分布式中，只能使用一個#### SNAPSHOTTING ?#### //定義RDB的持久化相關save <seconds> <changes> //使用save指令，并指定每隔多少秒，如果發生多大變化，進行存儲示例：save 900 1 //表示在900秒（15分鐘內），如果至少有1個鍵發生改變，則做一次快照（持久化）save 300 10 //表示在300秒（5分鐘內），如果至少有10個鍵發生改變，則做一次快照（持久化）save 60 10000 //表示在60秒（1分鐘內），如果至少有10000個鍵發生改變，則做一次快照（持久化）save "" //如果redis中的數據不需做持久化，只是作為緩存，則可以使用此方式關閉持久化功能######## REPLICATION ####### //配置主從相關# replicaof <masterip> <masterport> //此項不啟用時，則為主，如果啟動則為從，但是需要指明主服務器的IP，端口# masterauth <master-password> //如果主服務設置了密碼認證，那么從的則需要啟用此項并指明主的認證密碼replica-read-only yes //定義從服務對主服務是否為只讀（僅復制）##### LIMITS ##### //定義與連接和資源限制相關的配置# maxclients 10000 //定義最大連接限制（并發數）# maxmemory <bytes> //定義使用主機上的最大內存，默認此項關閉，表示最大將使用主機上的最大可用內存###### APPEND ONLY MODE ####### //定義AOF的持久化功能相關配置，一旦有某一個鍵發生變化，將修改鍵的命令附加到命令列表的文件中，類似于MySQL二進制日志appendonly no //定義是否開啟此功能，no表示關閉，yes表示開啟說明：RDB和AOF兩種持久功能可以同時啟用，兩者不影響

修改配置文件中以下內容

#修改監聽地址為 0.0.0.0 bind 0.0.0.0 #開啟守護進程 daemonize yes #指定日志文件目錄 logfile /var/1og/redis_6379.1og #指定工作目錄 dir /var/lib/redis/6379 #開啟 AOF 持久化功能 appendonly yes #配置密碼 requirepass "tj123456" masterauth "tj123456"

3.2 ?登錄redis：

?redis-cli

選項：

• -h <hostname> 指定主機IP
• -p <port> 指定端口socket文件進行通信
• -s <socket> ????指定socket文件，如果客戶端和服務端都在同一臺主機，可以指定socket文件進行通信
• -a <password> ??指定認證密碼
• -r <repeat> ????連接成功后指定運行的命令N次
• -i <interval> ??連接成功后每個命令執行完成等待時間，使用-i選項指定
• -n <db>

redis-cli -h 192.168.1.63 //連接redis，默認不啟用密碼認證 或： redis-cli //使用redis-cli直接連接，默認連接是127.0.0.1 IP 127.0.0.1:6379> exit //退出連接

3.3 ?redis獲取幫助

127.0.0.1:6379> help //獲取使用幫助

說明：redis的help命令非常強大，因為redis支持眾多的數據結構，每一種數據結構當中都支持N種操作，因此需要使用 help @group方式來獲取某一種數據結構所支持的操作

例：獲取字符串組所支持有那些操作

127.0.0.1:6379> help @string

127.0.0.1:6379> help APPEND //獲取單個命令的使用方法

APPEND key value //命令方法

summary: Append a value to a key

since: 2.0.0 //說明此命令在哪個版本中引入的

group: string //該命令所屬哪一個組

查看都有哪些組：

127.0.0.1:6379> help TAB鍵，每敲一次輪換一個，帶有@則為一個組，不帶@則為命令使用

切換庫（名稱空間）：

127.0.0.1:6379> select 1 //表示切換到1號庫中，默認為0號庫，共16個，0-15

OK

127.0.0.1:6379[1]>

3.4 ?鍵的遵循：

可以使用ASCII字符-296

鍵的長度不要過長，鍵的長度越長則消耗的空間越多

在同一個庫中（名稱空間），鍵的名稱不得重復，如果復制鍵的名稱，實際上是修改鍵中的值

在不同的庫中（名稱空間），鍵的同一個名稱可以重復

鍵可以實現自動過期

3.5 ?Strings的操作：

127.0.0.1:6379> help setSET key value [EX seconds] [PX milliseconds] [NX|XX] //命令 鍵 值 [EX 過期時間，單位秒]summary: Set the string value of a keysince: 1.0.0group: stringNX：如果一個鍵不存在，才創建并設定值，否則不允許設定XX：如果一個鍵存在則設置建的值，如果不存在則不創建并不設置其值例：127.0.0.1:6379> set test lyyOK127.0.0.1:6379> set test aaa NX(nil) //反回提示一個沒能執行的操作127.0.0.1:6379> get test"lyy"127.0.0.1:6379> set foo abc XX(nil)定義一個鍵并設置過期時間為60秒127.0.0.1:6379> set fda abc EX 60OK獲取鍵中的值：127.0.0.1:6379> help getGET keysummary: Get the value of a keysince: 1.0.0group: string例：127.0.0.1:6379> get test"lyy"添加鍵中的值（在原有鍵中附加值的內容）：127.0.0.1:6379> append test fda(integer) 7127.0.0.1:6379> get test"lyyfda"獲取指定鍵中的值的字符串的長度：127.0.0.1:6379> strlen test(integer) 7定義整數值：127.0.0.1:6379> set fda 0 //整數值為0OK增加鍵中的整數值：127.0.0.1:6379> incr fda(integer) 1127.0.0.1:6379> incr fda(integer) 2127.0.0.1:6379> incr fda(integer) 3127.0.0.1:6379> incr fda(integer) 4127.0.0.1:6379> get fda"4"注：incr命令只能對整數使用刪除鍵：127.0.0.1:6379> del fda(integer) 1127.0.0.1:6379> get fda(nil)

3.6 ?列表的操作：

鍵指向一個列表，而列表可以理解為是一個字符串的容器，列表是有眾多元素組成的集合，可以在鍵所指向的列表中附加一個值

LPUSH //在鍵所指向的列表前面插入一個值（左邊加入）

RPUSH //在鍵所指向的列表后面附加一個值（右邊加入）

LPOP //在鍵所指向的列表前面彈出一個值（左邊彈出）

RPOP //在鍵所指向的列表后面彈出一個值（右邊彈出）

LINDEX //根據索引獲取值，指明索引位置進行獲取對應的值

LSET //用于修改指定索引的值為指定的值

例：127.0.0.1:6379> help @listLSET key index valuesummary: Set the value of an element in a list by its indexsince: 1.0.0指定一個新的列表，在幫助中并沒產明哪個命令用于創建一個新的列表，實際上創建一個新的列表使用LPUSH或RPUSH都可以例：127.0.0.1:6379> lpush ll test //ll為列表名稱，test為值（索引）(integer) 1獲取列表中的值：需要指明索引位置進行獲取對應的值127.0.0.1:6379> lindex ll 0 //第一個索引則為0"test"在原有的列表中的左側加入一個值：127.0.0.1:6379> lpush ll fda(integer) 2127.0.0.1:6379> lindex ll 0"fda"127.0.0.1:6379> lindex ll 1"test"在原有的列表中的右側加入一個值127.0.0.1:6379> rpush ll lyy(integer) 3127.0.0.1:6379> lindex ll 2"lyy"127.0.0.1:6379> lindex ll 1"test"127.0.0.1:6379> lindex ll 0"fda"修改一個已有的列表中的值：127.0.0.1:6379> lset ll 0 abcOK127.0.0.1:6379> lindex ll 0"abc"查看列表中的值的數量127.0.0.1:6379> llen ll(integer) 3在已有的列表中右側彈出（刪除）一個值127.0.0.1:6379> rpop ll"lyy"在已有的列表中左側彈出（刪除）一個值127.0.0.1:6379> lpop ll"abc"127.0.0.1:6379> lpop ll"test"127.0.0.1:6379> lpop ll(nil)

3.7 ?認證實現方法：

(1) /etc/redis/6379.conf

# requirepass foobared //啟用此項，并指定密碼即可

requirepass PASSWORD

例：# vim /etc/redis/6379.conf requirepass 123456# redis-cli127.0.0.1:6379> select 1(error) NOAUTH Authentication required.127.0.0.1:6379> auth 123456OK127.0.0.1:6379> select 1OK127.0.0.1:6379[1]>

3.8 ?清空數據庫：

FLUSHDB：刪除當前選擇的數據庫所有key

FLUSHALL：清空所有庫

127.0.0.1:6379> flushdbOK

四、redis持久化

4.1 持久化概述：

默認情況下，redis工作時所有數據集都是存儲于內存中的，不論是否有磁盤上的持久化數據，都是工作于內存當中，redis本身就是一個內存的數據庫，把所有數據庫相關的存儲都存儲在內存中，如果redis崩潰或斷電導致所有數據丟失，所以redis提供了持久化功能來保證數據的可靠性，redis持久化有兩種實現，RDB和AOF

4.2 ?RDB:

存儲為二進制格式的數據文件，默認啟動的持久化機制；按事先定制的策略，周期性地將數據保存至磁盤，使用save命令即可設定周期和策略即可；數據文件默認為dump.rdb，客戶端連接服務器以后可以用去使用save命令進行保存數據至磁盤

保存快照有兩種方式：

1、客戶端也可顯式使用SAVE或BGSAVE命令啟動快照保存機制；

2、借助于配置文件所定義的save和策略進行保存：

SAVE: 是同步保存，在客戶端使用save保存快照時，是在redis主線程中保存快照；因為redis的主線程是用于處理請求的，所以此時會阻塞所有客戶端請求，每次的保存快照都是把內存中的數據完整的保存一份，并非是增量的，如果內存中的數據比較大，而還有大量的寫操作請求時，此方式會引起大量的I/O，會導致redis性能下降

BGSAVE：異步方式，將立即返回結果，但自動在后臺保持操作，所以BGSAVE命令啟動以后，前臺不會被占用，客戶端的請求是不會被阻塞（主進程不會被阻塞）

如果是在配置文件中定義的save，那么redis在持久化的時候，則會開啟另外的進程去處理，不會阻塞redis的主進程

redis的RDB持久化不足之處則是，一旦數據出現問題，由于RDB的數據不是最新的，所以基于RDB恢復過來的數據一定會有一部分數據丟失，也就是RDB保存之后的修改的數據會丟失

4.3 ?AOF：

Append Only File，有著更好的持久化能力的解決方案，AOF類似于MySQL的二進制日志，記錄每一次redis的寫操作命令，以順序IO方式附加在指定文件的尾部，是使用追加方式實現的，這也叫做一種附加日志類型的持久化機制，由于每一次的操作都記錄，則會隨著時間長而增大文件的容量，并且有些記錄的命令是多余的，AOF不像RDB，RDB是保存數據集的本身

但是redis進程能夠自動的去掃描這個對應的AOF文件，把其中一些冗余的操作給合并一個，以實現將來一次性把數據恢復，也就是說redis能夠合并重寫AOF的持久化文件，由BGREWRITEAOF命令來實現，BGREWRITEAOF命令是工作于后臺的重寫AOF文件的命令，重寫后redis將會以快照的方式將內存中的數據以命令的方式保存在臨時文件中，最后替換原來的文件，重寫AOF文件方式，并沒有讀取舊AOF文件，而是直接將當前內存中的所有數據直接生成一個類似于MySQL二進日志命令一樣的操作，例：set test 0 ，incr test ?... 1000 ，則會替換為set test 1000 些命令放到重寫文件中，如果此過程完成，那么原有的AOF將被刪除

BGREWRITEAOF：AOF文件重寫；

不會讀取正在使用AOF文件，而通過將內存中的數據，為內存中的所有數據生成一個命令集，以命令的方式保存到臨時文件中，完成之后替換原來的AOF文件；所以AOF文件是通過重寫將其變小

4.4 ?配置文件中的與RDB相關的參數：

stop-writes-on-bgsave-error yes //在進行快照備份時，一旦發生錯誤的話是否停止寫操作

rdbcompression yes //RDB文件是否使用壓縮，壓縮會消耗CPU

rdbchecksum yes //是否對RDB文件做校驗碼檢測，此項定義在redis啟動時加載RDB文件是否對文件檢查校驗碼，在redis生成RDB文件是會生成校驗信息，在redis再次啟動或裝載RDB文件時，是否檢測校驗信息，如果檢測的情況下會消耗時間，會導致redis啟動時慢，但是能夠判斷RDB文件是否產生錯誤

dbfilename dump.rdb //定義RDB文件的名稱

dir /var/lib/redis //定義RDB文件存放的目錄路徑

127.0.0.1:6379> config get dir

1) "dir"

2) "/var/lib/redis/6379"

4.5 ?配置文件中的與AOF相關的參數：

appendonly no //定義是否開啟AOF功能，默認為關閉

appendfilename "appendonly.aof" //定義AOF文件

appendfsync always //表示每次收到寫命令時，立即寫到磁盤上的AOF文件，雖然是最好的持久化功能，但是每次有寫命令時都會有磁盤的I/O操作，容易影響redis的性能

appendfsync everysec //表示每秒鐘寫一次，不管每秒鐘收到多少個寫請求都往磁盤中的AOF文件中寫一次

appendfsync no //表示append功能不會觸發寫操作，所有的寫操作都是提交給OS，由OS自行決定是如何寫的

no-appendfsync-on-rewrite no //當此項為yes時，表示在重寫時，對于新的寫操作不做同步，而暫存在內存中

auto-aof-rewrite-percentage 100 //表示當前AOF文件的大小是上次重寫AOF文件的二倍時，則自動日志重寫過程

auto-aof-rewrite-min-size 64mb //定義AOF文件重寫過程的條件，最少為定義大小則觸發重寫過程

注意：持久本身不能取代備份；還應該制定備份策略，對redis數據庫定期進行備份；

4.6 ?RDB與AOF同時啟用：

(1) BGSAVE和BGREWRITEAOF不會同時執行，為了避免對磁盤的I/O影響過大，在某一時刻只允許一者執行；

如果BGSAVE在執行當中，而用戶手動執行BGREWRITEAOF時，redis會立即返回OK，但是redis不會同時執行，會等BGSAVE執行完成，再執行BGREWRITEAOF

(2) 在Redis服務器啟動用于恢復數據時，會優先使用AOF

五、redis主從架構（實現讀寫分離）

5.1 ?復制的工作過程：

主庫會基于pingcheck方式檢查從庫是否在線，如果在線則直接同步數據文件至從服務端，從服務端也可以主動發送同步請求到主服務端，主庫如果是啟動了持久化功能時，會不斷的同步數據到磁盤上，主庫一旦收到從庫的同步請求時，主庫會將內存中的數據做快照，然后把數據文件同步給從庫，從庫得到以后是保存在本地文件中（磁盤），而后則把該文件裝載到內存中完成數據重建，鏈式復制也同步如此，因為主是不區分是真正的主，還是另外一個的從

1、啟動一slave

2、slave會向master發送同步命令，請求主庫上的數據，不論從是第一次連接，還是非第一次連接，master此時都會啟動一個后臺的子進程將數據快照保存在數據文件中，然后把數據文件發送給slave

3、slave收到數據文件 以后會保存到本地，而后把文件重載裝入內存

5.2 ?特點：

1、一個Master可以有多個Slave；

2、支持鏈式復制(一個slave也可以是其他的slave的slave)；

3、Master以非阻塞方式同步數據至slave(master可以同時處理多個slave的讀寫請求，salve端在同步數據時也可以使用非阻塞方式)；

5.3 ?啟動復制功能：

1、使用用戶端啟用：

在slave上:

> SLAVAOF MASTER_IP MASTER_PORT例：127.0.0.1:6379> replicaof 192.168.1.64 6379 //成為從庫OK

2、使用配置配置（在從庫上操作）：

# vim /etc/redis/6379.conf

# replicaof <masterip> <masterport> //修改此項如下

replicaof 192.168.1.63 6379

從庫上查看：

127.0.0.1:6379> info?replication# Replicationrole:slavemaster_host:192.168.1.63master_port:6379master_link_status:up

5.4 ?主從相關配置：

slave-serve-stale-data yes //表示當主服務器不可以用時，則無法判定數據是否過期，此時從服務器仍然接收到讀請求時，yes表示仍然響應（繼續使用過期數據）

slave-read-only yes //啟用slave時，該服務器是否為只讀

repl-diskless-sync no //是否基于diskless機制進行sync操作，一般情況下如果disk比較慢，網絡帶寬比較大時，在做復制時，此項可以改為Yes

repl-diskless-sync-delay 5 //指定在slave下同步數據到磁盤的延遲時間，默認為5秒，0表示不延遲

slave-priority 100 //指定slave優先級，如果有多個slave時，那一個slave將優先被同步

# min-slaves-to-write 3 //此項表示在主從復制模式當中，如果給主服務器配置了多個從服務器時，如果在從服務器少于3個時，那么主服務器將拒絕接收寫請求，從服務器不能少于該項的指定值，主服務器才能正常接收用戶的寫請求

# min-slaves-max-lag 10 //表示從服務器與主服務器的時差不能夠相差于10秒鐘以上，否則寫操作將拒絕進行

注意：如果master使用requirepass開啟了認證功能，從服務器要使用masterauth <PASSWORD>來連入服務請求使用此密碼進行認證；

主從節點/etc/redis/6379.conf文件添加一樣的信息

requirepass tj123456 masterauth tj123456

主從復制的問題：

例：有一主三從，如果主服務器離線，那么所有寫操作操作則無法執行，為了避免此情況發生，redis引入了sentinel（哨兵）機制

六、 使用sentinel實現主從架構高可用

6.1 ?sentinel的工作過程：

sentinel安裝在另外的主機上，sentinel主機既能監控又能提供配置功能，向sentinel指明主redis服務器即可（僅監控主服務器），sentinel可以從主服務中獲取主從架信息，并分辨從節點，sentinel可以監控當前整個主從服務器架構的工作狀態，一旦發現master離線的情況，sentinel會從多個從服務器中選擇并提升一個從節點成為主節點，當主節點被從節點取代以后，那么IP地址則發生了，客戶所連接之前的主節點IP則不無法連接，此時可以向sentinel發起查詢請求，sentinel會告知客戶端新的主節點的IP，所以sentinel是redis在主從架構中實現高可用的解決方，sentinel為了誤判和單點故障，sentinel也應該組織為集群，sentinel多個節點同時監控redis主從架構，一旦有一個sentinel節點發現redis的主節點不在線時，sentinel會與其他的sentinel節點協商其他的sentinel節點是否也為同樣發現redis的主節點不在線的情況，如果sentinel的多個點節點都發現redis的主節點都為離線的情況，那么則判定redis主節點為離線狀態，以此方式避免誤判，同樣也避免了單點故障

6.2 ?sentinel：

用于管理多個redis服務實現HA；

監控多個redis服務節點

自動故障轉移

sentinel也是一個分布式系統，可以在一個架構中運行多個sentinel進程，多個進程之間使用“流言協議”接收redis主節點是否離線，并使用“投票協議”是否實現故障轉移，選擇哪一個redis的從服務器成為主服務器

啟用sentinel：

redis-sentinel可以理解為運行有著特殊代碼的redis，redis自身也可以運行為sentinel，sentinel也依賴配置文件，用于保存sentinel不斷收集的狀態信息

程序：

redis-sentinel /path/to/file.conf

redis-server ?/path/to/file.conf --sentinel

運行sentinel的步驟：

(1) 服務器自身初始化（運行redis-server中專用于sentinel功能的代碼）；

(2) 初始化sentinel狀態，根據給定的配置文件，初始化監控的master服務器列表；

(3) 創建連向master的連接；

6.3 ?專用配置文件：

/etc/sentinel.conf

(1) # sentinel monitor <master-name> <ip> <redis-port> <quorum> //此項可以出現多次，可以監控多組redis主從架構，此項用于監控主節點 <master-name> 自定義的主節點名稱，<ip> 主節點的IP地址，<redis-port>主節點的端口號，<quorum>主節點對應的quorum法定數量，用于定義sentinel的數量，是一個大于值盡量使用奇數，如果sentinel有3個，則指定為2即可，如果有4個，不能夠指定為2，避免導致集群分裂，注意，<master-name>為集群名稱，可以自定義，如果同時監控有多組redis集群時，<master-name>不能同樣

(2) sentinel down-after-milliseconds <master-name> <milliseconds> ?//sentinel連接其他節點超時時間，單位為毫秒（默認為30秒）

sentinel parallel-syncs <master-name> <numslaves> //提升主服務器時，允許多少個從服務向新的主服務器發起同步請求

sentinel failover-timeout <master-name> <milliseconds> //故障轉移超時時間，在指定時間沒能完成則判定為失敗，單位為毫秒（默認為180秒）

6.4 ?專用命令：

• ? SENTINEL masters //列出所有監控的主服務器
• ? SENTINEL slaves <master name> //獲取指定redis集群的從節點
• ? SENTINEL get-master-addr-by-name <master name> //根據指定master的名稱獲取其IP
• ? SENTINEL reset //用于重置，包括名稱，清除服務器所有運行狀態，故障轉移、等等
• ? SENTINEL failover <master name> //手動向某一組redis集群發起執行故障轉移

6.5 修改sentinel配置文件

#復制配置文件 cp /opt/redis-5.0.9/sentinel.conf /etc/redis/sentinel.conf

修改文件中以下內容：

#關閉保護模式 protected-mode no#Redis哨兵默認的監聽端口 port 26379 daemonize yes #指定日志存放路徑 logfile "/var/log/sentinel.log" #指定數據庫存放路徑 dir "/var/lib/redis/6379" #指定哨兵節點 #2表示，至少需要 2 個哨兵節點同意，才能判定主節點故障并進行故障轉移 sentinel monitor mymaster 192.168.238.10 6379 2 #指定連接主redis密碼 sentinel auth-pass mymaster tj123456#判定服務器down掉的時間周期，默認30000毫秒 (30秒 ) sentinel down-after-milliseconds mymaster 3000 #故障節點的最大超時時間為180000 (180秒) sentinel failover-timeout mymaster 180000

scp?配置文件到其他節點。

6.6 啟動哨兵模式

先啟動主節點然后再啟動從節點

主：

/usr/local/redis/bin/redis-sentinel /etc/redis/sentinel.conf

從：

/usr/local/redis/bin/redis-sentinel /etc/redis/sentinel.conf

查看信息

/usr/local/redis/bin/redis-cli -a tj123456 -p 26379 info Sentinel

6.7 模擬故障

#關閉主節點redis ps -ef | grep redis kill -9 具體的進程號 #查看信息，多查詢幾次 redis-cli -a tj123456 -p 26379 info Sentinel

?如下圖執行結果：自動切換

由以上測試可見，主的故障離線后，sentinel重新選了其 一個從的成為了新的主節點，在原來的主節點重新上線后，仍然不會恢復為主節點

注意：

將來客戶端應連接sentinel，向sentinel發請求去尋址，并根據sentinel的反饋，進行連接新的redis主節點，這一點需要使用redis專用客戶端來實現。redis客戶端會根據sentinel返回的新節點IP進行連接

總結

以上是生活随笔為你收集整理的redis详解及哨兵模式搭建的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。