５, Redis配置檔案,持久化,釋出訂閱,主從複製，快取

阿新 • • 發佈：2021-01-03

5.1 Redis.conf詳解

啟動的時候,就通過配置檔案來啟動!
工作中,一些小小的配置,可以讓你脫穎而出!
行家有沒有,出手就知道

單位

在這裡插入圖片描述 1、配置檔案 unit單位對大小寫不敏感!

包含:可以包含其他配置檔案，把多個配置檔案組合起來，都配置進來
在這裡插入圖片描述就是好比我們學習Spring、Improt, include

網路：

bind 127.0.0.1    # 繫結的ip
protected-mode yes # 保護模式
port 6379  # 埠設定

通用 GENERAL

**守護程序(daemon)**是一類在後臺執行的特殊程序，用於執行特定的系統任務。很多守護程序在系統引導的時候啟動，並且一直執行直到系統關閉。另一些只在需要的時候才啟動，完成任務後就自動結束。

daemonize yes   # 以守護程序的方式執行,預設是 no,我們需要自己開啟為yes!

pidfile /var/run/redis_6379.pid  # 如果以後臺的方式執行,我們就需要指定一個 pid 檔案!
# 日誌
# Specify the server verbosity level.
# This can be one of:（下面是四個級別）
# debug (a lot of information, useful for development/testing)  
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably) 生產環境
# warning (only very important / critical messages are logged)
loglevel notice
logfile "" #生成的日誌的檔案位置名
databases 16  # 資料庫的數量,預設是 16 個數據庫
always-show-logo yes  # 是否總是顯示LOGO

快照

持久化, 在規定的時間內,執行了多少次操作,則會持久化到檔案 .rdb檔案或者.aof檔案
redis是記憶體資料庫,如果沒有持久化,那麼資料斷電即失!

# 如果900s內,如果至少有一個1 key進行了修改,我們就進行持久化操作
save 900 1
# 如果300s內,如果至少10 key進行了修改,我們就進行持久化操作
save 300 10
# 如果60s內,如果至少10000 key進行了修改,我們就進行持久化操作
save 60 10000
# 我們之後學習持久化,會自己定義這個測試!

stop-writes-on-bgsave-error yes   # 持久化如果出錯,是否還需要繼續工作!
rdbcompression yes # 是否壓縮 rdb 檔案,需要消耗一些cpu資源!
rdbchecksum yes # 儲存rdb檔案的時候,進行錯誤的檢查校驗!
dir ./  # rdb 檔案儲存的目錄!，預設是當前目錄

REPLICATION 複製,我們後面講解主從複製的時候再進行講解

SECURITY 安全
可以在這裡設定redis的密碼,預設是沒有密碼!

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass   # 獲取redis的密碼
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "123456"   # 設定redis的密碼
OK
127.0.0.1:6379> config get requirepass   # 發現所有的命令都沒有許可權了
(error) NOAUTH Authentication required.
127.0.0.1:6379> ping
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123456  # 使用密碼進行登入!
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"

限制 CLIENTS

maxclients 10000   # 設定能連線上redis的最大客戶端的數量
maxmemory <bytes>  # redis 配置最大的記憶體容量
maxmemory-policy noeviction  # 記憶體到達上限之後的處理策略
   1、volatile-lru:只對設定了過期時間的key進行LRU(預設值)　　（最近最久未使用）
   2、allkeys-lru : 刪除lru演算法的key  
   3、volatile-random:隨機刪除即將過期key  
   4、allkeys-random:隨機刪除  
   5、volatile-ttl : 刪除即將過期的  
   6、noeviction : 永不過期,返回錯誤

APPEND ONLY 模式 aof配置

appendonly no    # 預設是不開啟aof模式的,預設是使用rdb方式持久化的,在大部分所有的情況下,rdb完全夠用!
appendfilename "appendonly.aof"  # 持久化的檔案的名字
# appendfsync always   # 每次修改都會 sync。消耗效能
appendfsync everysec   # 每秒執行一次 sync,可能會丟失這1s的資料!
# appendfsync no       # 不執行 sync,這個時候作業系統自己同步資料,速度最快!

