Redis持久化

1、reids持久化

一、持久化的取捨和選擇

（1）持久化的做用

redis全部數據保持在內存中，對數據的更新將異步地保存到磁盤上。

（2）持久化方式 RDB快照

RDB文件（二進制）
Redis建立RDB文件，啓動時自帶載入RDB文件
觸發機制-主要三種方式
save(同步) 建立RDB 阻塞 文件策略：如存在老的RDB文件，新替換老 複雜度：O(n)
bgsave(異步) 一、basave 二、fork子進程 三、create RDB 四、bgsave successfully(異步響應客戶端在fork以後)
自動 配置 secondes 900 changes 1 seconds 300 changes 10 seconds 60 changes 10000 知足任一條件
最佳配置
dbfilename dump-{$port}.rdb
dir /bigdiskpath
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

• RDB是Redis內存到硬盤的快照，用於持久化
• save一般會阻塞Redis
• bgsave不會阻塞Redis，可是會fork新進程
• save自動配置知足任一就會被執行

（3）持久化方式 AOF 寫日誌

RDB的現存問題：耗時耗性能
三種策略：
always 寫命令刷新的緩衝區 每條命令 fsync到硬盤 優勢 不丟數據 缺點 IO開銷大
everysec 寫命令刷新緩衝區，每秒把緩衝區 fsync到硬盤 優勢 IO開銷可控 缺點 丟失一秒數據
no 寫命令到緩衝區 OS決定fsync到硬盤 優勢 不用管 缺點 不可空
推薦 everysec
AOF重寫：

• 減小硬盤佔用量
• 加速恢復速度

AOF 重寫實現的兩種方式 bgrewriteof AOF重寫配置
重寫配置 auto-aof-rewrite-min-size AOF文件重寫須要的尺寸 auto-aof-rewrite-percentage AOF文件增加率
aof_current_size AOF當前尺寸 aof_base_size AOF上次啓動和重寫的尺寸
同時知足 自動出發機制
aof_current_size > auto-aof-rewrite-min-size
aof_current_size - aof_base_size/aof_base_size > auto-aof-rewrite-percentage
推薦配置

appendonly yes
appendfilename "appendonly-${port}.aof"
appendfsync everysec
dir /bigdiskpath
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

（4）RDB和AOF的抉擇

RDB 啓動優先級

命令	RDB	AOF
啓動優先級	低	高
體積	小	大
恢復速度	快	慢
數據安全性	丟數據	根據策略決定
輕重	重	輕

• RDB最佳策略

關 集中管理 主關從開
AOF最佳策略
開：緩存和存儲 AOF重寫集中管理 everysec
最佳策略
小分片 緩存或者存儲 監控（硬盤、內存、負載、網絡） 足夠的內存

二、fork子進程的開銷和優化

（1）fork操做

fork特性

• 同步操做
• 與內存量息息相關：內存越大，耗時越長
• info： latestt_fork_usec

改善fork

• 有限使用物理機或者搞笑支持fork操做的虛擬化計數
• 控制redis實例最大可用內存：maxmemory
• 合理配置Linux內存分配策略：vm.overcommit_memory=1
• 下降fork頻率

（2）子進程開銷和優化

CPU
開銷：RDB和AOF文件生成，屬於CPU密集型
優化：不作CPU綁定，不和CPU密集型部署
內存
開銷：fork內存開銷，copy-on-write
優化：echo never > /sys/kernel/mm/transparent_hugepage/enable
硬盤
開銷：AOF和RDB文件寫入，能夠結合iostat，iotop分析
優化：不要和高硬盤負載服務部署一塊兒：存儲服務，隊列服務等 no-appendfsync-on-rewrite=yes
根據寫入量決定磁盤類型 單機多實例持久化目錄能夠考慮分盤

（3）AOF追加阻塞

阻塞定位：Redis日誌 info Persistence

2、Redis的主從複製原理

一、redis的複製

單機的問題：機器故障 容量瓶頸 QPS瓶頸
主從複製的做用：數據副本 擴展讀性能

• 一個master能夠有多個slave
• 一個slave只能有一個master
• 數據流向是單向的，master到slave

實現方式：slaveof命令 配置

