正文

redis高可用集群（redis高可用集群搭建）

發(fā)布時(shí)間：2023-04-13 14:14:41 稿源：創(chuàng)意嶺閱讀： 72

大家好！今天讓創(chuàng)意嶺的小編來(lái)大家介紹下關(guān)于redis高可用集群的問(wèn)題，以下是小編對(duì)此問(wèn)題的歸納整理，讓我們一起來(lái)看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁(yè)版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請(qǐng)撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、redis HA方案
2、Redis哨兵集群
3、linux 的環(huán)境搭建（二）--redis單機(jī)環(huán)境、生產(chǎn)環(huán)境、集群環(huán)境的搭建
4、redis常見問(wèn)題

redis高可用集群（redis高可用集群搭建）

一、redis HA方案

HA(High Available，高可用性群集)機(jī)集群系統(tǒng)簡(jiǎn)稱，是保證業(yè)務(wù)連續(xù)性的有效解決方案，一般有兩個(gè)或兩個(gè)以上的節(jié)點(diǎn)，且分為活動(dòng)節(jié)點(diǎn)及備用節(jié)點(diǎn)。通常把正在執(zhí) 行業(yè)務(wù)的稱為活動(dòng)節(jié)點(diǎn)，而作為活動(dòng)節(jié)點(diǎn)的一個(gè)備份的則稱為備用節(jié)點(diǎn)。當(dāng)活動(dòng)節(jié)點(diǎn)出現(xiàn)問(wèn)題，導(dǎo)致正在運(yùn)行的業(yè)務(wù)（任務(wù)）不能正常運(yùn)行時(shí)，備用節(jié)點(diǎn)此時(shí)就會(huì)偵測(cè)到，并立即接續(xù)活動(dòng)節(jié)點(diǎn)來(lái)執(zhí)行業(yè)務(wù)。從而實(shí)現(xiàn)業(yè)務(wù)的不中斷或短暫中斷。

Redis 一般以主/從方式部署（這里討論的應(yīng)用從實(shí)例主要用于備份，主實(shí)例提供讀寫）該方式要實(shí)現(xiàn) HA 主要有如下幾種方案：

二、Redis哨兵集群

Redis-Sentinel是redis官方推薦的高可用性解決方案，

當(dāng)用redis作master-slave的高可用時(shí)，如果master本身宕機(jī)，redis本身或者客戶端都沒有實(shí)現(xiàn)主從切換的功能。

而redis-sentinel就是一個(gè)獨(dú)立運(yùn)行的進(jìn)程，用于監(jiān)控多個(gè)master-slave集群，

自動(dòng)發(fā)現(xiàn)master宕機(jī)，進(jìn)行自動(dòng)切換slave > master

每個(gè)Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實(shí)例發(fā)送一個(gè) PING 命令

如果一個(gè)實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時(shí)間超過(guò) down-after-milliseconds 選項(xiàng)所指定的值，則這個(gè)實(shí)例會(huì)被 Sentinel 標(biāo)記為主觀下線。

如果一個(gè)Master被標(biāo)記為主觀下線，則正在監(jiān)視這個(gè)Master的所有 Sentinel 要以每秒一次的頻率確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài)。

當(dāng)有足夠數(shù)量的 Sentinel（大于等于配置文件指定的值）在指定的時(shí)間范圍內(nèi)確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài)，則Master會(huì)被標(biāo)記為客觀下線

在一般情況下，每個(gè) Sentinel 會(huì)以每 10 秒一次的頻率向它已知的所有Master，Slave發(fā)送 INFO 命令

當(dāng)Master被 Sentinel 標(biāo)記為客觀下線時(shí)，Sentinel 向下線的 Master 的所有 Slave 發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次

若沒有足夠數(shù)量的 Sentinel 同意 Master 已經(jīng)下線， Master 的客觀下線狀態(tài)就會(huì)被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回復(fù)， Master 的主觀下線狀態(tài)就會(huì)被移除。

