上篇詳細(xì)闡述了redis集群的安裝搭建以及集群監(jiān)控變更相關(guān)運(yùn)維操作尿庐，本篇繼續(xù)對(duì)redis集群調(diào)優(yōu)和常見(jiàn)問(wèn)題的解決進(jìn)行介紹。

一、集群調(diào)優(yōu)

1.1 Linux 內(nèi)存內(nèi)核參數(shù)優(yōu)化：

Vm.overcommit_memory

參數(shù)說(shuō)明: 文件指定了內(nèi)核針對(duì)內(nèi)存分配的策略，其值可以是0野芒、1、2双炕。

• 0：表示內(nèi)核將檢查是否有足夠的可用內(nèi)存供應(yīng)用進(jìn)程使用狞悲；如果有足夠的可用內(nèi)存， 內(nèi)存申請(qǐng)?jiān)试S妇斤；否則摇锋，內(nèi)存申請(qǐng)失敗，并把錯(cuò)誤返回給應(yīng)用進(jìn)程站超。

• 1：表示內(nèi)核允許分配所有的物理內(nèi)存荸恕，而不管當(dāng)前的內(nèi)存狀態(tài)如何。

• 2：表示內(nèi)核允許分配超過(guò)所有物理內(nèi)存和交換空間總和的內(nèi)存死相。

建議該參數(shù)設(shè)置為1

1.2 網(wǎng)絡(luò)參數(shù)優(yōu)化：

# 允許存在time_wait狀態(tài)的最大數(shù)值瞎饲，超過(guò)則立刻被清楚并且警告 
# 默認(rèn)是262144, 防止過(guò)多的time_wait導(dǎo)致端口資源被耗盡
net.ipv4.tcp_max_tw_buckets = 6000
# 允許系統(tǒng)打開(kāi)的端口范圍尚蝌，
# 默認(rèn)狀態(tài)下系統(tǒng)自身可自動(dòng)使用的端口范圍是 32768 逗抑，61000璧榄，
net.ipv4.ip_local_port_range = 10000 65000
# 啟用timewait 快速回收 项阴，在nat環(huán)境存在問(wèn)題
net.ipv4.tcp_tw_recycle = 1
# 開(kāi)啟重用椿争。允許將TIME-WAIT sockets 重新用于新的TCP 連接柳击。
net.ipv4.tcp_tw_reuse = 1
# 開(kāi)啟SYN Cookies橄杨，當(dāng)出現(xiàn)SYN 等待隊(duì)列溢出時(shí)七芭，啟用cookies 來(lái)處理素挽。
net.ipv4.tcp_syncookies = 1
# 定義了系統(tǒng)中每一個(gè)端口最大的監(jiān)聽(tīng)隊(duì)列的長(zhǎng)度
net.core.somaxconn = 262144
net.core.netdev_max_backlog = 262144
# 處于半連接狀態(tài)的最大鏈接數(shù)，防止過(guò)多異常鏈接導(dǎo)致系統(tǒng)異常
net.ipv4.tcp_max_syn_backlog = 262144
# 時(shí)間戳可以避免序列號(hào)的卷繞, 在nat 環(huán)境會(huì)導(dǎo)致故障
net.ipv4.tcp_timestamps = 0
# 建立連接syn+ack 與syn 包重試次數(shù)
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

系統(tǒng)打開(kāi)最大文件數(shù)設(shè)置：

fs.file-max：系統(tǒng)所有進(jìn)程一共可以打開(kāi)的文件數(shù)量

[root@elk-server etc]# sysctl  -a  | grep  file
fs.file-nr = 4416       0       52565136
fs.file-max = 52565136

Fs.file-nr:這個(gè)是一個(gè)狀態(tài)指示的文件狸驳，一共三個(gè)值：

• 第一個(gè)代表全局已經(jīng)分配的文件描述符數(shù)量
• 第二個(gè)代表自由的文件描述符（待重新分配的）
• 第三個(gè)代表總的文件描述符的數(shù)量预明。

