redis深入學習
阿新 • • 發佈：2020-11-29
Redis持久化
官方文件：
1.RDB和AOF優缺點 RDB: 可以在指定的時間間隔內生成資料集的時間點快照,把當前記憶體裡的狀態快照到磁碟上 優點: 壓縮格式/恢復速度快,適用於備份,主從複製也是基於rdb持久化功能實現 缺點: 可能會丟失資料 AOF: 類似於mysql的binlog,重寫,、每次操作都寫一次/1秒寫一次,檔案中的命令全部以redis協議的格式儲存,新命令會被追加到檔案的末尾 優點: 安全,有可能會丟失1秒的資料 缺點: 檔案比較大,恢復速度慢 2.配置RDB #900秒內有一個更改,300秒內有10個更改,....... save 900 1 save 300 10 save 60 10000 dir /data/redis_6379/ dbfilename redis_6379.rdb 結論: 1.執行shutdown的時候,內部會自動執行bgsave,然後再執行shutdown 2.pkill kill killall 都類似於執行shutdown命令.會觸發bgsave持久化 3.恢復的時候,rdb檔名稱要和配置檔案裡寫的一樣 4.如果沒有配置save引數,執行shutdown不會自動bgsave持久化 5.如果沒有配置save引數,可以手動執行bgsave觸發持久化儲存 6.kill -9 redis 不會出發持久化 常用命令: ll /data/redis_6379/ cat /opt/redis_6379/conf/redis_6379.conf vim /opt/redis_6379/conf/redis_6379.conf pkill redis redis-server /opt/redis_6379/conf/redis_6379.conf redis-cli -h db01 redis-cli -h db01 shutdown bash for.sh 3.配置AOF appendonly yes #是否開啟aof日誌功能 appendfsync always #每1個命令,都立即同步到aof appendfsync everysec #每秒寫1次 appendfsync no #寫入工作交給作業系統,由作業系統判斷緩衝區大小,統一寫入到aof. appendfilename "redis_6379.aof" appendonly yes appendfsync everysec 實驗: 如果aof和rdb檔案同時存在,redis會如何讀取: 實驗步驟: 1.插入一條資料 aof: 有記錄 rdb: 沒有記錄 2.複製到其他地方 3.把redis停掉 4.清空資料目錄 5.把資料檔案拷貝過來 aof: 有記錄 rdb: 沒有記錄 6.啟動redis 7.測試,如果有新插入的資料,就表示讀取的是aof,如果沒有,就表示讀取的是rdb 實驗結論: 如果2種資料格式都存在,優先讀取aof 如何選擇： 好的，那我該怎麼用？ 通常的指示是，如果您希望獲得與PostgreSQL可以提供的功能相當的資料安全性，則應同時使用兩種永續性方法。 如果您非常關心資料，但是在災難情況下仍然可以承受幾分鐘的資料丟失，則可以僅使用RDB。 有很多使用者單獨使用AOF，但我們不建議這樣做，因為不時擁有RDB快照對於進行資料庫備份，加快重啟速度以及AOF引擎中存在錯誤是一個好主意。 注意：由於所有這些原因，我們將來可能會最終將AOF和RDB統一為一個永續性模型（長期計劃）。 以下各節將說明有關這兩個永續性模型的更多詳細資訊。
Redis使用者認證
redis預設開啟了保護模式,只允許本地迴環地址登入並訪問資料庫
禁止protected-mode
protected-mode yes/no （保護模式，是否只允許本地訪問）
1.Bind :指定IP進行監聽 vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf bind 10.0.0.51 127.0.0.1 #增加requirepass {password} vim /opt/redis_cluster/redis_6379/conf/redis_6379.conf requirepass 123456 2.使用密碼登入 兩種方式: 第一種: redis-cli -h db01 AUTH 123456 第二種: redis-cli -h db01 -a 123456 get k_1 ======================================== #禁用危險命令 配置檔案裡新增禁用危險命令的引數 1）禁用命令 rename-command KEYS "" rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command CONFIG "" 2）重新命名命令 rename-command KEYS "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" rename-command FLUSHALL "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" rename-command FLUSHDB "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" rename-command CONFIG "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Redis主從複製
主從複製介紹
在分散式系統中為了解決單點問題,通常會把資料複製多個副本到其他機器,滿足故障恢復和負載均衡等求.
Redis也是如此,提供了複製功能.
複製功能是高可用Redis的基礎,後面的哨兵和叢集都是在複製的基礎上實現高可用的.
配置複製的方式有三種
1.在配置檔案中加入slaveof {masterHost} {masterPort} 隨redis啟動生效. 2.在redis-server啟動命令後加入—slaveof {masterHost} {masterPort}生效. 3.直接使用命令:slaveof {masterHost} {masterPort}生效. #檢視複製狀態資訊命令 Info replication
快速建立第二臺redis節點命令:
rsync -avz db01:/opt/* /opt/
rm -rf /data (先備份)
mkdir /data/redis_6379/ -p
cd /opt/redis
make install
sed -i 's#51#52#g' /opt/redis_6379/conf/redis_6379.conf
redis-server /opt/redis_6379/conf/redis_6379.conf
配置方法:
方法1: 臨時生效
[root@db-02 ~]# redis-cli -h 10.0.0.52
10.0.0.52:6379> SLAVEOF 10.0.0.51 6379
OK
方法2: 寫入配置檔案
SLAVEOF 10.0.0.51 6379
取消主從複製
SLAVEOF no one
注意!!!
1.從節點只讀不可寫
2.從節點不會自動故障轉移,它會一直同步主
10.0.0.52:6379> set k1 v1
(error) READONLY You can't write against a read only slave.
3.主從複製故障轉移需要人工介入
- 修改程式碼指向REDIS的IP地址
- 從節點需要執行SLAVEOF no one
注意!!!
1.從節點會清空自己原有的資料,如果同步的物件寫錯了,就會導致資料丟失
2.主庫有密碼從庫的配置
masterauth 123456
安全的操作:
1.無論是同步,無論是主節點還是從節點
2.先備份一下資料
3.配置持久化(為了重新載入資料)
4.重啟
從節點請求同步:
2602:S 09 Nov 15:58:25.703 * The server is now ready to accept connections on port 6379
2602:S 09 Nov 15:58:25.703 * Connecting to MASTER 10.0.1.51:6379
2602:S 09 Nov 15:58:25.703 * MASTER <-> SLAVE sync started
2602:S 09 Nov 15:58:25.703 * Non blocking connect for SYNC fired the event.
2602:S 09 Nov 15:58:25.703 * Master replied to PING, replication can continue...
2602:S 09 Nov 15:58:25.704 * Partial resynchronization not possible (no cached master)
2602:S 09 Nov 15:58:25.705 * Full resync from master: be1ed4812a0bd83227af30dc6ebe36d88bca5005:1
主節點收到請求之後開始持久化儲存資料:
12703:M 09 Nov 15:58:25.708 * Slave 10.0.1.52:6379 asks for synchronization
12703:M 09 Nov 15:58:25.708 * Full resync requested by slave 10.0.1.52:6379
12703:M 09 Nov 15:58:25.708 * Starting BGSAVE for SYNC with target: disk
12703:M 09 Nov 15:58:25.708 * Background saving started by pid 12746
12746:C 09 Nov 15:58:25.710 * DB saved on disk
12746:C 09 Nov 15:58:25.710 * RDB: 6 MB of memory used by copy-on-write
從節點接收主節點發送的資料,然後載入記憶體:
2602:S 09 Nov 15:58:25.805 * MASTER <-> SLAVE sync: receiving 95 bytes from master
2602:S 09 Nov 15:58:25.805 * MASTER <-> SLAVE sync: Flushing old data
2602:S 09 Nov 15:58:25.805 * MASTER <-> SLAVE sync: Loading DB in memory
2602:S 09 Nov 15:58:25.806 * MASTER <-> SLAVE sync: Finished with success
主節點收到從節點同步完成的訊息:
12703:M 09 Nov 15:58:25.809 * Background saving terminated with success
12703:M 09 Nov 15:58:25.809 * Synchronization with slave 10.0.1.52:6379 succeeded
主從複製流程:
1.從節點發送同步請求到主節點
2.主節點接收到從節點的請求之後,做了如下操作
- 立即執行bgsave將當前記憶體裡的資料持久化到磁碟上
- 持久化完成之後,將rdb檔案傳送給從節點
3.從節點從主節點接收到rdb檔案之後,做了如下操作
- 清空自己的資料
- 載入從主節點接收的rdb檔案到自己的記憶體裡
4.後面的操作就是和主節點實時的了
Redis哨兵
Redis Sentinel 是一個分散式系統， Redis Sentinel為Redis提供高可用性。可以在沒有人為干預的情況下阻止某種型別的故障。
Redis 的 Sentinel 系統用於管理多個 Redis 伺服器（instance）該系統執行以下三個任務：
1.監控（Monitoring）：
Sentinel 會不斷地定期檢查你的主伺服器和從伺服器是否運作正常。
2.提醒（Notification）：
當被監控的某個 Redis 伺服器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程式傳送通知。
3.自動故障遷移（Automatic failover）：
當一個主伺服器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主伺服器的其中一個從伺服器升級為新的主伺服器， 並讓失效主伺服器的其他從伺服器改為複製新的主伺服器； 當客戶端試圖連線失效的主伺服器時， 叢集也會向客戶端返回新主伺服器的地址， 使得叢集可以使用新主伺服器代替失效伺服器
Sentinel 節點是一個特殊的 Redis 節點,他們有自己專屬的 API(埠)
規劃安裝配置命令
哨兵是基於主從複製，所以需要先部署好主從複製
手工操作步驟如下：
1.先配置和建立好1臺伺服器的節點和哨兵
2.使用rsync傳輸到另外2臺機器
3.修改另外兩臺機器的IP地址
建議使用ansible劇本批量部署
結構圖
做db03的主從
1.db03上執行快速安裝第3個redis節點
rsync -avz 10.0.0.51:/opt/* /opt/
mkdir /data/redis_6379 -p
cd /opt/redis
make install
sed -i 's#51#53#g' /opt/redis_6379/conf/redis_6379.conf
redis-server /opt/redis_6379/conf/redis_6379.conf
redis-cli
2.啟動所有的單節點
redis-server /opt/redis_6379/conf/redis_6379.conf
3.配置主從複製(任意節點)
redis-cli -h 10.0.0.52 slaveof 10.0.0.51 6379
redis-cli -h 10.0.0.53 slaveof 10.0.0.51 6379
安裝部署3個哨兵節點-----基於主從的前提
!!!!注意!!!!
三個節點的bind IP修改為自己的IP地址
mkdir -p /data/redis_26379
mkdir -p /opt/redis_26379/{conf,pid,logs}
#.配置哨兵的配置檔案
注意！三臺機器都操作
cat >/opt/redis_26379/conf/redis_26379.conf << EOF
bind $(ifconfig eth0|awk 'NR==2{print $2}')
port 26379
daemonize yes
logfile /opt/redis_26379/logs/redis_26379.log
dir /data/redis_26379
sentinel monitor myredis 10.0.0.51 6379 2
sentinel down-after-milliseconds myredis 3000
sentinel parallel-syncs myredis 1
sentinel failover-timeout myredis 18000
EOF
#.啟動哨兵
redis-sentinel /opt/redis_26379/conf/redis_26379.conf
#.驗證主節點(注意對應的節點)
redis-cli -h 10.0.0.51 -p 26379 Sentinel get-master-addr-by-name myredis
redis-cli -h 10.0.0.52 -p 26379 Sentinel get-master-addr-by-name myredis
redis-cli -h 10.0.0.53 -p 26379 Sentinel get-master-addr-by-name myredis
配置檔案的變化
當所有節點啟動後,配置檔案的內容發生了變化,體現在三個方面:
1)Sentinel節點自動發現了從節點,其餘Sentinel節點
2)去掉了預設配置,例如parallel-syncs failover-timeout引數
3)添加了配置紀元相關引數
檢視配置檔案命令
[root@db01 ~]# tail -6 /opt/redis_cluster/redis_26379/conf/redis_26379.conf
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 10.0.0.52 6379
sentinel known-slave mymaster 10.0.0.53 6379
sentinel known-sentinel mymaster 10.0.0.53 26379 7794fbbb9dfb62f4d2d7f06ddef06bacb62e4c97
sentinel known-sentinel mymaster 10.0.0.52 26379 17bfab23bc53a531571790b9b31558dddeaeca40
sentinel current-epoch 0
模擬故障轉移
- 關閉主節點服務上的所有redis程序
- 觀察其他2個節點會不會發生選舉
- 檢視配置檔案裡會不會自動更新
- 檢視新的主節點能不能寫入
- 檢視從節點能否正常同步
模擬故障修復上線
- 啟動單節點
- 啟動哨兵
模擬權重選舉,權重相同的id小的優先(最好其他權重設定為0,100以上有問題)
- 設定其他節點的權重為0
- 手動發起重新選舉
- 觀察所有節點訊息是否同步
- 觀察切換結果是否符合預期
命令解釋:
1.查詢命令:CONFIG GET slave-priority
2.設定命令:CONFIG SET slave-priority 0
3.主動切換(哨兵):sentinel failover myredis
redis-cli -h 10.0.0.52 -p 6379 CONFIG SET slave-priority 0
redis-cli -h 10.0.0.53 -p 6379 CONFIG SET slave-priority 0
redis-cli -h 10.0.0.51 -p 26379 sentinel failover myredis
驗證選舉結果:
redis-cli -h 10.0.0.51 -p 26379 Sentinel get-master-addr-by-name myredis
Redis哨兵+主從+密碼
主從密碼配置檔案裡新增2行引數：
requirepass "123456"
masterauth "123456"
哨兵配置檔案新增一行引數：
sentinel auth-pass myredis 123456
Redis哨兵設定權重手動故障轉移
1.檢視權重
CONFIG GET slave-priority
2.設定權重
在其他節點把權重設為0
CONFIG SET slave-priority 0
3.主動發起重新選舉
sentinel failover mymaster
4.恢復預設的權重
CONFIG SET slave-priority 100
redis叢集安裝部署-----基於主從的前提
Redis Cluster 是 redis的分散式解決方案，在3.0版本正式推出
當遇到單機、記憶體、併發、流量等瓶頸時，可以採用Cluster架構方案達到負載均衡目的。
Redis Cluster之前的分散式方案有兩種：
- 客戶端分割槽方案，優點分割槽邏輯可控，缺點是需要自己處理資料路由，高可用和故障轉移等。
- 代理方案，優點是簡化客戶端分散式邏輯和升級維護便利，缺點加重架構部署和效能消耗。
官方提供的 Redis Cluster叢集方案，很好的解決了叢集方面的問題
資料分佈
分散式資料庫首先要解決把整個資料庫集按照分割槽規則對映到多個節點的問題,即把資料集劃分到多個節點上,每個節點負責整體資料的一個子集,需要關注的資料分片規則,redis clusterciyong雜湊分片規則
手動搭建部署叢集
思路:
- 部署一臺伺服器上的2個叢集節點
- 傳送完成後修改其他主機的ip地址
- 使用ansible批量部署
拓撲圖
1.目錄規劃
主節點 6380
從節點 6381
# redis安裝目錄
/opt/redis_{6380,6381}/{conf,logs,pid}
# redis資料目錄
/data/redis_{6380,6381}
# redis運維指令碼
/root/scripts/redis_shell.sh
2.db01建立命令
#為了關閉其他redis埠,生產中需要注意
pkill redis
mkdir -p /opt/redis_{6380,6381}/{conf,logs,pid}
mkdir -p /data/redis_{6380,6381}
cat >/opt/redis_6380/conf/redis_6380.conf<<EOF
bind 10.0.0.51
port 6380
daemonize yes
pidfile "/opt/redis_6380/pid/redis_6380.pid"
logfile "/opt/redis_6380/logs/redis_6380.log"
dbfilename "redis_6380.rdb"
dir "/data/redis_6380/"
cluster-enabled yes
cluster-config-file nodes_6380.conf
cluster-node-timeout 15000
EOF
cd /opt/
cp redis_6380/conf/redis_6380.conf redis_6381/conf/redis_6381.conf
sed -i 's#6380#6381#g' redis_6381/conf/redis_6381.conf
rsync -avz /opt/redis_638* 10.0.0.52:/opt/
rsync -avz /opt/redis_638* 10.0.0.53:/opt/
redis-server /opt/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_6381/conf/redis_6381.conf
ps -ef|grep redis
3.db02操作命令
pkill redis
find /opt/redis_638* -type f -name "*.conf"|xargs sed -i "/bind/s#51#52#g"
mkdir –p /data/redis_{6380,6381}
redis-server /opt/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_6381/conf/redis_6381.conf
ps -ef|grep redis
4.db03操作命令
pkill redis
find /opt/redis_638* -type f -name "*.conf"|xargs sed -i "/bind/s#51#53#g"
mkdir –p /data/redis_{6380,6381}
redis-server /opt/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_6381/conf/redis_6381.conf
ps -ef|grep redis
手動配置節點發現
當把所有節點都啟動後檢視程序會有cluster的字樣,但是登入後執行CLUSTER NODES命令會發現只有每個節點自己的ID,目前叢集內的節點,還沒有互相發現,所以搭建redis叢集我們第一步要做的就是讓叢集內的節點互相發現.,在執行節點發現命令之前我們先檢視一下叢集的資料目錄會發現有生成叢集的配置檔案,檢視後發現只有自己的節點內容,等節點全部發現後會把所發現的節點ID寫入這個檔案
叢集模式的Redis除了原有的配置檔案之外又加了一份叢集配置檔案.當叢集內節點. 資訊發生變化,如新增節點,節點下線,故障轉移等.節點會自動儲存叢集狀態到配置檔案.
需要注意的是,Redis自動維護叢集配置檔案,不需要手動修改,防止節點重啟時產生錯亂.
節點發現使用命令: CLUSTER MEET {IP} {PORT}
提示:在叢集內任意一臺機器執行此命令就可以
發現節點(db01)
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.51 6381
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.52 6380
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.52 6381
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.53 6380
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.53 6381
查詢
redis-cli -h 10.0.0.51 -p 6380 CLUSTER NODES
[root@db01 opt]# redis-cli -h 10.0.0.51 -p 6380 CLUSTER NODES
0a138d3b47ae0ac83719d150ac5e46f1986c92f9 10.0.0.52:6381 master - 0 1577372412387 3 connected
f1c6d6a418edb08f986715f093934646d92f99e3 10.0.0.53:6381 master - 0 1577372411377 0 connected
dc225e89785179d0045d82a2b3f0c1d072466713 10.0.0.53:6380 master - 0 1577372410361 4 connected 10922-16383
81b466115f32423ecd32a2cb4477f1e1a9913437 10.0.0.52:6380 master - 0 1577372408341 5 connected 5461-10921
83d86340bf4859023994ba75f4b1d84778a58840 10.0.0.51:6381 master - 0 1577372413402 2 connected
b0cda45c78d5a7fe288f46fa85c4041da795a5ec 10.0.0.51:6380 myself,master - 0 0 1 connected 0-5460
Redis Cluster 通訊流程
在分散式儲存中需要提供維護節點元資料資訊的機制，所謂元資料是指：節點負責哪些資料，是否出現故障燈狀態資訊，redis 叢集採用 Gossip(流言)協議，Gossip 協議工作原理就是節點彼此不斷交換資訊，一段時間後所有的節點都會知道叢集完整資訊，這種方式類似流言傳播。
通訊過程：
-
叢集中的每一個節點都會單獨開闢一個 Tcp 通道，用於節點之間彼此通訊，通訊埠在基礎埠上家10000.
-
每個節點在固定週期內通過特定規則選擇結構節點發送 ping 訊息
-
接收到 ping 訊息的節點用 pong 訊息作為響應。叢集中每個節點通過一定規則挑選要通訊的節點，每個節點可能知道全部節點，也可能僅知道部分節點，只要這些節點彼此可以正常通訊，最終他們會打成一致的狀態，當節點出現故障，新節點加入，主從角色變化等，它能夠給不斷的ping/pong訊息，從而達到同步目的。
通訊訊息型別：
-
Gossip
Gossip 協議職責就是資訊交換，資訊交換的載體就是節點間彼此傳送Gossip 訊息。
常見 Gossip 訊息分為：ping、 pong、 meet、 fail 等 -
meet
meet 訊息：用於通知新節點加入，訊息傳送者通知接受者加入到當前叢集，meet 訊息
通訊正常完成後，接收節點會加入到叢集中並進行ping、 pong 訊息交換
-
ping
ping 訊息：叢集內交換最頻繁的訊息，叢集內每個節點每秒想多個其他節點發送 ping 訊息，用於檢測節點是否線上和交換彼此資訊。
-
pong
Pong 訊息：當接收到 ping，meet 訊息時，作為相應訊息回覆給傳送方確認訊息正常通訊，節點也可以向叢集內廣播自身的 pong 訊息來通知整個叢集對自身狀態進行更新。 -
fail
fail 訊息：當節點判定叢集內另一個節點下線時，迴向叢集內廣播一個fail 訊息，其他節點收到 fail 訊息之後把對應節點更新為下線狀態。
通訊示意圖：
-
手動分配槽位
-
redis叢集一共有16384個槽,所有的槽都必須分配完畢，
-
有一個槽沒分配整個叢集都不可用,每個節點上槽位的順序無所謂，重點是槽位的個數,
-
hash分片演算法足夠隨機，足夠平均
-
不要去手動修改叢集的配置檔案
我們雖然有6個節點,但是真正負責資料寫入的只有3個節點,其他的3個節點只是作為主節點的從節點,也就是說,只需要分配期中三個節點的的槽位就可以
非配槽位需要在每個主節點上來配置,兩種方法執行:
- 分別登陸到每個主節點的客戶端來執行命令
- 一臺遠端登入在其主節點上執行
1.槽位規劃
db01:6380 0-5460
db02:6380 5461-10921
db03:6380 10922-16383
2.分配槽位(有的版本有坑,會報錯,需要注意)
redis-cli -h 10.0.0.51 -p 6380 CLUSTER ADDSLOTS {0..5460}
redis-cli -h 10.0.0.52 -p 6380 CLUSTER ADDSLOTS {5461..10920}
redis-cli -h 10.0.0.52 -p 6380 CLUSTER ADDSLOTS 10921
redis-cli -h 10.0.0.53 -p 6380 CLUSTER ADDSLOTS {10922..16383}
3.檢視叢集狀態
redis-cli -h db01 -p 6380 CLUSTER info
允許的槽位個數誤差範圍2%以內
手動配置叢集的高可用
雖然這時候叢集是可用的了,但是整個叢集只要有一臺機器壞掉了,那麼整個叢集都是不可用的.
所以這時候需要用到其他三個節點分別作為現在三個主節點的從節點,以應對叢集主節點故障時可以進行自動切換以保證叢集持續可用.
注意:
1.不要讓複製節點複製本機器的主節點, 因為如果那樣的話機器掛了叢集還是不可用狀態, 所以複製節點要複製其他伺服器的主節點.
2.使用redis-trid工具自動分配的時候會出現複製節點和主節點在同一臺機器上的情況,需要注意
手動部署複製關係
#查詢id
redis-cli -h 10.0.0.51 -p 6380 CLUSTER NODES
redis-cli -h 10.0.0.51 -p 6381 CLUSTER REPLICATE 35b5ee70a887b5256089a5eebf521aa21a0a7a7a
redis-cli -h 10.0.0.52 -p 6381 CLUSTER REPLICATE 65baaa3b071f906c14da10452c349b0871317210
redis-cli -h 10.0.0.53 -p 6381 CLUSTER REPLICATE a1d47ccb19411eaf12d5af4b22cafbbefc8e2486
測試叢集
1.嘗試插入一條資料發現報錯
10.0.0.51:6380> set k1 v1
(error) MOVED 12706 10.0.0.53:6380
2.目前的現象
- 在db01的6380節點插入資料提示報錯
- 報錯內容提示應該移動到db03的6380上
- 在db03的6380上執行相同的插入命令可以插入成功
- 在db01的6380節點插入資料有時候可以,有時候不行
- 使用-c引數後,可以正常插入命令,並且節點切換到了提示的對應節點上
3.問題原因
因為叢集模式又ASK路由規則,加入-c引數後,會自動跳轉到目標節點處理
並且最後由目標節點返回資訊
4.測試足夠隨機足夠平均
#!/bin/bash
for i in $(seq 1 1000)
do
redis-cli -c -h db01 -p 6380 set k_${i} v_${i} && echo "set k_${i} is ok"
done
控制指令碼
sh redis_shell.sh login 6380 10.0.0.52
[root@db03 script]# cat redis_shell.sh
#!/bin/bash
USAG(){
echo "sh $0 {start|stop|restart|login|ps|tail} PORT"
}
if [ "$#" = 1 ]
then
REDIS_PORT='6379'
elif
[ "$#" -gt 2 -a -z "$(echo "$2"|sed 's#[0-9]##g')" ]
then
REDIS_PORT="$2"
else
USAG
exit 0
fi
REDIS_IP=$3
PATH_DIR=/opt/redis_${REDIS_PORT}/
PATH_CONF=/opt/redis_${REDIS_PORT}/conf/redis_${REDIS_PORT}.conf
PATH_LOG=/opt/redis_${REDIS_PORT}/logs/redis_${REDIS_PORT}.log
CMD_START(){
redis-server ${PATH_CONF}
}
CMD_SHUTDOWN(){
redis-cli -c -h ${REDIS_IP} -p ${REDIS_PORT} shutdown
}
CMD_LOGIN(){
redis-cli -c -h ${REDIS_IP} -p ${REDIS_PORT}
}
CMD_PS(){
ps -ef|grep redis
}
CMD_TAIL(){
tail -f ${PATH_LOG}
}
case $1 in
start)
CMD_START
CMD_PS
;;
stop)
CMD_SHUTDOWN
CMD_PS
;;
restart)
CMD_START
CMD_SHUTDOWN
CMD_PS
;;
login)
CMD_LOGIN
;;
ps)
CMD_PS
;;
tail)
CMD_TAIL
;;
*)
USAG
esac
模擬故障轉移
至此,我們已經手動的把一個redis高可用的叢集部署完畢了, 但是還沒有模擬過故障
這裡我們就模擬故障,停掉期中一臺主機的redis節點,然後檢視一下叢集的變化
我們使用暴力的kill -9殺掉 db02上的redis叢集節點,然後觀察節點狀態
理想情況應該是db01上的6381從節點升級為主節點
在db01上檢視叢集節點狀態
雖然我們已經測試了故障切換的功能,但是節點修復後還是需要重新上線
所以這裡測試節點重新上線後的操作
重新啟動db02的6380,然後觀察日誌
觀察db01上的日誌
這時假如我們想讓修復後的節點重新上線,可以在想變成主庫的從庫執行CLUSTER FAILOVER命令
這裡我們在db02的6380上執行
Redis Cluster ASK路由介紹
在叢集模式下,Redis接受任何鍵相關命令時首先會計算鍵對應的槽,再根據槽找出所對應的節點 如果節點是自身,則處理鍵命令;否則回覆MOVED重定向錯誤,通知客戶端請求正確的節點,這個過程稱為Mover重定向.
知道了ask路由後,我們使用-c選項批量插入一些資料
使用工具搭建部署Redis Cluster
手動搭建叢集便於理解叢集建立的流程和細節，不過手動搭建叢集需要很多步驟，當叢集節點眾多時，必然會加大搭建叢集的複雜度和運維成本，因此官方提供了 redis-trib.rb的工具方便我們快速搭建叢集。
redis-trib.rb是採用 Ruby 實現的 redis 叢集管理工具，內部通過 Cluster相關命令幫我們簡化叢集建立、檢查、槽遷移和均衡等常見運維操作，使用前要安裝 ruby 依賴環境
1.安裝依賴-只要在db01上操作
yum makecache fast
yum install rubygems -y
gem sources --remove https://rubygems.org/
gem sources -a http://mirrors.aliyun.com/rubygems/
gem update –system
gem install redis -v 3.3.5
2.還原環境-所有節點都執行!!!
pkill redis
rm -rf /data/redis_6380/*
rm -rf /data/redis_6381/*
3.啟動叢集節點-所有節點都執行
redis-server /opt/redis_6380/conf/redis_6380.conf
redis-server /opt/redis_6381/conf/redis_6381.conf
ps -ef|grep redis
4.使用工具搭建部署Redis(一臺部署)
cd /opt/redis/src/
./redis-trib.rb create --replicas 1 10.0.0.51:6380 10.0.0.52:6380 10.0.0.53:6380 10.0.0.51:6381 10.0.0.52:6381 10.0.0.53:6381
5.檢查叢集完整性
./redis-trib.rb check 10.0.0.51:6380
6.檢查叢集負載是否合規
./redis-trib.rb rebalance 10.0.0.51:6380
使用工具擴容節點
redis叢集的擴容操作規劃
- 準備新節點
- 加入叢集
- 遷移槽和資料(遷移過程千萬不能中斷,以防叢集故障)
擴容流程圖
打印出進群每個節點資訊後,reshard命令需要確認遷移的槽數量,這裡我們輸入4096個:
How many slots do you want to move (from 1 to 16384)? 4096
輸入6390的節點ID作為目標節點,也就是要擴容的節點,目標節點只能指定一個
What is the receiving node ID? xxxxxxxxx
之後輸入源節點的ID,這裡分別輸入每個主節點的6380的ID最後輸入done,或者直接輸入all
Source node #1:all
遷移完成後命令會自動退出,這時候我們檢視一下叢集的狀態
./redis-trib.rb rebalance 10.0.0.51:6380
1.建立新節點-db01操作
mkdir -p /opt/redis_{6390,6391}/{conf,logs,pid}
mkdir -p /data/redis_{6390,6391}
cd /opt/
cp redis_6380/conf/redis_6380.conf redis_6390/conf/redis_6390.conf
cp redis_6380/conf/redis_6380.conf redis_6391/conf/redis_6391.conf
sed -i 's#6380#6390#g' redis_6390/conf/redis_6390.conf
sed -i 's#6380#6391#g' redis_6391/conf/redis_6391.conf
redis-server /opt/redis_6390/conf/redis_6390.conf
redis-server /opt/redis_6391/conf/redis_6391.conf
ps -ef|grep redis
redis-cli -c -h db01 -p 6380 cluster meet 10.0.0.51 6390
redis-cli -c -h db01 -p 6380 cluster meet 10.0.0.51 6391
redis-cli -c -h db01 -p 6380 cluster nodes
2.使用工具擴容步驟
cd /opt/redis/src/
./redis-trib.rb reshard 10.0.0.51:6380
第一次互動:每個節點保留多少個槽位
How many slots do you want to move (from 1 to 16384)? 4096
第二次互動:接收節點的ID是什麼
What is the receiving node ID? 6390的ID
第三次互動:哪個節點需要匯出
Source node #1: all
第四次互動:確認是否執行分配
Do you want to proceed with the proposed reshard plan (yes/no)? yes
3.檢查叢集完整性
./redis-trib.rb check 10.0.0.51:6380
4.檢查叢集負載是否合規
./redis-trib.rb rebalance 10.0.0.51:6380
5.調整複製順序
redis-cli -h 10.0.0.53 -p 6381 CLUSTER REPLICATE 51-6390的ID
redis-cli -h 10.0.0.51 -p 6391 CLUSTER REPLICATE 51-6380的ID
6.測試寫入指令碼
[root@db01 ~]# cat for.sh
#!/bin/bash
for i in $(seq 1 100000)
do
redis-cli -c -h db01 -p 6380 set k_${i} v_${i} && echo "set k_${i} is ok"
done
7.測試讀指令碼
[root@db03 ~]# cat du.sh
#!/bin/bash
for i in $(seq 1 100000)
do
redis-cli -c -h db01 -p 6380 get k_${i}
sleep 0.1
done
使用工具收縮節點
流程說明
- 確定下線節點是否有負責的槽,如果是,要把槽遷移到其他節點,保證節點下線後整個叢集槽節點對映的完整性
- 當下線節點不再負責槽或者本身是從節點時,就可以通知群內其他節點忘記下線節點,當所有的節點忘記該節點後可以正常關閉
- 計劃將6390和6391節點下線,收縮和擴容的方向相反,6390變為源節點,其他節點變為目標節點,源節點把自己負責的4096個槽均勻的遷移到其他節點上,由於
redis-trib.rb reshard命令只能有一個目標節點,因此需要執行3次reshard命令,分別遷移1365,1365,1366個槽
收縮流程圖
1.使用工具收縮節點
cd /opt/redis/src/
./redis-trib.rb reshard 10.0.0.51:6380
2.第一次互動: 要遷移多少個
How many slots do you want to move (from 1 to 16384)? 1365
3.第二次互動: 輸入第一個需要接收節點的ID
What is the receiving node ID? db01的6380的ID
4.第三次互動: 輸入需要匯出的節點的ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: db01的6390的ID
Source node #2: done
5.第四次互動: 確認
Do you want to proceed with the proposed reshard plan (yes/no)? yes
6.繼續重複的操作,直到6390所有的槽位都分配給了其他主節點
7.確認叢集狀態是否正常,確認6390槽位是否都遷移走了
10.0.0.51:6380> CLUSTER NODES
8.忘記以及下線節點(從節點可以直接刪除,主節點先移走資料,再刪除)
./redis-trib.rb del-node 10.0.0.51:6390 baf9585a780d9f6e731972613a94b6f3e6d3fb5e
./redis-trib.rb del-node 10.0.0.51:6391 e54a79cca258eb76fb74fc12dafab5ebac26ed90
排錯思路
-
首先確定埠是否啟動
-
檢查防火牆,getenforce
-
./redis-trib.rb check 10.0.0.51:6380檢查
-
cluster nodes
企業案例
遷移過程中,ctrl+c,叢集出現問題
解決辦法:
工具關閉槽
cd /opt/redis/src
./redis-trib.rb fix 10.0.0.51:6380
手動關閉:
連線對應的redis節點,執行cluster setslot 773 stable,(匯入,匯出問題槽位)
執行,reblance是出現#######,按下ctrl+c發現叢集執行cluster info時.ok,但槽的狀態有問題
解決思路:
1手動關閉:
連線對應的redis節點,執行cluster setslot 773 stable,
查詢槽的狀態已經恢復
cluster info
檢查,有報錯,
./redis-trib.rb check 10.0.0.51:6380
cluster info 狀態ok,叢集用fix,有問題,發現問題773槽位識別出現問題,其他節點上看0-773在6390上,6390上看而在6380上
2.刪除兩個問題槽位,6380,6390
cluster delslots 773
3.6390新增773
cluster addslots 773
發現大家看到的結果一致6390上,check.reblance ok
redis叢集常用的命令
叢集(cluster)
CLUSTER INFO 列印叢集的資訊
CLUSTER NODES 列出叢集當前已知的所有節點（node），以及這些節點的相關資訊。
節點(node)
CLUSTER MEET <ip> <port> 將 ip 和 port 所指定的節點新增到叢集當中，讓它成為叢集的一份子。
CLUSTER FORGET <node_id> 從叢集中移除 node_id 指定的節點。
CLUSTER REPLICATE <node_id> 將當前節點設定為 node_id 指定的節點的從節點。
CLUSTER SAVECONFIG 將節點的配置檔案儲存到硬盤裡面。
槽(slot)
CLUSTER ADDSLOTS <slot> [slot ...] 將一個或多個槽（slot）指派（assign）給當前節點。
CLUSTER DELSLOTS <slot> [slot ...] 移除一個或多個槽對當前節點的指派。
CLUSTER FLUSHSLOTS 移除指派給當前節點的所有槽，讓當前節點變成一個沒有指派任何槽的節點。
CLUSTER SETSLOT <slot> NODE <node_id> 將槽 slot 指派給 node_id 指定的節點，如果槽已經指派給另一個節點，那麼先讓另一個節點刪除該槽>，然後再進行指派。
CLUSTER SETSLOT <slot> MIGRATING <node_id> 將本節點的槽 slot 遷移到 node_id 指定的節點中。
CLUSTER SETSLOT <slot> IMPORTING <node_id> 從 node_id 指定的節點中匯入槽 slot 到本節點。
CLUSTER SETSLOT <slot> STABLE 取消對槽 slot 的匯入（import）或者遷移（migrate）。
鍵 (key)
CLUSTER KEYSLOT <key> 計算鍵 key 應該被放置在哪個槽上。
CLUSTER COUNTKEYSINSLOT <slot> 返回槽 slot 目前包含的鍵值對數量。CLUSTER GETKEYSINSLOT <slot> <count> 返回 count 個 slot 槽中的鍵。
資料遷移
需求背景
剛切換到redis叢集的時候肯定會面臨資料匯入的問題,所以這裡推薦使用redis-migrate-tool工具來匯入單節點資料到叢集裡
官方地址：
匯出工具
1.安裝工具
yum install libtool autoconf automake git bzip2 -y
cd /opt/
git clone https://github.com/vipshop/redis-migrate-tool.git
cd redis-migrate-tool/
autoreconf -fvi
./configure
make && make install
2.編寫配置檔案
cat > 6379_to_6380.conf << EOF
[source]
type: single
servers:
- 10.0.0.51:6379
[target]
type: redis cluster
servers:
- 10.0.0.51:6380
[common]
listen: 0.0.0.0:8888
source_safe: true
EOF
3.單節點生成測試資料
redis-server /opt/redis_6379/conf/redis_6379.conf
cat >input_6379.sh<<EOF
#!/bin/bash
for i in {1..1000}
do
redis-cli -c -h db01 -p 6379 set oldzhang_\${i} oldzhang_\${i}
echo "set oldzhang_\${i} is ok"
done
EOF
4.執行工具遷移單節點資料到叢集
redis-migrate-tool -c 6379_to_6380.conf
5.執行工具驗證資料是否遷移完成
redis-migrate-tool -c 6379_to_6380.conf -C redis_check
RDB檔案遷移到叢集
1.先把叢集的RDB檔案都收集起來
- 在從節點上執行bgsave命令生成RDB檔案
redis-cli -h db01 -p 6381 BGSAVE
redis-cli -h db02 -p 6381 BGSAVE
redis-cli -h db03 -p 6381 BGSAVE
2.把從節點生成的RDB檔案拉取過來
mkdir /root/rdb_backup
cd /root/rdb_backup/
scp db01:/data/redis_6381/redis_6381.rdb db01_6381.rdb
scp db02:/data/redis_6381/redis_6381.rdb db02_6381.rdb
scp db03:/data/redis_6381/redis_6381.rdb db03_6381.rdb
3.清空資料
redis-cli -c -h db01 -p 6380 flushall
redis-cli -c -h db02 -p 6380 flushall
redis-cli -c -h db03 -p 6380 flushall
7.編寫配置檔案
cat >rdb_to_cluter.conf <<EOF
[source]
type: rdb file
servers:
- /root/rdb_backup/db01_6381.rdb
- /root/rdb_backup/db02_6381.rdb
- /root/rdb_backup/db03_6381.rdb
[target]
type: redis cluster
servers:
- 10.0.0.51:6380
[common]
listen: 0.0.0.0:8888
source_safe: true
EOF
8.使用工具匯入
redis-migrate-tool -c rdb_to_cluter.conf
使用工具分析key的大小(注意Python環境的安裝過程,有出錯多執行幾次)
需求背景
redis的記憶體使用太大鍵值太多,不知道哪些鍵值佔用的容量比較大,而且線上分析會影響效能
0.需求背景
redis的記憶體使用太大鍵值太多,不知道哪些鍵值佔用的容量比較大,而且線上分析會影響效能.
1.安裝命令:(pip可能會出錯,)
yum install python-pip gcc python-devel -y
cd /opt/
git clone https://github.com/sripathikrishnan/redis-rdb-tools
cd redis-rdb-tools
pip install python-lzf
python setup.py install
2.生成測試資料:
redis-cli -h db01 -p 6379 set txt $(cat txt.txt)
3.執行bgsave生成rdb檔案
redis-cli -h db01 -p 6379 BGSAVE
3.使用工具分析:
cd /data/redis_6379/
rdb -c memory redis_6379.rdb -f redis_6379.rdb.csv
4.過濾分析
awk -F"," '{print $4,$3}' redis_6379.rdb.csv |sort -n
5.將結果整理彙報給領導,詢問開發這個key是否可以刪除
預防redis不斷寫入資料
設定記憶體最大限制
config set maxmemory 2G
記憶體回收機制
當達到記憶體使用限制之後redis會出發對應的控制策略
redis支援6種策略：
1.noevicition 預設策略，不會刪除任務資料，拒絕所有寫入操作並返回客戶端錯誤資訊，此時只響應讀操作
2.volatile-lru 根據LRU演算法刪除設定了超時屬性的key，指導騰出足夠空間為止，如果沒有可刪除的key，則退回到noevicition策略
3.allkeys-lru 根據LRU演算法刪除key，不管資料有沒有設定超時屬性
4.allkeys-random 隨機刪除所有key
5.volatile-random 隨機刪除過期key
5.volatile-ttl 根據key的ttl，刪除最近要過期的key
動態配置
config set maxmemory-policy
監控過期鍵
需求背景
因為開發重複提交，導致電商網站優惠捲過期時間失效
問題分析
如果一個鍵已經設定了過期時間，這時候在set這個鍵，過期時間就會取消
解決思路
如何在不影響機器效能的前提下批量獲取需要監控鍵過期時間
1.Keys * 查出來匹配的鍵名。然後迴圈讀取ttl時間
2.scan * 範圍查詢鍵名。然後迴圈讀取ttl時間
Keys 重操作，會影響伺服器效能，除非是不提供服務的從節點
Scan 負擔小，但是需要去多次才能取完，需要寫指令碼
指令碼內容：
cat 01get_key.sh
#!/bin/bash
key_num=0
> key_name.log
for line in $(cat key_list.txt)
do
while true
do
scan_num=$(redis-cli -h 192.168.47.75 -p 6380 SCAN ${key_num} match ${line}\* count 1000|awk 'NR==1{print $0}')
key_name=$(redis-cli -h 192.168.47.75 -p 6380 SCAN ${key_num} match ${line}\* count 1000|awk 'NR>1{print $0}')
echo ${key_name}|xargs -n 1 >> key_name.log
((key_num=scan_num))
if [ ${key_num} == 0 ]
then
break
fi
done
done