具體的配置,我們在 Redis持久化中去給大家詳細詳解!

5.2 Redis持久化

面試和工作,持久化都是重點!
Redis 是記憶體資料庫,如果不將記憶體中的資料庫狀態儲存到磁碟,那麼一旦伺服器程序退出,伺服器中的資料庫狀態也會消失。所以 Redis提供了持久化功能!

RDB(Redis DataBase)

什麼是RDB?
在主從複製中,rdb就是備用了!在從機上面!

在這裡插入圖片描述

在指定的時間間隔內將記憶體中的資料集快照寫入磁碟,也就是行話講的Snapshot快照,它恢復時是將快照檔案直接讀到記憶體裡。
Redis會單獨建立(fork)一個子程序來進行持久化,會先將資料寫入到一個臨時檔案中,待持久化過程都結束了,再用這個臨時檔案替換上次持久化好的檔案。整個過程中,主程序是不進行任何IO操作的。這就確保了極高的效能。如果需要進行大規模資料的恢復,且對於資料恢復的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。我們預設的就是RDB,一般情況下不需要修改這個配置!
有時候在生產環境我們會將這個檔案進行備份!
rdb儲存的檔案是dump.rdb 都是在我們的配置檔案中快照中進行配置的!

觸發機制
1、配置檔案中save的規則滿足的情況下,會自動觸發rdb規則
2、執行 flushall 命令,也會觸發我們的rdb規則!
3、退出redis,也會產生 rdb 檔案!
備份就會自動生成一個 dump.rdb

在這裡插入圖片描述

如果恢復rdb檔案!
1、只需要將rdb檔案放在我們redis啟動目錄就可以,redis啟動的時候會自動檢查dump.rdb 恢復其中的資料!
2、檢視需要存放的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"  # 如果在這個目錄下存在 dump.rdb 檔案,啟動就會自動恢復其中的資料

幾乎就它自己預設的配置就夠用了,但是我們還是需要去學習!

優點:
1、適合大規模的資料恢復!
2、對資料的完整性要不高!（這裡是指比如６０秒儲存一次，但是在59秒的時候宕機了，那這５９秒資料就丟失了）

缺點：
1、需要一定的時間間隔程序操作!如果redis意外宕機了,這個最後一次修改資料就沒有的了!
2、fork程序的時候,會佔用一定的記憶體空間！！！

AOF(Append Only File)
將我們的所有命令都記錄下來,就好比history,恢復的時候就把這個檔案全部在執行一遍!

是什麼

在這裡插入圖片描述
以日誌的形式來記錄每個寫操作,將Redis執行過的所有指令記錄下來(讀操作不記錄),只許追加檔案但不可以改寫檔案,redis啟動之初會讀取該檔案重新構建資料,換言之,redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作

Aof儲存的是 appendonly.aof 檔案

append

在這裡插入圖片描述預設是不開啟的,我們需要手動進行配置!我們只需要將 appendonly 改為yes就開啟了 aof!
重啟,redis 就可以生效了!
如果這個 aof 檔案有錯誤,這時候 redis 是啟動不起來的,我們需要修復這個aof檔案
redis 給我們提供了一個修復工具　redis-check-aof --fix

在這裡插入圖片描述
如果檔案正常，重啟就可以正常啟動了

在這裡插入圖片描述 重寫規則說明
aof 預設就是檔案的無限追加,檔案會越來越大!

在這裡插入圖片描述如果 aof 檔案大於 64m,太大了! fork一個新的程序來將我們的檔案進行重寫!

優點和缺點!

appendonly no    # 預設是不開啟aof模式的,預設是使用rdb方式持久化的,在大部分所有的情況下,rdb完全夠用!
appendfilename "appendonly.aof"  # 持久化的檔案的名字
# appendfsync always   # 每次修改都會 sync。消耗效能
appendfsync everysec   # 每秒執行一次 sync,可能會丟失這1s的資料!
# appendfsync no       # 不執行 sync,這個時候作業系統自己同步資料,速度最快!
# rewrite 重寫