cat /proc/sys/fs/file-nr 
編輯 /etc/sysctl.conf    
fs.file-max=52550148重啟生效 
查看和設(shè)置 Linux 當(dāng)前用戶(hù)的資源設(shè)置情況

image.png

swap設(shè)置：

為提高redis整體性能 ，避免redis內(nèi)部的熱數(shù)據(jù)被在內(nèi)存不足的情況被交換到磁盤(pán)耙箍，讀取數(shù)據(jù)的時(shí)候相應(yīng)緩慢撰糠，建議盡量不使用swap或者禁用swap。對(duì)于內(nèi)部不足 最好的方法還是擴(kuò)大內(nèi)存辩昆。

臨時(shí)生效：

sysctl -w vm.swappiness=0

永久生效：

echo "vm.swappiness = 0">> /etc/sysctl.conf（盡量不使用交換分區(qū)阅酪，注意不不是禁用）

刷新SWAP：可以執(zhí)行命令刷新一次SWAP（將SWAP里的數(shù)據(jù)轉(zhuǎn)儲(chǔ)回內(nèi)存，并清空SWAP里的數(shù)據(jù)）

swapoff -a && swapon -a

sysctl -p (執(zhí)行這個(gè)使其生效，不用重啟)

或者直接關(guān)閉 swap

swapoff -a

并修改文件 /etc/fstab 注釋掉swap行术辐，并重啟永久生效

image.png

關(guān)閉透明大頁(yè)(Transparent Huge Pages)：

在redis實(shí)例啟動(dòng)時(shí)候會(huì)報(bào)如下警告：

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

意思是：你使用的是透明大頁(yè)砚尽，可能導(dǎo)致redis延遲和內(nèi)存使用問(wèn)題

執(zhí)行以下命令可修復(fù)該問(wèn)題：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

永久解決方案：

修改內(nèi)核參數(shù) /boot/grub/grub.conf

添加transparent_hugepage=never numa=off

image.png

重啟生效

open-file：

用戶(hù)會(huì)話(huà)級(jí)別的文件打開(kāi)的最大數(shù)

[root@elk-server configs]# cat  /etc/security/limits.conf | grep  -v '#' | grep  -v '^$'
* soft nofile 102400
* hard nofile 102400

1.3 Redis配置參數(shù)調(diào)優(yōu)：

禁用rdb持久化

• rdb 持久化會(huì)導(dǎo)致redis實(shí)例頻繁的做fork操作，fork 創(chuàng)建一個(gè)子進(jìn)程辉词，比較耗費(fèi)資源必孤。

• 在訪(fǎng)問(wèn)量比較大的系統(tǒng)中(特別是更新/插入比較頻繁的系統(tǒng)中)，會(huì)產(chǎn)生大量的增量數(shù)據(jù)瑞躺，系統(tǒng)刷新大量的增量數(shù)據(jù)到磁盤(pán)會(huì)嚴(yán)重導(dǎo)致性能波動(dòng)敷搪。

• rdb會(huì)丟數(shù)據(jù)

• 建議設(shè)置為 save “”

設(shè)置 maxmemory

默認(rèn)值是 0，表示不限制內(nèi)存使用幢哨，會(huì)導(dǎo)致系統(tǒng)資源被耗盡购啄。建議根據(jù)項(xiàng)目系統(tǒng)需求設(shè)置一個(gè)最大值，但不建議單實(shí)例超過(guò)20gb嘱么。

設(shè)置timeout 超時(shí)時(shí)間

防止大量空閑鏈接占用大量資源 狮含，建議設(shè)置將超時(shí)鏈接設(shè)置為3600s Timeout 3600

slowlog-max-len

設(shè)置1000，記錄慢查詢(xún)的條數(shù),默認(rèn)128 曼振，增加該值几迄，方便排查系統(tǒng)異常等問(wèn)題。

tcp-backlog默認(rèn)

TCP接收隊(duì)列長(zhǎng)度冰评，受以下兩個(gè)內(nèi)核參數(shù)的影響：

