目錄

集群運維

集群傾斜

集群讀寫分離

手動故障轉移

數據遷移

緩存更新策略

穿透優化

無底洞優化

雪崩優化

熱點key優化

Linux配置優化

flushall/flushdb誤操作

安全的redis

處理bigkey

尋找熱點key

---

之前這本書看了大概二分之一，后面就沒有再堅持下去，這次在我球管理redis-manager的機會，重新撿起這本書，深度的閱讀，以防止自己記憶碎片，整理文檔。Redis開發與運維這本書的內容太多，網上沒有找到檢索，記錄下來自己認為重要的信息片段，供檢所使用。

書籍地址：https://github.com/singgel/Study-Floder

集群運維

集群完整性：

默認當16384中任何一個槽沒有指派時集群不可用

持有槽的主節點下線時，從故障發現到自動切換轉移，整個集群狀態為不可用，大多數場景無法接受將cluster-require-full-coverage設置為no

帶寬消耗：

消息發送頻率：cluster-node-timeout/2

消息數據量：slots槽數組（2kb）+1/10集群的狀態數據

節點部署規模：部署的節點要劃分均勻

Pub/Sub廣播問題：

集群模式下的public廣播問題，頻繁的應用Pub/Sub避免在大量節點的集群使用，建議使用sentinel結構專門用于Pub/Sub

集群傾斜

數據傾斜：

節點和槽不均勻 使用redis-trib.rb rebalance

不同槽對應鍵數據量差異過大 大量使用hash_tag導致，

使用cluster countkeysinslot?{slot}獲取槽對應鍵的數量發現最多建的槽，

再通過cluster getkeysinslot?{slot}?{count}迭代出所有鍵找出過度使用的hash_tag

集合對象包含大量元素 使用redis-cli --bigkey識別，找出后根據業務場景拆分（過大會造成migrate失敗）

內存相關配置不一致 例如hash-max-ziplist-value、set-max-intset-entitres等壓縮數據結構配置

請求傾斜：

熱點key的場景，簡單的getset不會造成負載不均勻，一般是hgetall、smembers等搞復雜度算法命令

1.大集合鍵拆分，hmget代替hgetall

2.不使用熱key做hash_tag

3.一致性要求不高的，客戶端使用本地緩存減少熱鍵調用

集群讀寫分離

只讀連接：

集群模式下從節點不接受任何讀寫請求，被轉發到對應的master上

分擔讀壓力，使用readonly打開只讀狀態

只讀流程：如果槽屬于正在復制的主節點，直接執行命令，負責重定向

readonly命令時連接級別，每次新建命令都要

讀寫分離：

復制延遲，讀取過期數據，從節點故障

集群提供cluster slave?{nodeId}獲取從節點

不提倡使用

手動故障轉移

從節點執行cluster failover執行切換流程

應用于：

主節點遷移（新舊機器遷移）

強制故障轉移（主從節點同時故障）

從節點與主節點復制斷線時間超過cluster-slave-validity-factor*cluster-node-timeout+repl-ping-slave-period

網絡不穩定，無法在cluster-node-timeout*2時間內完成發現轉移

集群超過一半以上主節點同時故障

cluster failover提供

force：不再請求master的偏移量，直接替換并廣播

takeover：用于超一半主節點故障，會導致配置紀元沖突，會采用配置紀元大的（紀元沖突采用nodeId大的）

數據遷移

和雪球當前方案一樣redis-migrate-tool

緩存更新策略

1.LRU/LFU/FIFO

maxmemory-policy緩存使用量超過預設最大值

一致性最差，由算法決定

2.超時剔除

給緩存數據添加過期時間

一致性由expire決定

3.主動更新

利用消息系統或者其他方式通知更新緩存

一致性最高，搭配expire更好

4.最佳實踐

低一致性配置最大內存和淘汰策略

高一致性超時剔除+主動更新

緩存粒度：

穿透優化

業務代碼或者數據問題，惡意攻擊、爬蟲導致

1.緩存空值

優點：保護后端數據源 數據壓力

缺點：意味著更多的空間（如果是攻擊，問題就嚴重了）、緩存和存儲有一個時間窗口不一致

2.布隆過濾器攔截

在訪問緩存和存儲前，將存在的key用布隆過濾器提前保存起來做第一層攔截

https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter

無底洞優化

增加節點，性能不增加反而降低

命令優化，例如優化SQL語句

減少網絡通信次數

降低接入成本（長連接、連接池、NIO）

雪崩優化

