目錄

集群運維

集群傾斜

集群讀寫分離

手動故障轉(zhuǎn)移

數(shù)據(jù)遷移

緩存更新策略

穿透優(yōu)化

無底洞優(yōu)化

雪崩優(yōu)化

熱點key優(yōu)化

Linux配置優(yōu)化

flushall/flushdb誤操作

安全的redis

處理bigkey

尋找熱點key

---

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

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

集群運維

集群完整性：

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

持有槽的主節(jié)點下線時，從故障發(fā)現(xiàn)到自動切換轉(zhuǎn)移，整個集群狀態(tài)為不可用，大多數(shù)場景無法接受將cluster-require-full-coverage設(shè)置為no

帶寬消耗：

消息發(fā)送頻率：cluster-node-timeout/2

消息數(shù)據(jù)量：slots槽數(shù)組（2kb）+1/10集群的狀態(tài)數(shù)據(jù)

節(jié)點部署規(guī)模：部署的節(jié)點要劃分均勻

Pub/Sub廣播問題：

集群模式下的public廣播問題，頻繁的應(yīng)用Pub/Sub避免在大量節(jié)點的集群使用，建議使用sentinel結(jié)構(gòu)專門用于Pub/Sub

集群傾斜

數(shù)據(jù)傾斜：

節(jié)點和槽不均勻 使用redis-trib.rb rebalance

不同槽對應(yīng)鍵數(shù)據(jù)量差異過大 大量使用hash_tag導(dǎo)致，

使用cluster countkeysinslot?{slot}獲取槽對應(yīng)鍵的數(shù)量發(fā)現(xiàn)最多建的槽，

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

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

內(nèi)存相關(guān)配置不一致 例如hash-max-ziplist-value、set-max-intset-entitres等壓縮數(shù)據(jù)結(jié)構(gòu)配置

請求傾斜：

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

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

2.不使用熱key做hash_tag

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

集群讀寫分離

只讀連接：

集群模式下從節(jié)點不接受任何讀寫請求，被轉(zhuǎn)發(fā)到對應(yīng)的master上

分擔(dān)讀壓力，使用readonly打開只讀狀態(tài)

只讀流程：如果槽屬于正在復(fù)制的主節(jié)點，直接執(zhí)行命令，負責(zé)重定向

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

讀寫分離：

復(fù)制延遲，讀取過期數(shù)據(jù)，從節(jié)點故障

集群提供cluster slave?{nodeId}獲取從節(jié)點

不提倡使用

手動故障轉(zhuǎn)移

從節(jié)點執(zhí)行cluster failover執(zhí)行切換流程

應(yīng)用于：

主節(jié)點遷移（新舊機器遷移）

強制故障轉(zhuǎn)移（主從節(jié)點同時故障）

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

網(wǎng)絡(luò)不穩(wěn)定，無法在cluster-node-timeout*2時間內(nèi)完成發(fā)現(xiàn)轉(zhuǎn)移

集群超過一半以上主節(jié)點同時故障

cluster failover提供

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

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

數(shù)據(jù)遷移

和雪球當(dāng)前方案一樣redis-migrate-tool

緩存更新策略

1.LRU/LFU/FIFO

maxmemory-policy緩存使用量超過預(yù)設(shè)最大值

一致性最差，由算法決定

2.超時剔除

給緩存數(shù)據(jù)添加過期時間

一致性由expire決定

3.主動更新

利用消息系統(tǒng)或者其他方式通知更新緩存

一致性最高，搭配expire更好

4.最佳實踐

低一致性配置最大內(nèi)存和淘汰策略

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

緩存粒度：

穿透優(yōu)化

業(yè)務(wù)代碼或者數(shù)據(jù)問題，惡意攻擊、爬蟲導(dǎo)致

1.緩存空值

優(yōu)點：保護后端數(shù)據(jù)源 數(shù)據(jù)壓力

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

2.布隆過濾器攔截

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

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

無底洞優(yōu)化

增加節(jié)點，性能不增加反而降低

命令優(yōu)化，例如優(yōu)化SQL語句

減少網(wǎng)絡(luò)通信次數(shù)

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

雪崩優(yōu)化

1.保證緩存層服務(wù)的高可用性

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

3.故障演練，上線前就關(guān)閉緩存壓測一下

熱點key優(yōu)化

問題：

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

重建緩存不能短時間內(nèi)完成（復(fù)雜計算，sql、io、多依賴等）

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

解決：

減少重建次數(shù)、數(shù)據(jù)盡可能一致、較少的潛在危險

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

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

Linux配置優(yōu)化

1.vm.overcommit_memory

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

最佳實踐

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

集中化管理AOF和RDB的bgsave

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

2.swappiness

百分比會決定操作系統(tǒng)使用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之后默認開啟，內(nèi)存頁從4KB變?yōu)?MB，建議禁用（echo never > /sys/kernel/mm/transparent_hugepage/enabled）

4.OOM killer

會在可用內(nèi)存不足時殺掉用戶進程，根據(jù)每個進程的權(quán)值（越高越被殺，cat /proc/{pid}/oom_score）

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

5.NTP

網(wǎng)絡(luò)時間協(xié)議，保證不同機器時鐘一致性

6.ulimit

查看和設(shè)置當(dāng)前用戶進程的資源數(shù)，open files是單個用戶打開的最大文件個數(shù)

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

7.TCP backlog

在linux系統(tǒng)內(nèi)核中維護了兩個隊列：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后，根據(jù)緩存還是存儲策略不同

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

存儲：影響巨大

AOF：

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

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

RDB：

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

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

最佳實踐：

使用shell腳本

安全的redis

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

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

主從節(jié)點要配置一致

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

bind綁定的是網(wǎng)卡，可以設(shè)置多個

定期備份數(shù)據(jù)

不使用默認端口

不使用root作為管理員

處理bigkey

字符串一般超過10kb都是大key了，和ops相關(guān)

集合類型一般是元素個數(shù)過多

危害：

內(nèi)存空間不均勻

超時阻塞

網(wǎng)絡(luò)擁塞

處理：

redis-cli --bigkeys統(tǒng)計（debug object key可以查看key的字節(jié)數(shù)）

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

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

刪除：

string直接del

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

尋找熱點key

1.客戶端，每次調(diào)用redis命令時使用字典記錄

缺點：

無法預(yù)知keygeshu，存在內(nèi)存泄漏

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

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

2.代理端（Twemproxy、Codis）

3.redis服務(wù)端

使用monitor命令

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

4.機器

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

處理熱點key：

拆分復(fù)雜數(shù)據(jù)結(jié)構(gòu)

遷移熱點key，將熱點slot單獨遷到一個節(jié)點上

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。