簡(jiǎn)介一份面向 CentOS 7.x 環(huán)境搭建 Redis 集群的自動(dòng)化部署腳本包服務(wù)于需要快速驗(yàn)證集群方案的運(yùn)維與后端開發(fā)者把主從復(fù)制、16384 個(gè)槽位分配、故障轉(zhuǎn)移等集群要點(diǎn)固化為可一鍵執(zhí)行的流程免去逐臺(tái)手工編譯與配置的重復(fù)勞動(dòng)。壓縮包共 5 個(gè)文件、約 1.86MB以 3 個(gè) sh 腳本為主體分別承擔(dān)主流程調(diào)度、Redis 安裝配置與集群卸載清理另含 redis-5.0.0.tar.gz 源碼包和一份 txt 使用說明覆蓋從解壓編譯到集群成型的完整環(huán)節(jié)已有 777 人學(xué)習(xí)。按說明修改 IP 與端口變量后依次執(zhí)行即可完成依賴安裝、編譯、節(jié)點(diǎn)配置與集群創(chuàng)建卸載腳本便于回收實(shí)例與殘留配置腳本中的變量定義、條件判斷與循環(huán)結(jié)構(gòu)也可作為編寫同類自動(dòng)化部署腳本的參考。對(duì)初次接觸集群部署的讀者還可借此理解節(jié)點(diǎn)角色劃分與槽位分配在真實(shí)環(huán)境中的含義并沿著腳本順序梳理常見故障的排查方向。1. 手工搭三主三從熬到凌晨這份 Redis 集群一鍵部署腳本省掉的四件事三臺(tái) CentOS 機(jī)器、六個(gè) Redis 實(shí)例我第一次手工搭集群從下午兩點(diǎn)折騰到凌晨配置文件手改六遍meet 完節(jié)點(diǎn)卡在 handshake最后發(fā)現(xiàn)是 17000 端口沒放行。后來(lái)拿到這份 redis 集群一鍵自動(dòng)部署腳本.rar真正省事的不是redis-cli --cluster create那一行而是它前面那堆重復(fù)勞動(dòng)——批量生成 conf、按順序拉起實(shí)例、把客戶端端口和集群總線端口一起放通、創(chuàng)建完再跑一遍 check 把狀態(tài)確認(rèn)下來(lái)。這套東西是 shell 寫的貼著 CentOS 的 systemctl、firewalld、sysctl 走沒有額外運(yùn)行時(shí)依賴幾百行讀一遍就能按自己的機(jī)器改。它適合三類人手上只有兩三臺(tái)測(cè)試機(jī)、需要反復(fù)重建集群做課程設(shè)計(jì)或壓測(cè)的線上出過槽位故障、想在預(yù)發(fā)環(huán)境原樣復(fù)現(xiàn)的以及剛接觸 Redis Cluster、想先跑通再回頭補(bǔ)原理的。下面從機(jī)制講到執(zhí)行鏈路再講翻車點(diǎn)。2. 槽位、總線與選舉一鍵腳本必須替你做對(duì)的四個(gè)集群機(jī)制腳本只做「生成配置、拉進(jìn)程、建集群」三件事但每一件背后都?jí)褐?Redis Cluster 的運(yùn)行時(shí)規(guī)則。不理解這四條腳本跑掛了連日志該往哪看都不知道。反過來(lái)理解了這四條腳本里那些看起來(lái)多余的 sleep、循環(huán)和判斷你就知道它在防什么。2.1 16384 個(gè)槽位怎么分腳本為什么默認(rèn)給三主Redis Cluster 把整個(gè)鍵空間切成 16384 個(gè)槽key 落到哪個(gè)槽由CRC16(key) mod 16384決定槽再歸某個(gè)主節(jié)點(diǎn)管?？蛻舳四玫?MOVED 重定向后自己緩存槽位表所以集群的核心不是「數(shù)據(jù)分片存儲(chǔ)」這件事本身而是「槽位歸屬必須全集群一致」。任何一個(gè)槽沒有主人集群在cluster-require-full-coverage yes默認(rèn)值下會(huì)直接拒絕所有寫請(qǐng)求。一鍵腳本之所以默認(rèn)三主三從不是審美選擇是硬約束--cluster-replicas 1要求主節(jié)點(diǎn)數(shù)至少 3因?yàn)楣收限D(zhuǎn)移要靠主節(jié)點(diǎn)多數(shù)派投票兩個(gè)主節(jié)點(diǎn)掛一個(gè)就湊不出多數(shù)。三主是最小可用拓?fù)淠_本里如果寫成「節(jié)點(diǎn)數(shù) / 2」來(lái)算主節(jié)點(diǎn)數(shù)節(jié)點(diǎn)少于 6 個(gè)時(shí)就會(huì)算出 2 主create 階段直接報(bào)*** ERROR: Invalid configuration for cluster creation。槽位分配默認(rèn)是均分再取余16384 / 3 5461、5461、5462第三個(gè)主節(jié)點(diǎn)多拿 2 個(gè)槽。這個(gè)數(shù)字在很多巡檢腳本里被寫死成5461做斷言一旦集群做過 reshard 就會(huì)誤報(bào)。我的做法是只看cluster info里的cluster_slots_assigned:16384不校驗(yàn)單節(jié)點(diǎn)槽數(shù)。另外要記住集群模式只支持 db 0配置里寫databases 16不會(huì)報(bào)錯(cuò)但SELECT命令會(huì)被拒絕返回ERR SELECT is not allowed in cluster mode。涉及多 key 的操作必須落在同一個(gè)槽用 hash tag 把 key 的一部分用{}包起來(lái)比如user:{1001}:name和user:{1001}:age會(huì)被強(qiáng)制分到同一槽這是設(shè)計(jì)鍵名時(shí)就要定下來(lái)的事不是部署階段能補(bǔ)救的。2.2 cluster bus 與握手meet 之后到底發(fā)生了什么每個(gè)集群節(jié)點(diǎn)會(huì)額外監(jiān)聽一個(gè)「客戶端端口 10000」的總線端口7000 對(duì)應(yīng) 17000。節(jié)點(diǎn)之間交換 gossip 消息、投票、傳播槽位表都走這個(gè)端口用的是二進(jìn)制協(xié)議和客戶端協(xié)議不是一回事。手工搭集群最常見的卡點(diǎn)就在這里6379 能 telnet 通17000 不通cluster nodes里對(duì)方節(jié)點(diǎn)永遠(yuǎn)是handshake狀態(tài)日志里反復(fù)刷Unable to connect to MASTER。握手的完整鏈路是腳本對(duì) A 節(jié)點(diǎn)執(zhí)行CLUSTER MEET B_IP B_PORTA 通過總線端口連 B交換節(jié)點(diǎn)信息B 再把 A 的信息 gossip 給已知節(jié)點(diǎn)。所以只要有一個(gè)節(jié)點(diǎn)的總線端口不通整個(gè)集群就可能分裂成兩個(gè)互不可見的孤島而cluster_state在每個(gè)孤島內(nèi)部都顯示 ok。這就是為什么腳本里的防火墻規(guī)則必須成對(duì)出現(xiàn)客戶端端口段和總線端口段一起放少寫一行就是幾小時(shí)的排查。還有個(gè)容易被忽略的點(diǎn)節(jié)點(diǎn)的 node id 存在cluster-config-file指定的文件里默認(rèn)叫nodes.conf。這個(gè)文件是 Redis 自己維護(hù)的腳本絕對(duì)不能刪、不能提前創(chuàng)建、不能手改。刪掉它的后果是節(jié)點(diǎn)重啟后生成新 id其他節(jié)點(diǎn)還拿著舊 id 做 gossip集群視圖徹底錯(cuò)亂。我在腳本里見過用rm -rf $DATA_DIR/*做「清理重來(lái)」的寫法看著干凈實(shí)際上把 nodes.conf 一起干掉了第二次執(zhí)行必翻車。2.3 主從復(fù)制與自動(dòng)故障轉(zhuǎn)移的判定鏈路從節(jié)點(diǎn)默認(rèn)每秒向主節(jié)點(diǎn)發(fā)REPLCONF ACK主節(jié)點(diǎn)把復(fù)制偏移量記在內(nèi)存里。某個(gè)主節(jié)點(diǎn)失聯(lián)后其余主節(jié)點(diǎn)在cluster-node-timeout默認(rèn) 15000 毫秒之后把它標(biāo)記為fail然后由持有該主節(jié)點(diǎn)槽位的從節(jié)點(diǎn)發(fā)起選舉拿到多數(shù)主節(jié)點(diǎn)投票后提升為主接管槽位。整個(gè)過程腳本管不了但腳本里的兩個(gè)參數(shù)直接決定它能不能成。一個(gè)參數(shù)是cluster-node-timeout。設(shè)太小網(wǎng)絡(luò)抖一下就觸發(fā)主從切換切完數(shù)據(jù)還沒同步完又切回來(lái)設(shè)太大真掛了要等半分鐘以上才恢復(fù)。生產(chǎn)上給 15000 到 30000 之間比較穩(wěn)測(cè)試機(jī)可以給 5000 加快演練節(jié)奏。另一個(gè)是cluster-replica-validity-factor默認(rèn) 10從節(jié)點(diǎn)斷線時(shí)間超過node-timeout × factor就失去競(jìng)選資格這是防止用一份過期數(shù)據(jù)頂上去的保護(hù)。把它設(shè)成 0 表示不管斷多久都能選只在「寧可丟數(shù)據(jù)也要?？捎谩沟膱?chǎng)景下才這么干。從節(jié)點(diǎn)能不能被選中還要看它的復(fù)制偏移量和主節(jié)點(diǎn)差多少。如果腳本為了讓啟動(dòng)快把repl-diskless-sync之類的東西亂調(diào)或者從節(jié)點(diǎn)剛起來(lái)還沒完成全量同步就被拉進(jìn)集群選舉時(shí)它的 offset 落后太多同樣會(huì)被其他主節(jié)點(diǎn)拒絕。所以腳本里「拉起實(shí)例」和「cluster create」之間應(yīng)該留幾秒讓復(fù)制鏈路建立這個(gè) sleep 不是玄學(xué)是在等master_link_status:up。2.4 節(jié)點(diǎn)順序與副本錯(cuò)位腳本里最容易寫錯(cuò)的一段邏輯redis-cli --cluster create的節(jié)點(diǎn)列表順序是有語(yǔ)義的前 N 個(gè)被當(dāng)作主節(jié)點(diǎn)后面按順序分配給它們做從節(jié)點(diǎn)。如果參數(shù)寫成--cluster-replicas 1列表是A B C D E F那 A B C 是主D E F 依次是 A B C 的從。但這個(gè)「依次」是按主機(jī)和端口的排列算的腳本如果用兩層 for 循環(huán)先生成所有 7000 端口再生成所有 7001 端口最終可能出現(xiàn)三個(gè)主節(jié)點(diǎn)全在同一臺(tái)物理機(jī)上另一臺(tái)機(jī)器上的三個(gè)從節(jié)點(diǎn)全在等它掛——機(jī)器一斷電集群直接沒了一半。正確的做法是按機(jī)器交錯(cuò)排列每臺(tái)機(jī)器出兩個(gè)實(shí)例列表寫成A:7000 A:7001 B:7000 B:7001 C:7000 C:7001這樣主節(jié)點(diǎn)天然分散在三臺(tái)機(jī)器上從節(jié)點(diǎn)也落在不同的物理機(jī)。腳本里如果做了「按 IP 分組再拼接」的處理讀的時(shí)候要確認(rèn)它是交錯(cuò)而不是分段。這一點(diǎn)在驗(yàn)收時(shí)可以用redis-cli --cluster check輸出的主從對(duì)應(yīng)關(guān)系直接看出來(lái)從節(jié)點(diǎn)和它的主節(jié)點(diǎn)在同一臺(tái)機(jī)器上就是錯(cuò)位了。還有一種錯(cuò)位是端口和目錄沒對(duì)上。同一個(gè) IP 上跑 7000 和 7001 兩個(gè)實(shí)例配置里的dir必須是兩個(gè)不同目錄logfile、pidfile、dbfilename也都得帶端口后綴。腳本如果只替換了port而沒替換dir兩個(gè)實(shí)例會(huì)往同一個(gè) dump 文件里寫AOF 也會(huì)互相覆蓋癥狀是集群能建起來(lái)但一重啟數(shù)據(jù)就亂。3. 解包看結(jié)構(gòu)CentOS 上的目錄、系統(tǒng)參數(shù)與端口三件套拿到 rar 之后第一件事不是急著bash deploy.sh而是先看清包里有什么、它假設(shè)你的機(jī)器處于什么狀態(tài)。這類腳本的失敗八成不是腳本邏輯錯(cuò)而是它默認(rèn)的前置條件在你的機(jī)器上不成立。3.1 壓縮包里的文件各管什么rar 在 CentOS 上默認(rèn)解不開需要先裝unrar很多最小化安裝的鏡像里沒有這個(gè)包得先配好軟件源再裝。解出來(lái)的目錄結(jié)構(gòu)各家寫法不同但職責(zé)基本是固定的幾類讀之前先按下面這張表對(duì)一遍缺哪個(gè)文件就知道腳本會(huì)缺哪一步文件/目錄典型職責(zé)缺了會(huì)怎樣deploy.sh主入口串起檢查、生成、啟動(dòng)、建集群無(wú)法一鍵執(zhí)行redis.conf.tpl配置模板用變量占位端口、目錄、密碼生成的配置全是默認(rèn)值nodes.list/hosts.conf節(jié)點(diǎn) IP 與端口清單腳本不知道往哪幾臺(tái)機(jī)器鋪start_all.sh/stop_all.sh批量拉起與停止實(shí)例只能手工 ps 后 killcheck_cluster.sh建完集群后的狀態(tài)校驗(yàn)出問題沒有統(tǒng)一出口redis-*.tar.gz源碼包或二進(jìn)制包需要自己準(zhǔn)備同版本安裝包README端口、密碼、目錄約定參數(shù)只能靠讀腳本猜讀腳本時(shí)優(yōu)先確認(rèn)三件事REDIS_HOME裝在哪、DATA_DIR數(shù)據(jù)落在哪、密碼是寫死在腳本里還是從外部傳入。寫死密碼的腳本在多人共用的測(cè)試環(huán)境里很常見改的時(shí)候記得同步改requirepass和masterauth兩處只改一處集群建不起來(lái)。3.2 CentOS 7/8 必須先改的四個(gè)內(nèi)核與資源項(xiàng)Redis 在集群模式下對(duì)系統(tǒng)資源更敏感因?yàn)槎嗔丝偩€連接和節(jié)點(diǎn)間心跳。以下四項(xiàng)如果腳本里沒做建議在執(zhí)行前手工補(bǔ)上用sysctl落成配置文件比sysctl -w臨時(shí)改可靠重啟不丟# /etc/sysctl.d/99-redis-cluster.conf # 允許內(nèi)存過量提交否則 fork 做 RDB 落盤時(shí)可能直接失敗 vm.overcommit_memory 1 # 監(jiān)聽隊(duì)列長(zhǎng)度低于 511 時(shí)高并發(fā)下會(huì)出現(xiàn)連接被丟棄 net.core.somaxconn 1024 # 盡量不使用 swap避免節(jié)點(diǎn)間心跳因換頁(yè)抖動(dòng)而超時(shí) vm.swappiness 1 # 關(guān)閉透明大頁(yè)THP 會(huì)造成 Redis 的 fork 延遲 spikes echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag sysctl --systemvm.overcommit_memory這一項(xiàng)是最容易被忽略的日志里表現(xiàn)為Background save is starting之后跟一條fork: Cannot allocate memory進(jìn)程直接沒了而這臺(tái)機(jī)器內(nèi)存看起來(lái)還很空閑。原因不是內(nèi)存不夠是內(nèi)核在 fork 時(shí)按 overcommit 策略拒絕了地址空間申請(qǐng)。somaxconn則對(duì)應(yīng)TCP: request_sock_TCP: Possible SYN flooding這類告警連接數(shù)一上來(lái)就丟包。文件描述符也得提。Redis 默認(rèn)建議ulimit -n不低于 10032systemd 拉起的服務(wù)要在 unit 文件里寫LimitNOFILE10032光改/etc/security/limits.conf對(duì) systemd 服務(wù)不生效這是 CentOS 7 之后非常常見的坑。腳本如果用redis-server xxx.conf 的方式啟動(dòng)繼承的是當(dāng)前 shell 的限制換個(gè)終端執(zhí)行結(jié)果就不一樣我一般讓腳本顯式ulimit -n 10032再拉進(jìn)程。3.3 端口放行7000-7005 只是其中一半六個(gè)實(shí)例用 7000 到 7005客戶端連這些端口沒問題但節(jié)點(diǎn)之間要走 17000 到 17005只放前半段的表現(xiàn)是cluster nodes里其他節(jié)點(diǎn)一直是handshake或者已經(jīng)connected但cluster_state:fail日志刷Cluster bus: connection refused。firewalld 的寫法是一次把兩段都加上# 客戶端端口段 firewall-cmd --permanent --add-port7000-7005/tcp # 集群總線端口段 客戶端端口 10000 firewall-cmd --permanent --add-port17000-17005/tcp firewall-cmd --reload firewall-cmd --list-ports如果機(jī)器在云上安全組是另一道門firewall-cmd --list-ports有輸出不代表外部能進(jìn)來(lái)。驗(yàn)證方式是換一臺(tái)機(jī)器用telnet 目標(biāo)IP 17000或者nc -zv 目標(biāo)IP 17000試本地ss -lntp | grep 1700看到監(jiān)聽只說明本機(jī)進(jìn)程起來(lái)了跟網(wǎng)絡(luò)可達(dá)是兩件事。還有個(gè)細(xì)節(jié)如果同一臺(tái)機(jī)器上跑多個(gè)實(shí)例bind建議寫內(nèi)網(wǎng) IP 而不是0.0.0.0同時(shí)把protected-mode關(guān)掉集群模式和多節(jié)點(diǎn)訪問下通常要關(guān)并且顯式設(shè)置cluster-announce-ip為內(nèi)網(wǎng)地址。多網(wǎng)卡機(jī)器上不設(shè)這一項(xiàng)節(jié)點(diǎn)會(huì)把自己廣播成 127.0.0.1 或者某塊業(yè)務(wù)網(wǎng)卡的地址其他節(jié)點(diǎn)按這個(gè)地址連總線端口永遠(yuǎn)連不上。4. 從零跑一遍配置生成、實(shí)例拉起、cluster create 的完整鏈路這一章按執(zhí)行順序走一遍每一步給出關(guān)鍵命令和需要核對(duì)的輸出。腳本再自動(dòng)這四步的中間產(chǎn)物你都應(yīng)該知道長(zhǎng)什么樣否則出問題只能干等。4.1 生成六份 redis.conf用循環(huán)替掉手改配置模板的核心是集群相關(guān)的那幾行端口、目錄、密碼用變量替換。手寫六份的失敗率遠(yuǎn)高于想象一份漏了cluster-enabled yescreate 階段就報(bào)Node xxx is not configured as a cluster node。用循環(huán)生成模板只維護(hù)一份#!/usr/bin/env bash set -euo pipefail BASE_PORT7000 DATA_ROOT/data/redis-cluster NODES(10.0.0.11 10.0.0.12 10.0.0.13) PASSWORDChangeMe_2024 for ip in ${NODES[]}; do for idx in 0 1; do port$((BASE_PORT idx)) dir${DATA_ROOT}/${port} mkdir -p ${dir} cat ${dir}/redis.conf EOF port ${port} bind ${ip} protected-mode no daemonize yes pidfile ${dir}/redis.pid logfile ${dir}/redis.log dir ${dir} dbfilename dump-${port}.rdb appendonly yes appendfilename appendonly-${port}.aof # 集群三件套開關(guān)、節(jié)點(diǎn)狀態(tài)文件、失聯(lián)判定毫秒數(shù) cluster-enabled yes cluster-config-file nodes-${port}.conf cluster-node-timeout 15000 cluster-announce-ip ${ip} cluster-announce-port ${port} cluster-announce-bus-port $((port 10000)) # 密碼必須兩處一致否則從節(jié)點(diǎn)同步和集群創(chuàng)建都會(huì)失敗 requirepass ${PASSWORD} masterauth ${PASSWORD} EOF done done幾個(gè)參數(shù)值得單獨(dú)說。cluster-config-file帶上端口后綴避免同機(jī)多實(shí)例互相覆蓋這個(gè)文件由 Redis 維護(hù)腳本只負(fù)責(zé)給路徑。cluster-announce-ip顯式寫成當(dāng)前機(jī)器的內(nèi)網(wǎng) IP多網(wǎng)卡環(huán)境下這是唯一可靠的廣播地址來(lái)源。appendonly yes在集群里建議打開從節(jié)點(diǎn)提升為主后如果只有 RDB最后一個(gè) RDB 之后的數(shù)據(jù)就丟了。daemonize yes讓實(shí)例后臺(tái)跑腳本里要跟一個(gè)循環(huán)等待端口就緒不能生成完就立刻建集群。路徑權(quán)限也要順手檢查${dir}必須對(duì)運(yùn)行 Redis 的用戶可寫用 root 生成目錄、用 redis 用戶起進(jìn)程是常見組合權(quán)限沒給對(duì)的表現(xiàn)是啟動(dòng)即退出日志里一行Cant open the append-only file: Permission denied。4.2 拉起實(shí)例并確認(rèn)端口真的在監(jiān)聽啟動(dòng)之后不要相信daemonize的返回值它只表示 fork 成功不表示配置正確。判斷標(biāo)準(zhǔn)是端口在監(jiān)聽且PING有回應(yīng)這一步放在腳本里就是一個(gè)帶超時(shí)的輪詢#!/usr/bin/env bash # 逐臺(tái)啟動(dòng)并按端口探活超過 30 秒未就緒就打印日志尾巴退出 for ip in 10.0.0.11 10.0.0.12 10.0.0.13; do for port in 7000 7001; do ssh ${ip} redis-server ${DATA_ROOT}/${port}/redis.conf for i in $(seq 1 30); do if redis-cli -h ${ip} -p ${port} -a ChangeMe_2024 --no-auth-warning ping 2/dev/null | grep -q PONG; then echo OK ${ip}:${port} break fi sleep 1 done redis-cli -h ${ip} -p ${port} -a ChangeMe_2024 --no-auth-warning ping \ | grep -q PONG || { tail -n 30 ${DATA_ROOT}/${port}/redis.log; exit 1; } done done這里用--no-auth-warning只是避免密碼提示刷屏腳本里不要把密碼明文寫進(jìn) history正式環(huán)境建議用REDISCLI_AUTH環(huán)境變量傳。探活只看PING還不夠集群模式下要再確認(rèn)cluster-enabled:yes和cluster_state的初始值剛啟動(dòng)的節(jié)點(diǎn)應(yīng)該是cluster_state:fail、cluster_known_nodes:1這屬于正常狀態(tài)說明它以單節(jié)點(diǎn)身份起來(lái)了等著被 meet。如果某個(gè)端口一直起不來(lái)先看日志最后 30 行再看ss -lntp | grep 端口有沒有別的進(jìn)程占著。測(cè)試機(jī)上經(jīng)常出現(xiàn)上一次的實(shí)例沒殺干凈pidfile 殘留導(dǎo)致新進(jìn)程以為自己在跑daemonize yes下這種問題特別隱蔽。4.3 cluster create 的節(jié)點(diǎn)順序與副本分配六個(gè)節(jié)點(diǎn)都活了之后才能建集群節(jié)點(diǎn)列表按「主機(jī)交錯(cuò)、主節(jié)點(diǎn)在前」的順序排。Redis 5 之后--cluster子命令是內(nèi)建的不需要額外裝 ruby 的 redis-tribredis-cli --cluster create \ 10.0.0.11:7000 10.0.0.12:7000 10.0.0.13:7000 \ 10.0.0.11:7001 10.0.0.12:7001 10.0.0.13:7001 \ --cluster-replicas 1 \ -a ChangeMe_2024 --cluster-yes前三個(gè)是主節(jié)點(diǎn)后三個(gè)按順序做它們的從節(jié)點(diǎn)所以 7001 的三個(gè)實(shí)例分別跟著三個(gè) 7000 主節(jié)點(diǎn)且從節(jié)點(diǎn)都不在同一個(gè) IP 上——這就是 2.4 里說的交錯(cuò)排列。--cluster-yes跳過多余的交互確認(rèn)腳本里必須加否則會(huì)卡在Can I set the above configuration? (type yes to accept)等人輸入。-a在帶密碼集群里要給且必須和配置里的requirepass一致。執(zhí)行過程中會(huì)看到每個(gè)主節(jié)點(diǎn)分到5461/5461/5462個(gè)槽接著是Waiting for the cluster to join這一步耗時(shí)取決于總線端口是否通。如果卡在這里超過一分鐘別等直接去另一臺(tái)機(jī)器上看telnet 目標(biāo)IP 17000是否可達(dá)九成是端口或cluster-announce-ip的問題。4.4 用 cluster check 把狀態(tài)釘死創(chuàng)建命令返回成功不代表集群健康必須再跑一遍 check它會(huì)逐個(gè)節(jié)點(diǎn)連過去核對(duì)槽位覆蓋和主從關(guān)系redis-cli --cluster check 10.0.0.11:7000 -a ChangeMe_2024 # 關(guān)鍵看三行 # [OK] All 16384 slots covered. # 每個(gè) master 下列出的 slots 區(qū)間與 replica 數(shù)量 # [OK] All nodes agree about slots configuration.All nodes agree about slots configuration這句是核心它表示各節(jié)點(diǎn)的槽位視圖已經(jīng)收斂一致。如果這里報(bào)Different slots configuration說明有節(jié)點(diǎn)的信息還沒 gossip 到等幾秒重跑如果一直不一致檢查是不是有節(jié)點(diǎn)被 meet 過兩次、在集群里留了重復(fù)條目。驗(yàn)收時(shí)我會(huì)把 check 的輸出存一份到日志目錄后面擴(kuò)容、遷移、重啟都可以拿來(lái)對(duì)比。5. 避坑與排查cluster_state:ok 之后仍然會(huì)翻車的五個(gè)場(chǎng)景集群建起來(lái)、狀態(tài) ok只說明拓?fù)涑闪⒉淮順I(yè)務(wù)能用。下面五個(gè)是我和同事在不同機(jī)器上真實(shí)踩過的癥狀看起來(lái)都不像集群?jiǎn)栴}根因全在配置和端口上。5.1 客戶端一直報(bào) MOVED狀態(tài)卻是 ok現(xiàn)象應(yīng)用連上 7000 寫一個(gè) key報(bào)MOVED 12345 10.0.0.12:7000程序里沒做重定向處理直接拋異常。集群側(cè)CLUSTER INFO顯示一切正常。原因客戶端沒開集群模式把 Redis 當(dāng)成單機(jī)在用。MOVED 不是錯(cuò)誤是告訴客戶端這個(gè)槽在別的節(jié)點(diǎn)集群感知客戶端會(huì)自動(dòng)跟隨并緩存槽位表單機(jī)客戶端則把重定向當(dāng)異常拋出來(lái)。另一種變體是連的是代理或 VIP請(qǐng)求被固定轉(zhuǎn)發(fā)到某一臺(tái)槽位表永遠(yuǎn)變不過來(lái)。解決換成客戶端庫(kù)的集群模式初始化方式連接時(shí)給出全部種子節(jié)點(diǎn)而不是一個(gè) VIP。如果確實(shí)只能給單地址必須在中間層做槽位感知轉(zhuǎn)發(fā)不能做四層負(fù)載均衡——四層會(huì)把同一個(gè)連接的所有請(qǐng)求固定到同一節(jié)點(diǎn)跨槽訪問必然失敗。5.2 節(jié)點(diǎn)卡在 handshake 半天不動(dòng)現(xiàn)象cluster nodes里某個(gè)節(jié)點(diǎn)狀態(tài)是handshakecluster info的cluster_known_nodes比實(shí)際節(jié)點(diǎn)數(shù)少日志反復(fù)刷Unable to connect to node。原因總線端口不通或者節(jié)點(diǎn)廣播的地址是 127.0.0.1、某塊業(yè)務(wù)網(wǎng)卡地址。前者是防火墻只放了 7000 段后者是多網(wǎng)卡機(jī)器沒設(shè)cluster-announce-ip節(jié)點(diǎn)按默認(rèn)網(wǎng)卡地址互相通告對(duì)方連過去自然不通。解決把總線端口段補(bǔ)進(jìn)防火墻和安全組cluster-announce-ip顯式寫內(nèi)網(wǎng) IP 后重啟實(shí)例。已經(jīng)進(jìn)過集群的錯(cuò)誤節(jié)點(diǎn)不能直接改配置重啟要先CLUSTER RESET HARD清掉它的節(jié)點(diǎn)狀態(tài)再重新CLUSTER MEET否則舊地址會(huì)一直留在其他節(jié)點(diǎn)的視圖里。5.3 重啟之后集群整體 fail現(xiàn)象三臺(tái)機(jī)器重啟實(shí)例都起來(lái)了cluster_state:failcluster_slots_assigned遠(yuǎn)小于 16384部分主節(jié)點(diǎn)顯示fail?。原因腳本的清理邏輯把nodes-*.conf刪了節(jié)點(diǎn)重新生成 id全集群不認(rèn)它或者數(shù)據(jù)目錄權(quán)限變了節(jié)點(diǎn)讀不到原狀態(tài)文件只能當(dāng)新節(jié)點(diǎn)啟動(dòng)還有一種是從節(jié)點(diǎn)比主節(jié)點(diǎn)先起來(lái)且主節(jié)點(diǎn)長(zhǎng)時(shí)間未就緒從節(jié)點(diǎn)把自己降級(jí)成孤立狀態(tài)。解決nodes.conf絕對(duì)不刪。重啟順序先主后從腳本里加等待邏輯確認(rèn)所有主節(jié)點(diǎn)cluster_state恢復(fù)到 ok 再拉起從節(jié)點(diǎn)。真出現(xiàn)了 id 變更只能在剩下節(jié)點(diǎn)里用CLUSTER FORGET把舊條目錄掉再把故障節(jié)點(diǎn)以干凈狀態(tài)重新加回并遷移槽位這個(gè)操作要停機(jī)窗口。5.4 帶密碼的集群創(chuàng)建直接失敗現(xiàn)象redis-cli --cluster create輸出Node xxx replied with error: NOAUTH Authentication required或者從節(jié)點(diǎn)一直master_link_status:down。原因requirepass配了masterauth沒配或者值不一樣。requirepass管客戶端連它masterauth管它連主節(jié)點(diǎn)時(shí)用什么密碼集群里兩個(gè)方向都要通只配一處就是半通狀態(tài)。解決兩處寫成同一個(gè)值redis-cli --cluster相關(guān)命令帶-a或用REDISCLI_AUTH。改配置要六個(gè)節(jié)點(diǎn)全改一遍再重啟改完先用redis-cli -a 密碼 info replication確認(rèn)從節(jié)點(diǎn)master_link_status:up再跑--cluster check。5.5 擴(kuò)容加節(jié)點(diǎn)后槽位覆蓋不全現(xiàn)象新加兩個(gè)節(jié)點(diǎn)、遷移了部分槽過去--cluster check報(bào)Not all 16384 slots are covered但每個(gè)節(jié)點(diǎn)單獨(dú)看都正常。原因遷移過程中斷或者用了手工CLUSTER SETSLOT但漏了IMPORTING/MIGRATING兩步的收尾源節(jié)點(diǎn)把槽標(biāo)成遷移中目標(biāo)節(jié)點(diǎn)沒接管這個(gè)槽就懸空了。cluster-require-full-coverage yes下整個(gè)集群拒寫。解決用redis-cli --cluster reshard走完整流程不要手工拼SETSLOT。已經(jīng)懸空的槽用CLUSTER SETSLOT slot NODE node-id在相關(guān)節(jié)點(diǎn)上逐一修正修完跑 check 確認(rèn)All 16384 slots covered。注意以上所有涉及CLUSTER RESET、FORGET、SETSLOT的操作都有數(shù)據(jù)丟失風(fēng)險(xiǎn)先在測(cè)試環(huán)境完整走一遍再上預(yù)發(fā)。6. 把一鍵腳本用成可維護(hù)工具故障演練與巡檢的固定動(dòng)作腳本能建集群只是起點(diǎn)。真正決定這套東西能不能長(zhǎng)期用的是你能不能在一次執(zhí)行之后回答兩個(gè)問題故障切換要多久、下次重建要改哪幾行。我給自己的固定動(dòng)作是每次部署完做一次小型故障演練把切換時(shí)間記進(jìn)部署記錄后面遇到「集群是不是變慢了」這類問題時(shí)至少有基線可比。演練很簡(jiǎn)單找到某個(gè)主節(jié)點(diǎn)kill -9掉它的進(jìn)程然后每?jī)擅氩橐淮蝐luster info里的cluster_state和cluster_slots_assigned同時(shí)用redis-cli -c往這個(gè)主節(jié)點(diǎn)負(fù)責(zé)的槽寫 key看多久恢復(fù)寫入。默認(rèn)cluster-node-timeout 15000下30 秒內(nèi)完成切換屬于正常超過 45 秒就要檢查是不是只有兩個(gè)主節(jié)點(diǎn)、投票湊不齊多數(shù)。演練完把殺掉的實(shí)例重新拉起它會(huì)以從節(jié)點(diǎn)身份回歸用redis-cli --cluster check確認(rèn)主從關(guān)系復(fù)原。巡檢我習(xí)慣寫成一個(gè)小循環(huán)把每個(gè)節(jié)點(diǎn)的關(guān)鍵指標(biāo)拉成一行肉眼掃一遍就知道有沒有異常#!/usr/bin/env bash # 逐節(jié)點(diǎn)采集關(guān)鍵狀態(tài)輸出一行一個(gè)實(shí)例便于 diff 和歸檔 PASSChangeMe_2024 for ip in 10.0.0.11 10.0.0.12 10.0.0.13; do for port in 7000 7001; do info$(redis-cli -h ${ip} -p ${port} -a ${PASS} --no-auth-warning cluster info 2/dev/null) role$(redis-cli -h ${ip} -p ${port} -a ${PASS} --no-auth-warning info replication 2/dev/null | awk -F: /^role/{print $2} | tr -d \r) state$(echo ${info} | awk -F: /^cluster_state/{print $2} | tr -d \r) assigned$(echo ${info} | awk -F: /^cluster_slots_assigned/{print $2} | tr -d \r) printf %-12s %-5s role%-6s state%-5s slots%s\n ${ip} ${port} ${role} ${state} ${assigned} done done這個(gè)腳本的價(jià)值在于輸出穩(wěn)定、可以直接 diff部署前存一份、演練后存一份cluster_slots_assigned從 16384 掉了就說明有槽懸空role變了就說明發(fā)生過切換。比翻日志快得多也不用記復(fù)雜命令。最后是一個(gè)參數(shù)化的習(xí)慣。拿到這類腳本我第一件事是把BASE_PORT、NODES、PASSWORD、DATA_ROOT四個(gè)變量抽到單獨(dú)的cluster.env里腳本開頭source進(jìn)來(lái)第二件事是把生成的配置、check 輸出、演練記錄按時(shí)間戳落到logs/不做覆蓋。那次重啟后集群 fail 的經(jīng)歷之后我每次改腳本都會(huì)先在一臺(tái)干凈的虛擬機(jī)上從零跑兩遍確認(rèn)第二遍執(zhí)行不會(huì)因?yàn)闅埩裟夸泩?bào)錯(cuò)再看一遍nodes.conf有沒有被動(dòng)過——集群這東西一次省事的rm -rf能換來(lái)一整晚的恢復(fù)工作后悔藥是沒有的。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取