• /proc/sys/net/core/somaxconn

• tcp_max_syn_backlog

在高并發(fā)的環(huán)境下映胁，你需要把這個(gè)值調(diào)高以避免客戶(hù)端連接緩慢的問(wèn)題。

數(shù)據(jù)持久化策略

數(shù)據(jù)持久化策略 甲雅，以場(chǎng)景為主

appendonly：是否開(kāi)啟appendonlylog解孙，開(kāi)啟的話(huà)每次寫(xiě)操作會(huì)記一條log，這會(huì)提高數(shù)據(jù)抗風(fēng)險(xiǎn)能力抛人，但影響效率弛姜。

appendfsync：appendonlylog如何同步到磁盤(pán)（三個(gè)選項(xiàng)，分別是每次寫(xiě)都強(qiáng)制調(diào)用fsync妖枚、每秒啟用一次fsync廷臼、不調(diào)用fsync等待系統(tǒng)自己同步）【常可以設(shè)置為 no荠商，everysec，always

• no：只需讓操作系統(tǒng)在需要時(shí)刷新數(shù)據(jù)续誉。速度快莱没。

• everysec (默認(rèn))：fsync每秒只有一次。折中酷鸦。

• always：每次寫(xiě)入僅附加日志后的fsync饰躲。慢朴译，最安全。

發(fā)送使用fsync的默認(rèn)策略属铁，每秒寫(xiě)入性能仍然很好（使用后臺(tái)線(xiàn)程執(zhí)行fsync眠寿，并且當(dāng)沒(méi)有fsync正在進(jìn)行時(shí)，主線(xiàn)程將努力執(zhí)行寫(xiě)入焦蘑。）建議設(shè)置為 everysec.

數(shù)據(jù)淘汰策略 待確認(rèn)

maxmemory-policy 六種方式 :

• volatile-lru：只對(duì)設(shè)置了過(guò)期時(shí)間的key進(jìn)行LRU（默認(rèn)值）

• allkeys-lru ：是從所有key里 刪除 不經(jīng)常使用的key

• volatile-random：隨機(jī)刪除即將過(guò)期key

• allkeys-random：隨機(jī)刪除

• volatile-ttl：刪除即將過(guò)期的

• noeviction：永不過(guò)期盯拱，返回錯(cuò)誤

建議設(shè)置為 volatile-ttl

repl-diskless-sync 啟用無(wú)盤(pán)復(fù)制

復(fù)制過(guò)程中產(chǎn)生的rdb文件不落盤(pán)，避免造成過(guò)大的io例嘱，影響性能 該參數(shù)默認(rèn)no

建議設(shè)置為 no

repl-disable-tcp-nodelay

是否啟用TCP_NODELAY狡逢，如果啟用則會(huì)使用少量的TCP包和帶寬去進(jìn)行數(shù)據(jù)傳輸?shù)絪lave端，當(dāng)然速度會(huì)比較慢拼卵；如果不啟用則傳輸速度比較快奢浑，但是會(huì)占用比較多的帶寬。

no-appendfsync-on-rewrite