1.保證緩存層服務的高可用性

2.依賴隔離組件為后端限流并降級https://github.com/netflix/hystrix

3.故障演練，上線前就關閉緩存壓測一下

熱點key優化

問題：

熱點key（例如熱門的新聞事件）并發量賊大

重建緩存不能短時間內完成（復雜計算，sql、io、多依賴等）

在緩存失效期間大量線程重建緩存造成后端壓力驟增

解決：

減少重建次數、數據盡可能一致、較少的潛在危險

互斥鎖：等上一個把緩存整出來、先看看有沒有

永不過期：緩存方面、功能方面（邏輯過期時間）

Linux配置優化

1.vm.overcommit_memory

設置為1(cat /proc/sys/vm/overcommit_memory)，不然log會有提示

最佳實踐

Redis合理設置maxmemory保證機器有20%~30%的空閑

集中化管理AOF和RDB的bgsave

設置vm.overcommit_memory=1，防止極端情況下fork失敗

2.swappiness

百分比會決定操作系統使用swap的傾向程度，越大傾向越高（默認60，cat /proc/sys/vm/swappiness）

free -m、vmstat 1、cat /proc/{pid}/smaps |grep Swap

Linux>3.5 vm.swapniess=1 : vm.swapniess=0

3.THP

Linux2.6.38之后默認開啟，內存頁從4KB變為2MB，建議禁用（echo never > /sys/kernel/mm/transparent_hugepage/enabled）

4.OOM killer

會在可用內存不足時殺掉用戶進程，根據每個進程的權值（越高越被殺，cat /proc/{pid}/oom_score）

這個值受(cat /proc/{pid}/oom_adj)控制，當oom_adj為最小值時該進程不會被殺掉

5.NTP

網絡時間協議，保證不同機器時鐘一致性

6.ulimit

查看和設置當前用戶進程的資源數，open files是單個用戶打開的最大文件個數

maxclient+32是redis的進程數（ulimit -Sn {max-open-files}）

7.TCP backlog

在linux系統內核中維護了兩個隊列：syns queue和accept queue，https://www.jianshu.com/p/e6f2036621f4

redis默認值511（cat /proc/sys/net/core/somaxconn）

這個值不能小于redis的默認值，這個是Linux半連接請求（syns queue）

flushall/flushdb誤操作

被誤flush后，根據緩存還是存儲策略不同

緩存：就是個簡單的緩存穿透

存儲：影響巨大

AOF：

auto-aof-rewrite-percentage、auto-aof-rewrite-min-size看看aof是不是重寫了（調大這個參數），拒絕手動bgrewriteaof

刪除掉flush這個命令，用redis-check-aof修復AOF文件

RDB：

save?{time}?{times}配置文件，防止手動bgsave

flush涉及的key較多，RDB會被清除，取決于RDB是什么時候備份的

最佳實踐：

使用shell腳本

安全的redis

偽裝危險命令：keys、flushall/flushdb、save、debug、config、shutdown

AOF和RDB不要，不然redis無法重啟

主從節點要配置一致

使用防火墻限制ip port只開放80

bind綁定的是網卡，可以設置多個

定期備份數據

不使用默認端口

不使用root作為管理員

處理bigkey

字符串一般超過10kb都是大key了，和ops相關

集合類型一般是元素個數過多

危害：

內存空間不均勻

超時阻塞

網絡擁塞

處理：

redis-cli --bigkeys統計（debug object key可以查看key的字節數）

被動收集：拋異常時打印所有的key

主動檢測：scan+debug object（推薦，鍵過多可以使用pipeline，從節點上執行，避免阻塞）

刪除：

string直接del

集合類型先scan，再pipeline逐個del filed

尋找熱點key

1.客戶端，每次調用redis命令時使用字典記錄

缺點：

無法預知keygeshu，存在內存泄漏

對代碼侵入，多個語言維護困難

只能了解客戶端熱點key，無法規模化運維

2.代理端（Twemproxy、Codis）

3.redis服務端

使用monitor命令

Facebook的redis-faina（盡可能在本機執行，存在單點，影響線上性能問題）

4.機器

對TCP抓包，采用ELK體系下的packetbeat插件（也可以對MySQL檢測）

處理熱點key：

拆分復雜數據結構

遷移熱點key，將熱點slot單獨遷到一個節點上

本地緩存加通知機制（發布訂閱解決不一致問題）

總結

以上是生活随笔為你收集整理的《Redis开发与运维》读书笔记三的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。