Redis主從複製&哨兵&集羣
前言
參考鏈接：https://www.bilibili.com/video/BV1CJ411m7Gc
主從複製工作流程
數據同步與命令傳播階段工作流程
複製緩衝區：又名複製積壓緩衝區，是一個先進先出的隊列，用於存儲服務器執行過的命令，每次傳播命令，master 都會講傳播的命令記錄下來，並存儲在複製緩衝區；
主從複製配置
-
方式一：通過
slave的redis-cli客戶端發送命令slaveof <masterip> <masterport> -
方式二：啓動服務器參數
redis-server redis.conf --slaveof <masterip> <masterport> -
方式三：在 slave 服務器配置文件(
redis.conf)配置# 開啓了該配置的Redis服務器在啓動後成爲從節點。 slaveof <masterip> <masterport> # 連接建立階段的身份驗證 masterauth <master-password> # 從節點是否只讀；默認是隻讀的。由於從節點開啓寫操作容易導致主從節點的數據不一致，因此該配置儘量不要修改。 slave-read-only yes
主從複製注意
master 注意
-
數據同步階段應避免流量高峯期，避免造成 master 阻塞；
-
複製緩衝區大小設置不合理，會導致數據溢出。如進行全量複製週期太長，進行部分複製時發現數據已經存在丟失的情況，必須進行二次全量複製，致使 slave 陷入死循環狀態
repl-backlog-size 1mb -
master 單機內存佔用主機內存比例不應過大，建議使用50% ~70%，留下 30%~50% 的內存用於執行 bgsave 命令和創建複製緩存區
slave 注意
-
爲避免slave進行全量複製、增量複製時服務器響應阻塞或者數據不同步，建議關閉此期間的對外服務
slave-serve-stale-data yes|no -
多個 slave 同時對 master 請求數據同步，master 發送的 RDB 文件增多，會對帶寬造成巨大沖擊；
-
slave 過多是，建議調整拓撲結構，由一主多從結構變爲樹狀結構，中間的節點既是 master，也是 slave。注意使用樹狀結構時，由於層級深度，導致深度越高的 slave 與最頂層的 master 件數據同步延遲較大，數據一致性較差，應謹慎選擇；
心跳階段注意
當 slave 多數掉線，或者延遲過高時， master 爲保障數據穩定性，將拒絕所有信息同步操作
# 當 slaves 小於 2 時不再寫
min-slaves-to-write 2
#
min-slaves-max-lag 8
slave 數量有 slave 發送 REPLCONF ACK 命令做確認；
slave 延遲有 slave 發送 REPLCONF ACK命令做確認；
哨兵模式
主機宕機，需要從 slave 選舉當 master
哨兵：是一個分佈式系統，用於對主從結構的每臺服務器進行監控，當出現故障時通過投票機制選擇新的 master ，並將所有 slave 連接到新的 master；
哨兵作用
- 監控：不斷的檢查 master 和 slave 是否正常運行，master 存活監測、master 與 slave 運行情況監測；
- 通知：當被監控的服務器出現問題，向其他（哨兵間、客戶端）發送通知；
- 自動故障轉移：斷開 master 和 slave 連接，選取一個 slave 作爲 master，將其他的 slave 連接到新的 master，並告知客戶端新的服務器地址；
注意：哨兵也是一臺redis服務器，只是不提供數據服務，通常哨兵配置數量爲單數，一般3個起；
哨兵搭建
-
配置一拖二的主從結構
-
配置三個哨兵（參考 sentinel.conf）
-
啓動哨兵
redis-sentinel sentinel.conf # 進入 sentinel 服務器 ./redis-cli -h 127.0.0.1 -p 26379
需要開放對應的端口
哨兵配置說明
# 端口，通常默認爲 26379
port 26379
# 後臺啓動
daemonize yes
# pid 目錄
pidfile /var/run/redis-sentinel.pid
# 日誌目錄/日誌文件名
logfile /usr/local/redis/bin/logs/log-sentinel.log
loglevel debug
# 工作目錄
dir /tmp
# 監控master，quorum（設置哨兵數/2 + 1，即多少哨兵認爲 master 宕機）
sentinel monitor <master-name> <ip> <redis-port> <quorum>
# master 權限認證
sentinel auth-pass <master-name> <password>
# 認定連接 master 多少時間，認定 master 宕機
sentinel down-after-milliseconds <master-name> <milliseconds>
# 新master，一次有多少slave開始同步
sentinel parallel-syncs <master-name> <numreplicas>
# 多長時間同步完成算是同步有效，多長時間同步算超時
sentinel failover-timeout <master-name> <milliseconds>
多個哨兵啓動的時候會修改哨兵的配置文件
哨兵工作原理
階段一：監控階段
- 獲取各個 sentinel 的狀態（是否在線）
- 獲取 master 的狀態
- master 屬性：runid、role（master）
- 各個 slave 的詳細信息
- 獲取所有 slave 的狀態（根據master中的slave信息）
- slave 屬性：runid、role（slave）、master_host、master_port、offset
階段二：通知階段
- 保持連通
階段三：故障轉移階段
- 發現問題
- 競選負責人
- 優選新 master
- 新 master 上任，其他 slave 切換 master，原 master 作爲 slave 故障回覆後連接；
集羣*
集羣搭建
配置文件
# 啓動集羣
cluster-enabled yes
#
cluster-config-file nodes-6379.conf
#
cluster-node-timeout 15000
# 集羣下密碼設置，每個節點密碼需要一致
masterauth redis#$%
requirepass redis#$%
執行命令配置
# --replicas 1 表示一個 master 連接 1 個 slave，創建成功後會自動分配主從關係；後面的redis地址數量需要和配置master和slave的數量一致，-a 後面是redis密碼
./redis-cli --cluster create 192.168.8.26:6379 192.168.8.27:6379 192.168.8.28:6379 192.168.8.29:6379 192.168.8.30:6379 192.168.8.31:6379 --cluster-replicas 1 -a redis#$%
客戶端訪問
./redis-cli -c -h 192.168.8.27 -p 6379
緩存預熱
緩存雪崩
- 在一個較短時間內，緩存中較多的key集中過期
- 大量請求訪問過期數據，redis 爲命中，redis 向數據庫獲取數據，數據庫接收大量請求而無法處理
- Redis 大量請求被積壓，出現超時現象
- 數據庫流量激增，數據庫崩潰
- Redis 服務器資源嚴重被佔用，Redis 服務器崩潰
- Redis 集羣呈現崩潰，集羣瓦解
根源
短時間內大量的key集中過期
解決方案
- 頁面靜態化
- 多級緩存架構（cdn緩存+nginx緩存+redis緩存+服務緩存）
- 數據庫讀寫優化
- 災難預警機制：監控CPU佔用和使用率、內存容量
- 限流
- 降級
- 超熱數據使用永久 key
- 使用 LRU和 LFU緩存算法
- LRU (Least recently used) 最近最少使用，如果數據最近被訪問過，那麼將來被訪問的機率也更高。
- LFU (Least frequently used) 最不經常使用，如果一個數據在最近一段時間內使用次數很少，那麼在將來一段時間內被使用的可能性也很小。
- FIFO (Fist in first out) 先進先出， 如果一個數據最先進入緩存中，則應該最早淘汰掉。
緩存擊穿
根源
單個key訪問量巨大
特徵
- Redis 中某個 key 過期，該 key 訪問量巨大
- 多個數據請求服務器直接壓到 Redis 後，均爲命中
- Redis 在短時間內發起大量對數據庫中同一數據的訪問
解決方案
- 預先設定（預先緩存）
- 現場調整（可以暫時設置爲永久數據）
- 定時刷新數據到緩存中
- 二級緩存
緩存穿透
特徵
- Redis 中大面積出現未命中數據
- 出現非正常 URL 訪問
解決方案
- 白名單策略
- 布隆過濾（先查看key是否在緩存，在獲取緩存）
- key 加密
器直接壓到 Redis 後，均爲命中
3. Redis 在短時間內發起大量對數據庫中同一數據的訪問
解決方案
- 預先設定（預先緩存）
- 現場調整（可以暫時設置爲永久數據）
- 定時刷新數據到緩存中
- 二級緩存
緩存穿透
特徵
- Redis 中大面積出現未命中數據
- 出現非正常 URL 訪問
解決方案
- 白名單策略
- 布隆過濾（先查看key是否在緩存，在獲取緩存）
- key 加密