主觀下線和客觀下線

主觀下線：Subjectively Down，簡(jiǎn)稱 SDOWN，指的是當(dāng)前 Sentinel 實(shí)例對(duì)某個(gè)redis服務(wù)器做出的下線判斷。

客觀下線：Objectively Down，簡(jiǎn)稱 ODOWN，指的是多個(gè) Sentinel 實(shí)例在對(duì)Master Server做出 SDOWN 判斷，并且通過(guò) SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下線判斷，然后開啟failover.

SDOWN適合于Master和Slave，只要一個(gè) Sentinel 發(fā)現(xiàn)Master進(jìn)入了ODOWN，這個(gè) Sentinel 就可能會(huì)被其他 Sentinel 推選出，并對(duì)下線的主服務(wù)器執(zhí)行自動(dòng)故障遷移操作。

ODOWN只適用于Master，對(duì)于Slave的 Redis 實(shí)例，Sentinel 在將它們判斷為下線前不需要進(jìn)行協(xié)商，所以Slave的 Sentinel 永遠(yuǎn)不會(huì)達(dá)到ODOWN。

Redis主從復(fù)制可將主節(jié)點(diǎn)數(shù)據(jù)同步給從節(jié)點(diǎn)，從節(jié)點(diǎn)此時(shí)有兩個(gè)作用：

但是問(wèn)題是：

那么這個(gè)問(wèn)題，redis-sentinel就可以解決了

Redis的一個(gè)進(jìn)程，但是不存儲(chǔ)數(shù)據(jù)，只是監(jiān)控redis

本實(shí)驗(yàn)是在測(cè)試環(huán)境下，因此只準(zhǔn)備一臺(tái)linux服務(wù)器用作環(huán)境??！

服務(wù)器環(huán)境，一臺(tái)即可完成操作

所有配置文件如下

總體redis配置文件如下，6379為master，6380和6381為slave

redis-6380.conf slave配置文件詳解，6381端口的配置文件，僅僅和6380端口不一樣

在主節(jié)點(diǎn)上查看主從通信關(guān)系

在從節(jié)點(diǎn)上查看主從關(guān)系（6380、6379）

此時(shí)可以在master上寫入數(shù)據(jù)，在slave上查看數(shù)據(jù)，此時(shí)主從復(fù)制配置完成

redis-sentinel-26379.conf配置文件寫入如下信息

redis-sentinel-26380.conf和redis-sentinel-26381.conf的配置僅僅差異是port(端口)的不同。

然后啟動(dòng)三個(gè)sentinel哨兵

此時(shí)查看哨兵是否成功通信

實(shí)例的思路

首先查看三個(gè)Redis的進(jìn)程狀態(tài)

第一個(gè)

第二個(gè)

第三個(gè)

直接干掉master，然后等待其他兩個(gè)節(jié)點(diǎn)是否能自動(dòng)被哨兵sentienl，切換為master節(jié)點(diǎn)

此時(shí)查看兩個(gè)slave的狀態(tài)

然后會(huì)發(fā)現(xiàn)slave節(jié)點(diǎn)成為master節(jié)點(diǎn)?。?

三、linux 的環(huán)境搭建（二）--redis單機(jī)環(huán)境、生產(chǎn)環(huán)境、集群環(huán)境的搭建

一、目錄

1、工具

2、安裝tcl

3、安裝單機(jī)版redis

4、把redis設(shè)置為daemon進(jìn)程，每次系統(tǒng)啟動(dòng)，redis進(jìn)程一起啟動(dòng)

5、安裝redis cluster

二、工具

2.1、tcl8.6.1-src.tar.gz

2.2、ruby-2.3.1.tar.gz

2.3、redis-4.1.1.gem

2.4、redis-3.2.8.tar.gz

2.5、openssl-1.0.2r.tar.gz

三、安裝tcl（安裝redis必須先要安裝tcl）