優點:
1、每一次修改都同步,檔案的完整性會更加好!
2、每秒同步一次,可能會丟失一秒的資料
3、從不同步,效率最高的!
缺點:
1、相對於資料檔案來說,aof遠遠大於 rdb,修復的速度也比 rdb慢!
2、Aof 執行效率也要比 rdb 慢,所以我們redis預設的配置就是rdb持久化

擴充套件:
1、RDB 持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存
2、AOF 持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以Redis 協議追加儲存每次寫的操作到檔案末尾,Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大。
3、只做快取,如果你只希望你的資料在伺服器執行的時候存在,你也可以不使用任何持久化
4、同時開啟兩種持久化方式

在這種情況下,當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
RDB 的資料不實時,同時使用兩者時伺服器重啟也只會找AOF檔案,那要不要只使用AOF呢?作者建議不要,因為RDB更適合用於備份資料庫(AOF在不斷變化不好備份),快速重啟,而且不會有AOF可能潛在的Bug,留著作為一個萬一的手段。

5、效能建議

因為RDB檔案只用作後備用途,建議只在Slave上持久化RDB檔案,而且只要15分鐘備份一次就夠了,只保留 save 900 1 這條規則。
如果Enable AOF ,好處是在最惡劣情況下也只會丟失不超過兩秒資料,啟動指令碼較簡單隻load自
己的AOF檔案就可以了,代價一是帶來了持續的IO,二是AOF rewrite 的最後將 rewrite 過程中產
生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可,應該儘量減少AOFrewrite的頻率,AOF重寫的基礎大小預設值64M太小了,可以設到5G以上,預設超過原大小100%大小重寫可以改到適當的數值。
如果不Enable AOF ,僅靠 Master-Slave Repllcation 實現高可用性也可以,能省掉一大筆IO,也
減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時倒掉,會丟失十幾分鐘的資料,
啟動指令碼也要比較兩個 Master/Slave 中的 RDB檔案,載入較新的那個,微博就是這種架構。

5.3 Redis釋出訂閱

Redis 釋出訂閱(pub/sub)是一種訊息通訊模式:傳送者(pub)傳送訊息,訂閱者(sub)接收訊息。微信、微博、關注系統!
Redis 客戶端可以訂閱任意數量的頻道。
訂閱/釋出訊息圖: 第一個:訊息傳送者, 第二個:頻道第三個:訊息訂閱者!

在這裡插入圖片描述下圖展示了頻道 channel1 , 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關係:

在這裡插入圖片描述

當有新訊息通過 PUBLISH 命令傳送給頻道 channel1 時, 這個訊息就會被髮送給訂閱它的三個客戶端:

在這裡插入圖片描述
命令
這些命令被廣泛用於構建即時通訊應用,比如網路聊天室(chatroom)和實時廣播、實時提醒等。

在這裡插入圖片描述
測試
　訂閱端：

127.0.0.1:6379> SUBSCRIBE kuangshenshuo  # 訂閱一個頻道 kuangshenshuo
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "kuangshenshuo"
3) (integer) 1
# 等待讀取推送的資訊
1) "message"  # 訊息
2) "kuangshenshuo"  # 哪個頻道的訊息
3) "hello,kuangshen"  # 訊息的具體內容

1) "message"
2) "kuangshenshuo"
3) "hello,redis"

傳送端：

127.0.0.1:6379> PUBLISH kuangshenshuo "hello,kuangshen"   # 釋出者釋出訊息到頻道!
(integer) 1
127.0.0.1:6379> PUBLISH kuangshenshuo "hello,redis"   # 釋出者釋出訊息到頻道!
(integer) 1
127.0.0.1:6379>

原理

Redis是使用C實現的,通過分析 Redis 原始碼裡的 pubsub.c 檔案,瞭解釋出和訂閱機制的底層實現,籍此加深對 Redis的理解。
Redis 通過 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令實現釋出和訂閱功能
微信:
通過 SUBSCRIBE 命令訂閱某頻道後,redis-server 裡維護了一個字典,字典的鍵就是一個個頻道!而字典的值則是一個連結串列,連結串列中儲存了所有訂閱這個 channel 的客戶端。SUBSCRIBE 命令的關鍵,就是將客戶端新增到給定channel 的訂閱連結串列中。