命令實現：slaveof 127.0.0.1 6379 複製 slaveof no one 取消複製
修改配置：

slaveof ip port 
slave-read-only yes

比較

方式	命令	配置
優勢	不須要重啓	統一配置
缺點	不便於管理	須要重啓

info replaction 查看主從複製的信息

二、redis的全量複製和部分複製

run_id：redis每次啓動的時候都會有一個隨機的id來保障redis的標識，重啓後消失
複製偏移量：master_repl_offset 記錄寫入了多少字節
全量複製：psync -> fullresync -> save masterInfo -> bgsave -> send RDB -> send buffer -> flush old data -> load RDB
全量複製的開銷：bgsave的時間 RDB文件網絡傳輸時間 從節點清空數據時間 從節點加載RDB時間 可能AOF重寫時間
部分複製：connection lost -> master -> connection to master -> psync -> continue

三、redis的故障處理

主從結構故障轉移：slave宕掉 客戶端從新鏈接另外一個slave master宕掉 使用sentinel自動故障轉移
開發運維中的問題：

• 讀寫分離：流量分攤到從節點

  可能遇到的問題： 複製數據延遲 讀到過時數據 從節點故障

• 主從配置不一致：

  例如maxmemory不一致，丟失數據；例如數據結構優化參數，內存不一致

• 規避全量複製

第一次全量複製，不可避免 小主節點，低峯
節點運行ID不匹配 主節點重啓 故障轉移，例如哨兵或集羣
複製積壓緩衝區不足 網絡中斷，部分複製沒法知足 增大複製緩衝區配置rel_backlog_size，網絡增長

• 規避複製風暴

單節點複製風暴 主節點重啓，多從節點複製 更換複製拓補
單機器複製風暴 機器宕機後，大量全量複製 主節點分散多機器

2、Redis的高可用sentinel

一、redis sentinel的架構

主從複製的問題：手動故障轉移 寫能力和存儲能力受限

• 客戶端從sentinel獲取redis信息
• redis sentinel故障轉移
• 多個sentinel發現並確認master有問題
• 選舉出一個sentinel做爲領導
• 選出一個slave做爲master
• 通知其他slave做爲新的master的slave
• 通知客戶端主從變化
• 等待心動額master復活成爲新的master的slave

二、redis sentinel的安裝和配置

• 配置並開啓主從節點
• 配置並開啓sentinel監控主節點。（sentinel是特殊的redis）
• 多機器
• 詳細配置節點

主節點

port 7000
daemonize yes
pidfile /var/run/redis-7000.pid
logfile "7000.log"
dir "/opt/soft/redis/data/"

從節點

port 7001
daemonize yes
pidfile /var/run/redis-7000.pid
logfile "7000.log"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 7000

sentinel主要配置

port ${port}
daemonize yes
dir "/opt/soft/redis/data/"
logfile "${port}.log"
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel down-after-milliseconds mymaster 300000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

客戶端接入流程
Sentinel地址集合 =》 mastername =》 不是代理模式

三、redis 高可用實現

客戶端高可用觀察
服務端日誌分析：數據節點和Sentinel節點
三個定時任務

（1）、每10秒每一個sentinel對master和slave執行info

• 發現每一個slave節點
• 確認主從關係

（2）、每2秒每一個sentinel經過master節點的channel交換信息（pub/sub）

• 經過__sentinel__：hello頻道交互
• 交互節點的見解和自身信息

（3）、每1秒每一個sentinel對其餘sentinel和redis執行ping

• 心跳檢測，失敗斷定依據

a、主觀下線和客觀下線

主觀下線：每一個sentinel節點對Redis節點失敗的偏見
客觀下線：全部sentinel節點對Redis節點失敗達成共識

b、領導者選舉

緣由：只要一個sentinel節點完成故障轉移
選舉：經過sentinel is-master-down-by-addr命令都但願成爲領導者

• 每一個主觀下線的sentinel節點向其餘sentinel節點發送命令，要求將它設置成爲領導者
• 收到命令的sentinel節點若是沒有贊成經過其餘Sentinel節點發送的命令，那麼就將贊成該請求，不然拒絕
• 若是該sentinel節點發現本身的票數已經超過sentinel集合半數，而且超過quorum，那麼它將成爲領導者
• 若是過程當中有多個sentinel節點成爲了領導者，那麼將等待一段時間從新進行選舉