bgrewriteaof機(jī)制腋腮，在一個(gè)子進(jìn)程中進(jìn)行aof的重寫(xiě)雀彼，從而不阻塞主進(jìn)程對(duì)其余命令的處理，同時(shí)解決了aof文件過(guò)大問(wèn)題即寡。
現(xiàn)在問(wèn)題出現(xiàn)了徊哑，同時(shí)在執(zhí)行bgrewriteaof操作和主進(jìn)程寫(xiě)aof文件的操作，兩者都會(huì)操作磁盤(pán)聪富，而bgrewriteaof往往會(huì)涉及大量磁盤(pán)操作莺丑，這樣就會(huì)造成主進(jìn)程在寫(xiě)aof文件的時(shí)候出現(xiàn)阻塞的情形。
現(xiàn)在no-appendfsync-on-rewrite參數(shù)出場(chǎng)了：如果該參數(shù)設(shè)置為no墩蔓，是最安全的方式梢莽，不會(huì)丟失數(shù)據(jù)，但是要忍受阻塞的問(wèn)題奸披。如果設(shè)置為yes呢昏名？這就相當(dāng)于將appendfsync設(shè)置為no，這說(shuō)明并沒(méi)有執(zhí)行磁盤(pán)操作源内，只是寫(xiě)入了緩沖區(qū)葡粒，因此這樣并不會(huì)造成阻塞（因?yàn)闆](méi)有競(jìng)爭(zhēng)磁盤(pán)）份殿，但是如果這個(gè)時(shí)候redis掛掉膜钓，就會(huì)丟失數(shù)據(jù)。
丟失多少數(shù)據(jù)呢卿嘲？在linux的操作系統(tǒng)的默認(rèn)設(shè)置下颂斜，最多會(huì)丟失30s的數(shù)據(jù)。因此拾枣，如果應(yīng)用系統(tǒng)無(wú)法忍受延遲沃疮，而可以容忍少量的數(shù)據(jù)丟失盒让，則設(shè)置為yes。如果應(yīng)用系統(tǒng)無(wú)法忍受數(shù)據(jù)丟失司蔬，則設(shè)置為no邑茄。

tcp-keepalive

發(fā)送redis服務(wù)端主動(dòng)向空閑的客戶(hù)端發(fā)起ack請(qǐng)求，以判斷連接是否有效 ,默認(rèn)值為 0 俊啼，表示禁用肺缕，可以通過(guò)tcp-keepalive配置項(xiàng)來(lái)進(jìn)行設(shè)置，單位為秒授帕。假如設(shè)置為60秒同木，則server端會(huì)每60秒向連接空閑的客戶(hù)端發(fā)起一次ACK請(qǐng)求，以檢查客戶(hù)端是否已經(jīng)掛掉跛十，對(duì)于無(wú)響應(yīng)的客戶(hù)端則會(huì)關(guān)閉其連接彤路。所以關(guān)閉一個(gè)連接最長(zhǎng)需要120秒的時(shí)間。如果設(shè)置為0芥映，則不會(huì)進(jìn)行敝拮穑活檢測(cè)。默認(rèn)為0

cluster-slave-validity-factor

設(shè)置slave斷開(kāi)master的時(shí)間因子在進(jìn)行故障轉(zhuǎn)移的時(shí)候全部slave都會(huì)請(qǐng)求申請(qǐng)為master奈偏，但是有些slave可能與master斷開(kāi)連接一段時(shí)間了導(dǎo)致數(shù)據(jù)過(guò)于陳舊颊郎，不應(yīng)該被提升為master。該參數(shù)就是用來(lái)判斷slave節(jié)點(diǎn)與master斷線(xiàn)的時(shí)間是否過(guò)長(zhǎng)霎苗。
判斷方法是：比較slave斷開(kāi)連接的時(shí)間和(node-timeout * slave-validity-factor)+ repl-ping-slave-period如果節(jié)點(diǎn)超時(shí)時(shí)間為三十秒, 并且slave-validity-factor為10姆吭，假設(shè)默認(rèn)的repl-ping-slave-period是10秒，即如果超過(guò)310秒slave將不會(huì)嘗試進(jìn)行故障轉(zhuǎn)移唁盏。

cluster-node-timeout

Cluster 集群中節(jié)點(diǎn)互聯(lián)超時(shí)時(shí)間 ,默認(rèn)15s

cluster-require-full-coverage

默認(rèn)是yes

集群所有主節(jié)點(diǎn)狀態(tài)為ok才提供服務(wù)内狸。建議設(shè)置為no，可以在slot沒(méi)有全部分配的時(shí)候提供服務(wù)厘擂。

cluster-migration-barrier

cluster-migration-barrier默認(rèn)值