在這裡插入圖片描述　　通過PUBLISH 命令向訂閱者傳送訊息,redis-server 會使用給定的頻道作為鍵,在它所維護的 channel字典中查詢記錄了訂閱這個頻道的所有客戶端的連結串列,遍歷這個連結串列,將訊息釋出給所有訂閱者。

在這裡插入圖片描述
　　Pub/Sub 從字面上理解就是釋出(Publish)與訂閱(Subscribe),在Redis中,你可以設定對某一個key值進行訊息釋出及訊息訂閱,當一個key值上進行了訊息釋出後,所有訂閱它的客戶端都會收到相應的訊息。這一功能最明顯的用法就是用作實時訊息系統,比如普通的即時聊天,群聊等功能。

使用場景:
1、實時訊息系統!
2、實時聊天!(頻道當做聊天室,將資訊回顯給所有人即可!)
3、訂閱,關注系統都是可以的!
稍微複雜的場景我們就會使用訊息中介軟體 MQ ()

5.4 Redis主從複製

概念

主從複製,是指將一臺Redis伺服器的資料,複製到其他的Redis伺服器。前者稱為主節點 (master/leader),後者稱為從節點(slave/follower);資料的複製是單向的,只能由主節點到從節點。Master以寫為主,Slave以讀為主。
預設情況下,每臺Redis伺服器都是主節點;
且一個主節點可以有多個從節點(或沒有從節點),但一個從節點只能有一個主節點。()

主從複製的作用主要包括:
1、資料冗餘:主從複製實現了資料的熱備份,是持久化之外的一種資料冗餘方式。
2、故障恢復:當主節點出現問題時,可以由從節點提供服務,實現快速的故障恢復;實際上是一種服務的冗餘。
3、負載均衡:在主從複製的基礎上,配合讀寫分離,可以由主節點提供寫服務,由從節點提供讀服務(即寫Redis資料時應用連線主節點,讀Redis資料時應用連線從節點),分擔伺服器負載;尤其是在寫少讀多的場景下,通過多個從節點分擔讀負載,可以大大提高Redis伺服器的併發量。
4、高可用(叢集)基石:除了上述作用以外,主從複製還是哨兵和叢集能夠實施的基礎,因此說主從複製是Redis高可用的基礎。

一般來說,要將Redis運用於工程專案中,只使用一臺Redis是萬萬不能的(宕機),原因如下:
1、從結構上,單個Redis伺服器會發生單點故障,並且一臺伺服器需要處理所有的請求負載,壓力較
大;
2、從容量上,單個Redis伺服器記憶體容量有限,就算一臺Redis伺服器記憶體容量為256G,也不能將所有記憶體用作Redis儲存記憶體,一般來說,單臺Redis最大使用記憶體不應該超過20G。電商網站上的商品,一般都是一次上傳,無數次瀏覽的,說專業點也就是"多讀少寫"。對於這種場景,我們可以使如下這種架構:

在這裡插入圖片描述
主從複製,讀寫分離! 80% 的情況下都是在進行讀操作!減緩伺服器的壓力!架構中經常使用! 一主二從!
只要在公司中,主從複製就是必須要使用的,因為在真實的專案中不可能單機使用Redis!

環境配置

只配置從庫,不用配置主庫!

127.0.0.1:6379> info replication   # 檢視當前庫的資訊
# Replication
role:master  # 角色
connected_slaves:0 #沒有從機
master_replid:b63c90e6c501143759cb0e7f450bd1eb0c70882a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

複製3個配置檔案,然後修改對應的資訊
1、埠
2、pid 名字
3、log檔名字
4、dump.rdb 名字

修改完畢之後,啟動我們的3個redis伺服器,可以通過程序資訊檢視!

在這裡插入圖片描述
一主二從
預設情況下,每臺Redis伺服器都是主節點; 我們一般情況下只用配置從機就好了!
認老大! 一主 (79)二從(80,81)

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379   #SLAVEOF host 6379   找誰當自己的老大!
OK
127.0.0.1:6380> info replication
# Replication
role:slave  # 當前角色是從機
master_host:127.0.0.1   # 可以看到主機的資訊
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