3.1、把tcl8.6.1-src.tar.gz通過(guò)WinSCP上傳到虛擬機(jī)中的/usr/local目錄下

四、安裝單機(jī)版redis

4.1、把redis-3.2.8.tar.gz通過(guò)WinSCP上傳到虛擬機(jī)中的/usr/local目錄下

4.2、依次運(yùn)行如下命令：

tar -zxvf redis-3.2.8.tar.gz 解壓文件

cd redis-3.2.8

make && make test && make install

五、把redis設(shè)置為daemon進(jìn)程，每次系統(tǒng)啟動(dòng)，redis進(jìn)程一起啟動(dòng)

5.1、將redis的utils目錄下的redis_init_script腳本拷貝到linux的/etc/init.d目錄中，將redis_init_script重命名為redis_6379，6379是我們希望這個(gè)redis實(shí)例監(jiān)聽的端口號(hào)

5.2、修改redis_6379腳本的第6行的REDISPORT，設(shè)置為相同的端口號(hào)（默認(rèn)就是6379）

protected-mode no 取消保護(hù)模式，保護(hù)模式只能127.0.0.1訪問(wèn)

daemonize yes 讓redis以daemon進(jìn)程運(yùn)行

pidfile /var/run/redis_6379.pid 設(shè)置redis的pid文件位置

bind 192.168.3.110

port 6379 設(shè)置redis的監(jiān)聽端口號(hào)

dir /var/redis/6379 設(shè)置持久化文件的存儲(chǔ)位置

logfile /var/log/redis/6379.log 設(shè)置日志文件位置

5.6、啟動(dòng)redis，依次執(zhí)行：

cd /etc/init.d,

chmod 777 redis_6379，賦讀寫執(zhí)行的權(quán)限（chmod -R 777 * 是遞歸把該目錄下的所有文件和其子文件全部賦權(quán)限）

./redis_6379 start 啟動(dòng)

5.7、確認(rèn)redis進(jìn)程是否啟動(dòng)，ps -ef | grep redis

5.8、讓redis跟隨系統(tǒng)啟動(dòng)自動(dòng)啟動(dòng)

5.9、重啟系統(tǒng)，不手動(dòng)啟動(dòng)redis，直接連接redis，可以連接上，表示配置成功

此時(shí)一個(gè)單機(jī)版的redis的生產(chǎn)環(huán)境已經(jīng)搭建好了，每次服務(wù)器重啟，redis都會(huì)自動(dòng)的啟動(dòng)

六、安裝redis cluster

（redis cluster集群，要求至少3個(gè)master，去組成一個(gè)高可用，健壯的分布式的集群，每個(gè)master都建議至少給一個(gè)slave，3個(gè)master，3個(gè)slave）

6.1、前提，我在其它機(jī)器上啟動(dòng)了六個(gè)redis（安裝步驟都如下）

2.2、創(chuàng)建三個(gè)目錄：

mkdir -p /etc/redis-cluster 存放集群配置信息，自動(dòng)生成配置

mkdir -p /var/log/redis redis日志

mkdir -p /var/redis/7001 存放redis的rdb文件和aof文件

6.3、將redis的utils目錄下的redis_init_script腳本拷貝到linux的/etc/init.d目錄中，將redis_init_script重命名為redis_7001，7001是我們希望這個(gè)redis實(shí)例監(jiān)聽的端口號(hào),并修改redis_7001配置文件中的REDISPORT=7001

6.4、修改/etc/redis/7001.conf中的部分配置為生產(chǎn)環(huán)境

6.5、完成了一個(gè)redis環(huán)境的配置，依次再配置其余五個(gè)，分別為7002、7003、7004、7005、7006，每個(gè)啟動(dòng)腳本內(nèi)，都修改對(duì)應(yīng)的端口號(hào)

6.6、啟動(dòng)6個(gè)redis實(shí)例

6.7、創(chuàng)建集群（需要安裝ruby、rubygems）