只有當(dāng)一個(gè)主節(jié)點(diǎn)至少擁有其他給定數(shù)量個(gè)處于正常工作中的從節(jié)點(diǎn)的時(shí)候昆淡，才會(huì)分配從節(jié)點(diǎn)給集群中孤立的主節(jié)點(diǎn)。這個(gè)給定數(shù)量就是migration barrier刽严。migration barrier 是1意味著一個(gè)從節(jié)點(diǎn)只有在其主節(jié)點(diǎn)另外至少還有一個(gè)正常工作的從節(jié)點(diǎn)的情況下才會(huì)被分配...

注：孤立的主節(jié)點(diǎn):原本有slave昂灵，但slave離線(xiàn)的master,本身沒(méi)有slave的master不屬于孤立主節(jié)點(diǎn)。

min-slaves-to-write默認(rèn)

master必須最少擁有的slave ,否則不允許寫(xiě)入 舞萄，默認(rèn)值為 0 眨补，表示禁用此特性

image.png

min-slaves-max-lag默認(rèn)

限制slave延遲的最大時(shí)間，如超過(guò)這個(gè)時(shí)間,master拒絕寫(xiě)入

slave-serve-stale-data

設(shè)置從庫(kù)是否可對(duì)外提供服務(wù)

• slave-serve-stale-data參數(shù)設(shè)置成yes倒脓，主從復(fù)制中撑螺，從服務(wù)器可以響應(yīng)客戶(hù)端請(qǐng)求；

• slave-serve-stale-data參數(shù)設(shè)置成no崎弃，主從復(fù)制中甘晤，從服務(wù)器將阻塞所有請(qǐng)求含潘，有客戶(hù)端請(qǐng)求時(shí)返回“SYNC with master in progress”

二、常見(jiàn)問(wèn)題

2.1 redis鏈接超時(shí)

異诚呋椋現(xiàn)象：

redis應(yīng)用鏈接超時(shí)遏弱，zabbix監(jiān)控鏈接超時(shí)獲取不到監(jiān)控?cái)?shù)據(jù) ，Linux系統(tǒng)層面,redis進(jìn)程所在的cpu節(jié)點(diǎn) 塞弊，cpu使用率100% 腾窝，可用內(nèi)存比較多(free 比較小 ，cache比較多),磁盤(pán)寫(xiě)比較高居砖，cpu sys 時(shí)間占比非常高虹脯。

磁盤(pán)現(xiàn)象：

image.png

Cpu 現(xiàn)象：

image.png

內(nèi)存狀態(tài)：

image.png

分析：

通過(guò)查看redis錯(cuò)誤日志，發(fā)現(xiàn)redis 6443實(shí)例正在執(zhí)行aof rewrite操作奏候。通過(guò)對(duì)比之前zabbix監(jiān)控和aof rewrite時(shí)間點(diǎn)循集，幾乎redis6443實(shí)例每次進(jìn)行aof操作的時(shí)候 Linux出現(xiàn)以上現(xiàn)象(鏈接超時(shí)，cpu高) 蔗草。

image.png

從日志中分析可以看出咒彤，在進(jìn)行aof rewrite 的時(shí)，Linux額外分配了差不多60G的內(nèi)存給redis的fork進(jìn)程咒精，而此時(shí)free內(nèi)存不足60g理論上應(yīng)該使用cache镶柱，但是從表象上看，并沒(méi)有直接使用cache模叙，而是在使用cache之前做了部分清理工作(cpu sys 時(shí)間比較高)歇拆，騰出部分空閑空間 。

臨時(shí)解決方案：清理cache

echo 1 > /proc/sys/vm/drop_caches

問(wèn)題得到臨時(shí)解決

永久解決方案：關(guān)掉 Linux的透明大頁(yè)

臨時(shí)關(guān)閉：

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

永久關(guān)閉

image.png

2.2 io 報(bào)錯(cuò)

I/O error reading bulk count from MASTER: Operation now in progress

image.png

調(diào)整 client-output-buffer-limit 解決

127.0.0.1:9003> config get client-output-buffer-limit

• "client-output-buffer-limit"

• "normal 0 0 0 slave 0 0 0 pubsub 33554432 8388608 60"