# 在主機中檢視!
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1  # 多了從機的配置
slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=1    # 多了從機的配置
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
second_repl_offset:-1
repl_backlog_histlen:42

如果兩個都配置完了，就是有兩個從機的

在這裡插入圖片描述
真實的主從配置應該在配置檔案中配置,這樣的話是永久的,我們這裡使用的是命令,暫時的!

細節
主機可以設定值，從機不能寫只能讀！主機中所有資訊和資料，都會自動被從機儲存

主機寫：
在這裡插入圖片描述
從機只能讀取內容：

測試:

主機斷開連線,從機依舊連線到主機的,但是沒有寫操作,這個時候,主機如果回來了,從機依舊可以直接獲取到主機寫的資訊!
如果是使用命令列來配置的主從,這個時候如果重啟了,從機就會變回主機!只要變為從機,立馬就會從主機中獲取值!

複製原理

Slave 啟動成功連線到 master 後會傳送一個sync同步命令
Master接到命令,啟動後臺的存檔程序,同時收集所有接收到的用於修改資料集命令,在後臺程序執行完畢之後,master將傳送整個資料檔案到slave,並完成一次完全同步。
全量複製:slave服務在接收到資料庫檔案資料後,將其存檔並載入到記憶體中。
增量複製:Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步
但是隻要是重新連線master,一次完全同步(全量複製)將被自動執行!我們的資料一定可以在從機中看到!

層層鏈路
上一個M連結下一個 S!

在這裡插入圖片描述上圖中的80依舊無法進行寫入

這時候也可以完成我們的主從複製!

如果沒有老大了,這個時候能不能選擇一個老大出來呢? 手動!

謀朝篡位

如果主機斷開了連線,我們可以使用SLAVEOF no one讓自己變成主機!其他的節點就可以手動連線到最新的這個主節點(手動)!如果這個時候老大修復了,那就重新連線!只能重新配置

哨兵模式

(自動選舉老大的模式)
概述

主從切換技術的方法是:當主伺服器宕機後,需要手動把一臺從伺服器切換為主伺服器,這就需要人工干預,費事費力,還會造成一段時間內服務不可用。這不是一種推薦的方式,更多時候,我們優先考慮哨兵模式。Redis從2.8開始正式提供了Sentinel(哨兵) 架構來解決這個問題。
謀朝篡位的自動版,能夠後臺監控主機是否故障,如果故障了根據投票數自動將從庫轉換為主庫。
哨兵模式是一種特殊的模式,首先Redis提供了哨兵的命令,哨兵是一個獨立的程序,作為程序,它會獨立執行。其原理是哨兵通過傳送命令,等待Redis伺服器響應,從而監控執行的多個Redis例項。

在這裡插入圖片描述這裡的哨兵有兩個作用

通過傳送命令,讓Redis伺服器返回監控其執行狀態,包括主伺服器和從伺服器。
當哨兵監測到master宕機,會自動將slave切換成master,然後通過釋出訂閱模式通知其他的從服
務器,修改配置檔案,讓它們切換主機。

然而一個哨兵程序對Redis伺服器進行監控,可能會出現問題,為此,我們可以使用多個哨兵進行監控。
各個哨兵之間還會進行監控,這樣就形成了多哨兵模式。

在這裡插入圖片描述
假設主伺服器宕機,哨兵1先檢測到這個結果,系統並不會馬上進行failover過程,僅僅是哨兵1主觀的認為主伺服器不可用,這個現象成為主觀下線。當後面的哨兵也檢測到主伺服器不可用,並且數量達到一定值時,那麼哨兵之間就會進行一次投票,投票的結果由一個哨兵發起,進行failover[故障轉移]操作。切換成功後,就會通過釋出訂閱模式,讓各個哨兵把自己監控的從伺服器實現切換主機,這個過程稱為客觀下線。

測試

我們目前的狀態是一主二從!
1、配置哨兵配置檔案 sentinel.conf