上述命令在部分機(jī)器上是可以直接運(yùn)行完成，成功安裝的，但在部分機(jī)器上運(yùn)行第三條命令時(shí)會(huì)提示ruby版本太低、openssl找不到的問(wèn)題，下面依次解決這兩個(gè)問(wèn)題：

6.8、再次運(yùn)行g(shù)em install redis命令，報(bào)出兩個(gè)錯(cuò)誤

6.9、再次運(yùn)行g(shù)em install redis命令，報(bào)出一個(gè)錯(cuò)誤

6.10、再次運(yùn)行g(shù)em install redis命令，報(bào)出一個(gè)錯(cuò)誤

6.11、再次運(yùn)行g(shù)em install redis命令

[root@ceshi01 local]# gem install redis

Successfully installed redis-4.1.1

Parsing documentation for redis-4.1.1

Done installing documentation for redis after 1 seconds

WARNING: Unable to pull data from ' https://rubygems.org/' : SSL_connect returned=1 errno=0 state=error: certificate verify failed ( https://api.rubygems.org/specs.4.8.gz )

1 gem installed

運(yùn)行成功

此時(shí)Redis安裝好，此三個(gè)工具也安裝好了，這時(shí)我們來(lái)做一個(gè)Redis集群測(cè)試，在一臺(tái)服務(wù)器中創(chuàng)建了6個(gè)Redis實(shí)例，開啟6個(gè)Redis服務(wù)

redis-trib.rb create --replicas 1 192.168.3.104:7001 192.168.3.104:7002 192.168.3.105:7003 192.168.3.105:7004 192.168.3.106:7005 192.168.3.106:7006

[root@eshop-cache02 init.d]# redis-trib.rb create --replicas 1 192.168.3.104:7001 192.168.3.104:7002 192.168.3.105:7003 192.168.3.105:7004 192.168.3.106:7005 192.168.3.106:7006

此時(shí)一個(gè)redis集群環(huán)境就已經(jīng)搭建好了，可以通過(guò)redis-trib.rb check 192.168.3.105:7003命令查看集群幾點(diǎn)的信息

[root@eshop-cache02 init.d]# redis-trib.rb check 192.168.3.105:7004

redis cluster的優(yōu)點(diǎn)：讀寫分離+高可用+多master

讀寫分離：每個(gè)master都有一個(gè)slave

高可用：master宕機(jī)，slave自動(dòng)被切換過(guò)去

多master：橫向擴(kuò)容支持更大數(shù)據(jù)量

四、redis常見問(wèn)題

1. 緩存擊穿

緩存擊穿是指一個(gè)請(qǐng)求要訪問(wèn)的數(shù)據(jù)，緩存中沒有，但數(shù)據(jù)庫(kù)中有的情況。這種情況一般都是緩存過(guò)期了。

但是這時(shí)由于并發(fā)訪問(wèn)這個(gè)緩存的用戶特別多，這是一個(gè)熱點(diǎn) key，這么多用戶的請(qǐng)求同時(shí)過(guò)來(lái)，在緩存里面沒有取到數(shù)據(jù)，所以又同時(shí)去訪問(wèn)數(shù)據(jù)庫(kù)取數(shù)據(jù)，引起數(shù)據(jù)庫(kù)流量激增，壓力瞬間增大，直接崩潰給你看。

所以一個(gè)數(shù)據(jù)有緩存，每次請(qǐng)求都從緩存中快速的返回了數(shù)據(jù)，但是某個(gè)時(shí)間點(diǎn)緩存失效了，某個(gè)請(qǐng)求在緩存中沒有請(qǐng)求到數(shù)據(jù)，這時(shí)候我們就說(shuō)這個(gè)請(qǐng)求就"擊穿"了緩存。

針對(duì)這個(gè)場(chǎng)景，對(duì)應(yīng)的解決方案一般來(lái)說(shuō)有三種。

借助Redis setNX命令設(shè)置一個(gè)標(biāo)志位就行。設(shè)置成功的放行，設(shè)置失敗的就輪詢等待。就是在更新緩存時(shí)加把鎖

后臺(tái)開一個(gè)定時(shí)任務(wù)，專門主動(dòng)更新過(guò)期數(shù)據(jù)

比如程序中設(shè)置 why 這個(gè)熱點(diǎn) key 的時(shí)候，同時(shí)設(shè)置了過(guò)期時(shí)間為 10 分鐘，那后臺(tái)程序在第 8 分鐘的時(shí)候，會(huì)去數(shù)據(jù)庫(kù)查詢數(shù)據(jù)并重新放到緩存中，同時(shí)再次設(shè)置緩存為 10 分鐘。

其實(shí)上面的后臺(tái)續(xù)命思想的最終體現(xiàn)是也是永不過(guò)期。

只是后臺(tái)續(xù)命的思想，會(huì)主動(dòng)更新緩存，適用于緩存會(huì)變的場(chǎng)景。會(huì)出現(xiàn)緩存不一致的情況，取決于你的業(yè)務(wù)場(chǎng)景能接受多長(zhǎng)時(shí)間的緩存不一致。

2. 緩存穿透

緩存穿透是指一個(gè)請(qǐng)求要訪問(wèn)的數(shù)據(jù)，緩存和數(shù)據(jù)庫(kù)中都沒有，而用戶短時(shí)間、高密度的發(fā)起這樣的請(qǐng)求，每次都打到數(shù)據(jù)庫(kù)服務(wù)上，給數(shù)據(jù)庫(kù)造成了壓力。一般來(lái)說(shuō)這樣的請(qǐng)求屬于惡意請(qǐng)求。

解決方案有兩種：

就是在數(shù)據(jù)庫(kù)即使沒有查詢到數(shù)據(jù)，我們也把這次請(qǐng)求當(dāng)做 key 緩存起來(lái)，value 可以是 NULL。下次同樣請(qǐng)求就會(huì)命中這個(gè) NULL，緩存層就處理了這個(gè)請(qǐng)求，不會(huì)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生壓力。這樣實(shí)現(xiàn)起來(lái)簡(jiǎn)單，開發(fā)成本很低。

3. 緩存雪崩

緩存雪崩是指緩存中大多數(shù)的數(shù)據(jù)在同一時(shí)間到達(dá)過(guò)期時(shí)間，而查詢數(shù)據(jù)量巨大，這時(shí)候，又是緩存中沒有，數(shù)據(jù)庫(kù)中有的情況了。

防止雪崩的方案簡(jiǎn)單來(lái)說(shuō)就是錯(cuò)峰過(guò)期。

在設(shè)置 key 過(guò)期時(shí)間的時(shí)候，在加上一個(gè)短的隨機(jī)過(guò)期時(shí)間，這樣就能避免大量緩存在同一時(shí)間過(guò)期，引起的緩存雪崩。

如果發(fā)了雪崩，我們可以有服務(wù)降級(jí)、熔斷、限流手段來(lái)拒絕一些請(qǐng)求，保證服務(wù)的正常。但是，這些對(duì)用戶體驗(yàn)是有一定影響的。

4. Redis 高可用架構(gòu)

Redis 高可用架構(gòu)，大家基本上都能想到主從、哨兵、集群這三種模式。

哨兵模式：

它主要執(zhí)行三種類型的任務(wù)：

哨兵其實(shí)也是一個(gè)分布式系統(tǒng)，我們可以運(yùn)行多個(gè)哨兵。

然后這些哨兵之間需要相互通氣，交流信息，通過(guò)投票來(lái)決定是否執(zhí)行自動(dòng)故障遷移，以及選擇哪個(gè)從服務(wù)器作為新的主服務(wù)器。

哨兵之間采用的協(xié)議是 gossip，是一種去中心化的協(xié)議，達(dá)成的是最終一致性。