1. 對(duì)于普通客戶(hù)端來(lái)說(shuō)范咨，限制為0故觅，也就是不限制。因?yàn)槠胀蛻?hù)端通常采用阻塞式的消息應(yīng)答模式渠啊，何謂阻塞式呢输吏？如：發(fā)送請(qǐng)求，等待返回替蛉，再發(fā)送請(qǐng)求贯溅，再等待返回。這種模式下躲查，通常不會(huì)導(dǎo)致Redis服務(wù)器輸出緩沖區(qū)的堆積膨脹它浅；2. 對(duì)于Pub/Sub客戶(hù)端（也就是發(fā)布/訂閱模式），大小限制是8M熙含，當(dāng)輸出緩沖區(qū)超過(guò)8M時(shí)罚缕，會(huì)關(guān)閉連接。持續(xù)性限制是怎静，當(dāng)客戶(hù)端緩沖區(qū)大小持續(xù)60秒超過(guò)2M邮弹，則關(guān)閉客戶(hù)端連接；3. 對(duì)于slave客戶(hù)端來(lái)說(shuō)蚓聘，大小限制是256M腌乡，持續(xù)性限制是當(dāng)客戶(hù)端緩沖區(qū)大小持續(xù)60秒超過(guò)64M，則關(guān)閉客戶(hù)端連接夜牡。

2.3 aof文件損壞

出錯(cuò)過(guò)程：

實(shí)例在將aof文件讀取到內(nèi)存時(shí)与纽，中斷，redis進(jìn)程自動(dòng)關(guān)閉

日志報(bào)錯(cuò)：

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. [2716] 28 Apr 10:17:27.915 # Bad file format reading the append only file: make a backup of your AOF file, then use./redis-check-aof --fix <filename> [2761] 28 Apr 10:19:40.866 * Increased maximum number of open files to 10032 (it was originally set to 1024)

解決方法：

使用redis-check-aof修復(fù)aof文件塘装，操作命令如下：

$：redis-check-aof --fix appendonly.aof

然后重新啟動(dòng)redis

2.4 新增節(jié)點(diǎn)至redis集群時(shí)報(bào)錯(cuò)

報(bào)錯(cuò)信息：

[ERR] Node 10.1.193.209:8006 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0.

原因：

新增節(jié)點(diǎn)不為空 解決：刪除新增節(jié)點(diǎn)的node.file急迂，aof文件，flushdb或者kill進(jìn)程重新建立節(jié)點(diǎn)（有時(shí)候/var/run/下面沒(méi)有進(jìn)程文件蹦肴，導(dǎo)致進(jìn)程沒(méi)有關(guān)閉）僚碎。到這里redis系列文章就暫時(shí)完結(jié)了，感謝大家的閱讀和支持阴幌，后續(xù)將持續(xù)更新其他系列技術(shù)文章勺阐。

程序員的核心競(jìng)爭(zhēng)力其實(shí)還是技術(shù)，因此對(duì)技術(shù)還是要不斷的學(xué)習(xí)矛双，關(guān)注 “IT 巔峰技術(shù)” 公眾號(hào) 渊抽，該公眾號(hào)內(nèi)容定位：中高級(jí)開(kāi)發(fā)、架構(gòu)師议忽、中層管理人員等中高端崗位服務(wù)的懒闷，除了技術(shù)交流外還有很多架構(gòu)思想和實(shí)戰(zhàn)案例。

作者是 《 消息中間件 RocketMQ 技術(shù)內(nèi)幕》 一書(shū)作者栈幸，同時(shí)也是 “RocketMQ 上海社區(qū)”聯(lián)合創(chuàng)始人毛雇，曾就職于拼多多、德邦等公司侦镇，現(xiàn)任上市快遞公司架構(gòu)負(fù)責(zé)人灵疮，主要負(fù)責(zé)開(kāi)發(fā)框架的搭建、中間件相關(guān)技術(shù)的二次開(kāi)發(fā)和運(yùn)維管理壳繁、混合云及基礎(chǔ)服務(wù)平臺(tái)的建設(shè)震捣。