# sentinel monitor 被監控的名稱 host　port　1
sentinel monitor myredis 127.0.0.1 6379 1

後面的這個數字1,代表主機掛了,slave投票看讓誰接替成為主機,票數最多的,就會成為主機!

2、啟動哨兵!

[root@kuangshen bin]# redis-sentinel kconfig/sentinel.conf
26607:X 31 Mar 2020 21:13:10.027 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
26607:X 31 Mar 2020 21:13:10.027 # Redis version=5.0.8, bits=64,
commit=00000000, modified=0, pid=26607, just started
26607:X 31 Mar 2020 21:13:10.027 # Configuration loaded
       

     Redis 5.0.8 (00000000/0) 64 bit
     Running in sentinel mode
     Port: 26379
     PID: 26607                                
         


                      http://redis.io        

26607:X 31 Mar 2020 21:13:10.029 # WARNING: The TCP backlog setting of 511
cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value
of 128.
26607:X 31 Mar 2020 21:13:10.031 # Sentinel ID is
4c780da7e22d2aebe3bc20c333746f202ce72996
26607:X 31 Mar 2020 21:13:10.031 # +monitor master myredis 127.0.0.1 6379 quorum
1
26607:X 31 Mar 2020 21:13:10.031 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @
myredis 127.0.0.1 6379
26607:X 31 Mar 2020 21:13:10.033 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @
myredis 127.0.0.1 6379

如果Master 節點斷開了,這個時候就會從從機中隨機選擇一個伺服器! (這裡面有一個投票演算法!)

在這裡插入圖片描述
哨兵日誌

如果主機此時回來了,只能歸併到新的主機下,當做從機,這就是哨兵模式的規則!

哨兵模式
優點:
1、哨兵叢集,基於主從複製模式,所有的主從配置優點,它全有
2、主從可以切換,故障可以轉移,系統的可用性就會更好
3、哨兵模式就是主從模式的升級,手動到自動,更加健壯!
缺點:
1、Redis 不好線上擴容的,叢集容量一旦到達上限,線上擴容就十分麻煩!
2、實現哨兵模式的配置其實是很麻煩的,裡面有很多選擇!

哨兵模式的全部配置!

# Example sentinel.conf
# 哨兵sentinel例項執行的埠 預設26379
port 26379

# 哨兵sentinel的工作目錄
dir /tmp

# 哨兵sentinel監控的redis主節點的 ip port
# master-name　可以自己命名的主節點名字 只能由字母A-z、數字0-9 、這三個字元".-_"組成。
# quorum 配置多少個sentinel哨兵統一認為master主節點失聯 那麼這時客觀上認為主節點失聯了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 當在Redis例項中開啟了requirepass foobared 授權密碼 這樣所有連線Redis例項的客戶端都要提供密碼
# 設定哨兵sentinel 連線主從的密碼 注意必須為主從設定一樣的驗證密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# 指定多少毫秒之後 主節點沒有應答哨兵sentinel 此時 哨兵主觀上認為主節點下線 預設30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行同步,這個數字越小,完成failover所需的時間就越長,但是如果這個數字越大,就意味著越多的slave因為replication而不可用。
可以通過將這個值設為 1 來保證每次只有一個slave 處於不能處理命令請求的狀態。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1