c、故障轉移

• 從slave節點中選出一個合適的節點做爲新的master節點
• 從上面的slave節點執行slaveof no one 命令讓其成爲master節點
• 向剩餘的slave節點發送命令，讓他們成爲新的master節點的slave節點，複製規則和parallel-syncs參數有關
• 更新對原來的master節點配置爲slave，並保持着對其關注，當其恢復後命令讓他取複製新的master節點

選擇合適的slave節點
選擇slave-pripority最高的slave節點，若是存在則返回，不存在則繼續
選擇複製偏移量將達的slave節點，若是存在則返回，不存在則繼續
選擇runId最小的節點

四、redis 高可用實戰

（1）、節點運維

機器下線：例如過保等狀況
機器性能不足：例如CPU、內存、硬盤、網絡等
節點自身故障：例如服務不穩定
從節點：臨時下線仍是永久下線，例如是否作一些清理工做，可是要考慮讀寫分離的狀況
主節點：sentinel failover進行替換

（2）、高可用讀寫分離

從節點的做用
副本：高可用的基礎
擴展：讀能力

Redis Sentinel是Redis的高可用實現方案

• 故障發現、故障自動轉移、配置中心、客戶端通知
• Redis Sentinel從Redis2.8纔開始正式生成可用
• 儘量在不一樣物理機上部署Redis Sentinel的節點
• RedisSentinel中的Sentinel節點個數應該大於等於3，且最好爲奇數
• Redis Sentinel中的數據節點與普通數據節點沒有區別
• 客戶端初始化時鏈接的時Sentinel節點集合，再也不是具體的Redis節點，但Sentinel只是配置中心不是代理
• Redis Sentinel經過三個定時任務實現了Sentinel節點對於主節點、從節點、其他Sentinel節點的監控
• Redis Sentinel在對節點作失敗斷定時分爲主觀下線和客觀下線
• 看懂Redis Sentinel故障轉移日誌對於Redis Sentinel以及問題排查很是有幫助
• Redis Sentinel實現讀寫分離高可用能夠依賴Sentinel節點的消息通知，獲取Redis數據節點的狀態變化

3、Redis的高可用 Cluster

一、呼喚集羣

併發量超過10萬QPS，數據量超過單機內存
解決方法：分佈式（簡單的認爲加機器）
順序分區：1-100 =》 1-33，34-66，67-100
哈希分區：1-100 =》 hash(key)%3 0,1,2
哈希分佈分爲 節點取餘分區，一致性哈希分區，虛擬槽分區

（1）節點取餘分區，添加一個節點 遷移率80%，多倍擴容遷移率50%

客戶端分片：哈希+取餘
節點伸縮：數據節點關係變化，致使數據遷移
遷移數量和添加節點數量有關：建議翻倍擴容

（2）一致性哈希

客戶端分片：哈希+順時針（優化取餘）
節點伸縮：隻影響臨近節點，可是仍是有數據遷移
翻倍伸縮：保證最小數據遷移和負載均衡

（3）虛擬槽分區

預設虛擬槽：每一個槽映射一個數據子集，通常比節點數大
良好的哈希函數：CRC16
服務端管理節點：槽，數據

二、基本架構

Redis Cluster架構： 節點 meet 指派槽 複製 高可用 分片

（1）安裝配置

配置開啓節點 =》 meet =》 指派槽 =》 主從

port ${port}
daemonize yes
dir "/opt/redis/redis/data"
dbfilename "dump-${port}.rdb"
logfile "${port}.file"
cluster-enabled yes
cluster-config-file nodes-${port}.conf
cluster-require-full-coverage no

cluster meet ip port

Cluster節點主要配置

cluster-enabled yes
cluster-node-timeout 15000
cluster-config-file "nodes.conf"
cluster-require-full-coverage yes

分配槽： cluster addslots slot
設置主從：cluster replicate node-id

（2）redis-trib安裝

下載編譯安裝Ruby => 安裝rubygem redis => 安裝redis-trib.rb配置開啓Redis一鍵開啓：./redis-trib.rb create --replicas 1 127.0.0.1:8000 127.0.0.1:8001...