# 故障轉移的超時時間 failover-timeout 可以用在以下這些方面:
#1. 同一個sentinel對同一個master兩次failover之間的間隔時間。
#2. 當一個slave從一個錯誤的master那裡同步資料開始計算時間。直到slave被糾正為向正確的master那
裡同步資料時。
#3.當想要取消一個正在進行的failover所需要的時間。  
#4.當進行failover時,配置所有slaves指向新的master所需的最大時間。不過,即使過了這個超時,
slaves依然會被正確配置為指向master,但是就不按parallel-syncs所配置的規則來了
# 預設三分鐘
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION
#配置當某一事件發生時所需要執行的指令碼,可以通過指令碼來通知管理員,例如當系統執行不正常時發郵件通知
相關人員。
#對於指令碼的執行結果有以下規則:
#若指令碼執行後返回1,那麼該指令碼稍後將會被再次執行,重複次數目前預設為10
#若指令碼執行後返回2,或者比2更高的一個返回值,指令碼將不會重複執行。
#如果指令碼在執行過程中由於收到系統中斷訊號被終止了,則同返回值為1時的行為相同。
#一個指令碼的最大執行時間為60s,如果超過這個時間,指令碼將會被一個SIGKILL訊號終止,之後重新執行。
#通知型指令碼:當sentinel有任何警告級別的事件發生時(比如說redis例項的主觀失效和客觀失效等等),
將會去呼叫這個指令碼,這時這個指令碼應該通過郵件,SMS等方式去通知系統管理員關於系統不正常執行的信
息。呼叫該指令碼時,將傳給指令碼兩個引數,一個是事件的型別,一個是事件的描述。如果sentinel.conf配
置檔案中配置了這個指令碼路徑,那麼必須保證這個指令碼存在於這個路徑,並且是可執行的,否則sentinel無
法正常啟動成功。
#通知指令碼
# shell程式設計
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh

# 客戶端重新配置主節點引數指令碼
# 當一個master由於failover而發生改變時,這個指令碼將會被呼叫,通知相關的客戶端關於master地址已
經發生改變的資訊。
# 以下引數將會在呼叫指令碼時傳給指令碼:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>總是“failover”,
# <role>是“leader”或者“observer”中的一個。
# 引數 from-ip, from-port, to-ip, to-port是用來和舊的master和新的master(即舊的slave)通訊的
# 這個指令碼應該是通用的,能被多次呼叫,不是針對性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由運維來配置!

社會目前程式設計師飽和(初級和中級)、高階程式設計師重金難求!(提升自己!)

5.5 Redis快取穿透和雪崩(面試高頻，工作常用)

服務的高可用問題!

在這裡我們不會詳細的去分析解決方案的底層!
Redis快取的使用,極大的提升了應用程式的效能和效率,特別是資料查詢方面。但同時,它也帶來了一些問題。其中,最要害的問題,就是資料的一致性問題,從嚴格意義上講,這個問題無解。如果對資料的一致性要求很高,那麼就不能使用快取。
另外的一些典型問題就是,快取穿透、快取雪崩和快取擊穿。目前,業界也都有比較流行的解決方案。

在這裡插入圖片描述
快取穿透(查不到)
概念

快取穿透的概念很簡單,使用者想要查詢一個數據,發現redis記憶體資料庫沒有,也就是快取沒有命中,於是向持久層資料庫查詢。發現也沒有,於是本次查詢失敗。當用戶很多的時候,快取都沒有命中(秒殺!),於是都去請求了持久層資料庫。這會給持久層資料庫造成很大的壓力,這時候就相當於出現了快取穿透。

解決方案
布隆過濾器

布隆過濾器是一種資料結構,對所有可能查詢的引數以hash形式儲存,在控制層先進行校驗,不符合規則丟棄,從而避免了對底層儲存系統的查詢壓力;

在這裡插入圖片描述
快取空物件

當儲存層不命中後,即使返回的空物件也將其快取起來,同時會設定一個過期時間,之後再訪問這個資料將會從快取中獲取,保護了後端資料來源;

在這裡插入圖片描述
但是這種方法會存在兩個問題:
1、如果空值能夠被快取起來,這就意味著快取需要更多的空間儲存更多的鍵,因為這當中可能會有很多的空值的鍵;
2、即使對空值設定了過期時間,還是會存在快取層和儲存層的資料會有一段時間視窗的不一致,這對於需要保持一致性的業務會有影響。

快取擊穿(量太大,快取過期!)
如微博伺服器宕機（如設定60秒過期，60.1秒恢復，這0.1秒可能會導致資料庫壓力過大）
概述

這裡需要注意和快取擊穿的區別,快取擊穿,是指一個key非常熱點,在不停的扛著大併發,大併發集中對這一個點進行訪問,當這個key在失效的瞬間,持續的大併發就穿破快取,直接請求資料庫,就像在一個屏障上鑿開了一個洞。
當某個key在過期的瞬間,有大量的請求併發訪問,這類資料一般是熱點資料,由於快取過期,會同時訪問資料庫來查詢最新資料,並且回寫快取,會導使資料庫瞬間壓力過大。

解決方案
設定熱點資料永不過期

從快取層面來看,沒有設定過期時間,所以不會出現熱點 key 過期後產生的問題。

加互斥鎖

分散式鎖:使用分散式鎖,保證對於每個key同時只有一個執行緒去查詢後端服務,其他執行緒沒有獲得分散式鎖的許可權,因此只需要等待即可。這種方式將高併發的壓力轉移到了分散式鎖,因此對分散式鎖的考驗很大。

在這裡插入圖片描述

快取雪崩
概念
快取雪崩,是指在某一個時間段,快取集中過期失效。Redis 宕機!

產生雪崩的原因之一,比如在寫本文的時候,馬上就要到雙十二零點,很快就會迎來一波搶購,這波商品時間比較集中的放入了快取,假設快取一個小時。那麼到了凌晨一點鐘的時候,這批商品的快取就都過期了。而對這批商品的訪問查詢,都落到了資料庫上,對於資料庫而言,就會產生週期性的壓力波峰。於是所有的請求都會達到儲存層,儲存層的呼叫量會暴增,造成儲存層也會掛掉的情況。

在這裡插入圖片描述
　　其實集中過期,倒不是非常致命,比較致命的是快取雪崩,是快取伺服器某個節點宕機或斷網。因為自然形成的快取雪崩,一定是在某個時間段集中建立快取,這個時候,資料庫也是可以頂住壓力的。無非就是對資料庫產生週期性的壓力而已。而快取服務節點的宕機,對資料庫伺服器造成的壓力是不可預知的,很有可能瞬間就把資料庫壓垮。

雙十一：停掉一些服務，（保證主要的服務可用）
解決方案

redis高可用
　　這個思想的含義是,既然redis有可能掛掉,那我多增設幾臺redis,這樣一臺掛掉之後其他的還可以繼續工作,其實就是搭建的叢集。(異地多活!)

限流降級(在SpringCloud講解過!)
　　這個解決方案的思想是,在快取失效後,通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許一個執行緒查詢資料和寫快取,其他執行緒等待。

資料預熱
　　資料加熱的含義就是在正式部署之前,我先把可能的資料先預先訪問一遍,這樣部分可能大量訪問的資料就會載入到快取中。在即將發生大併發訪問前手動觸發載入快取不同的key,設定不同的過期時間,讓快取失效的時間點儘量均勻。

５, Redis配置檔案,持久化,釋出訂閱,主從複製，快取

5.1 Redis.conf詳解

5.2 Redis持久化

5.3 Redis釋出訂閱

5.4 Redis主從複製

哨兵模式

5.5 Redis快取穿透和雪崩(面試高頻，工作常用)

５, Redis配置檔案,持久化,釋出訂閱,主從複製，快取

跟我一起學Redis之Redis配置檔案啃了一遍之後，從尷尬變得有底氣了

[喵咪Redis]Redis配置檔案和主從設定

Redis配置檔案詳解

Redis配置檔案redis.conf詳細配置說明

Redis配置檔案程式碼講解

Redis配置檔案

redis配置檔案redis.conf總結

redis——配置檔案詳解（2）

scrapy redis配置檔案setting引數詳解

2、redis入門--redis配置檔案

docker修改redis配置檔案

PHP使用Redis的Pub/Sub(釋出訂閱)命令

Redis--配置檔案詳解

Redis 配置檔案詳解

redis-配置檔案詳解

redis之mq實現釋出訂閱模式

Redis配置檔案+springCache配置檔案

redis配置檔案解析（基本）

轉載https://www.cnblogs.com/joshua317/p/5635297.html 關於redis配置檔案的解讀

５, Redis配置檔案,持久化,釋出訂閱,主從複製，快取

5.1 Redis.conf詳解

5.2 Redis持久化

5.3 Redis釋出訂閱

5.4 Redis主從複製

哨兵模式

5.5 Redis快取穿透和雪崩(面試高頻，工作常用)

相關推薦