：從主從復制到哨兵模式與Cluster分片)
1. 為什么要用Docker搭Redis集群從單節(jié)點到主從哨兵的演進邏輯先說一個很多人問我的問題單機Redis用得好好的為什么要費勁搭集群這個問題其實分兩層。第一層如果你的業(yè)務量還沒到單節(jié)點扛不住的程度那確實不用折騰集群帶來的復雜度可能比收益還大。但第二層一旦你開始遇到這些信號——CPU持續(xù)打滿、內存快不夠用、寫并發(fā)上不去、或者最怕的Redis宕機導致緩存雪崩那集群就不僅僅是進階玩法而是必須做的功課了。我在實際項目里見過不少類似的情況某公司起初單節(jié)點Redis扛著全部緩存數據某天凌晨主節(jié)點突然宕機整個訂單列表都查不到緩存數據庫壓力瞬間拉滿差點出事故。當時的第一反應就是趕緊弄個高可用方案。而Docker恰好能把這個過程大幅簡化——你不需要準備多臺物理機或虛擬機在一臺機器上就能模擬出完整的集群拓撲開發(fā)環(huán)境驗證通了再平滑遷移到多機生產環(huán)境。用Docker搭Redis集群常見的方案有三種方案核心機制適用場景復雜度主從復制Replication主節(jié)點寫從節(jié)點同步備份讀寫分離、數據備份低哨兵模式Sentinel在主從基礎上增加監(jiān)控和自動故障轉移高可用自動切換中Redis Cluster多主多從數據分片存儲海量數據、高并發(fā)寫入高很多人把這三者搞混以為集群就是Redis Cluster。實際上廣義的Redis集群方案包含了上面的全部形態(tài)。本文會按照從易到難的順序完整走一遍Docker下的三種搭建方式并重點講講我在每一步踩過的坑。這也是我認為一篇實操文章最應該有的內容——不是給你一堆命令復制粘貼而是讓你知道每條命令為什么這么寫、出了問題怎么排查。適合讀者已經了解Docker基本命令run、exec、network和Redis基本概念的人。如果你連docker ps都還沒跑過建議先花半小時熟悉Docker基礎再回來。2. 環(huán)境準備網絡、鏡像和目錄規(guī)劃少一個后面都難受開始動手前先做三件事。很多人省略了這一步結果搭到一半才發(fā)現網絡不通、目錄權限不對、版本不兼容來回折騰的時間比重新搭一遍還長。2.1 創(chuàng)建Docker網絡為什么不能用默認bridgeRedis集群節(jié)點之間需要互相通信而且后續(xù)擴容、重啟容器時IP可能變化所以最穩(wěn)妥的方式是創(chuàng)建一個自定義網絡。默認的bridge網絡雖然也能用但容器間通過容器名互相訪問的能力受限DNS解析不穩(wěn)定。docker network create redis-net加個--subnet參數會更可控比如docker network create --subnet172.20.0.0/16 redis-net這個子網段可以自己定只要和宿主機現有網段不沖突即可。指定了子網后后續(xù)給容器分配固定IP就方便了哨兵模式下尤其有用。2.2 Redis鏡像版本選擇別盲目latest我見過太多人直接docker pull redis:latest結果某次升級后配置項變了排查半天才發(fā)現是鏡像版本問題。這里我建議明確指定版本。docker pull redis:7.0目前Redis 7.x是主流穩(wěn)定版本7.0、7.2都在維護周期內。Redis 6.x也還能用但新特性如Function、Acl改進缺失沒必要。用固定版本號有兩個好處其一是保證本地和線上環(huán)境一致其二是你百度搜到的問題解決方案跟你的版本對得上不至于被版本差異誤導。2.3 目錄規(guī)劃配置文件持久化Docker容器的文件系統(tǒng)是臨時的容器刪了數據就沒了。Redis雖然主要做緩存但開啟AOF持久化后數據文件必須放在宿主機上否則容器重建等于丟數據。我的習慣是每個節(jié)點一個目錄mkdir -p /opt/redis/{6379,6380,6381}以三節(jié)點哨兵模式為例6379、6380、6381分別對應三個Redis實例。生產環(huán)境多機部署時這個目錄結構可以原樣拷貝到其他機器上路徑一致還能減少配置差異導致的低級錯誤。此外還需要準備Redis配置文件。下面這三個文件的細節(jié)我會在對應的章節(jié)逐步展開這里先把最小的骨架立起來touch /opt/redis/6379/redis.conf注意掛載配置文件時容器內的路徑和宿主機路徑要一一對應。我用/opt/redis/6379/redis.conf宿主機文件掛載到容器內/etc/redis/redis.conf這樣改配置文件只需要動宿主機文件不用進容器操作。提示如果你用的是SELinux強制模式的Linux發(fā)行版掛載文件前可能要執(zhí)行chcon -Rt svirt_sandbox_file_t /opt/redis否則容器可能因為權限問題啟動失敗。這個坑比較隱蔽啟動報錯時優(yōu)先檢查。3. 主從復制搭建最小可用集群的一小步主從復制是理解后面所有方案的基礎。它做的事情一句話概括一個主節(jié)點master接收寫請求一個或多個從節(jié)點slave實時同步主節(jié)點的數據讀請求可以打到從節(jié)點上分擔壓力。3.1 啟動主節(jié)點先寫主節(jié)點的配置文件/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof這里daemonize no是因為容器里應該讓Redis以前臺方式運行如果設成yesRedis進程會后臺化容器會因為沒有前臺進程而退出。這是Docker運行Redis的第一個經典坑。然后啟動容器docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf啟動后驗證一下docker exec -it redis-master redis-cli ping如果返回PONG說明主節(jié)點正常。3.2 啟動從節(jié)點并指定主節(jié)點從節(jié)點的配置和主節(jié)點幾乎一樣區(qū)別在于多了replicaof指令。Redis 5.0之前這個指令叫slaveof5.0之后改名為replicaof更準確的語義老版本命令依然兼容。新項目一律用replicaof。/opt/redis/6380/redis.confport 6380 daemonize no appendonly yes appendfilename appendonly.aof replicaof redis-master 6379注意replicaof后面的主機名我直接用了容器名redis-master。在自定義網絡里容器名就是獨立的DNS名稱容器間可以互相ping通。這也是我之前強調要先建自定義網絡的原因。啟動從節(jié)點docker run -d \ --name redis-slave-1 \ --network redis-net \ -p 6380:6380 \ -v /opt/redis/6380:/data \ -v /opt/redis/6380/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf驗證主從是否連通docker exec -it redis-slave-1 redis-cli info replication重點看這幾行輸出role:slave master_host:redis-master master_link_status:upmaster_link_status:up表示主從連接正常。如果顯示down大概率是網絡不通或replicaof配置寫錯。我遇到過一種情況是容器啟動時主節(jié)點還沒準備好從節(jié)點重試幾次后自然恢復等1-2分鐘再看就up了不用急著改配置。3.3 主從復制的數據驗證和誤區(qū)糾正寫幾個key驗證一下docker exec -it redis-master redis-cli set name hello docker exec -it redis-slave-1 redis-cli get name如果在從節(jié)點能讀到hello說明復制鏈路通了。這里必須特別提醒一個誤區(qū)從節(jié)點默認是只讀的。從節(jié)點上執(zhí)行寫命令會報錯READONLY You cant write against a read only replica。這不是故障是設計如此。從節(jié)點只負責同步主節(jié)點數據和分擔讀請求寫請求永遠走主節(jié)點。另外主從復制是異步的。異步意味著極端情況下主節(jié)點剛收到寫請求還沒來得及同步給從節(jié)點就宕機了這部分數據會丟失。對緩存場景通?？梢越邮艿珜祿恢滦砸髽O高的業(yè)務需要借助Wait命令或者直接換更嚴格的中間件Redis本身并不是強一致性的數據庫。提示如果主節(jié)點開啟了密碼驗證從節(jié)點的配置里要加masterauth 密碼否則復制會不斷報錯。這個坑在主從模式下不常見本地測試通常不設密碼但一上生產環(huán)境很多人就在這里卡住。同樣從節(jié)點自己的requirepass也要根據情況加上。3.4 主從模式的實際局限主從復制解決了數據備份和讀寫分離但解決不了自動故障轉移。主節(jié)點宕機后從節(jié)點雖然握著最新數據卻不會自動升級為主節(jié)點。該怎么辦人工干預——登錄服務器手動執(zhí)行replicaof no one讓某個從節(jié)點轉正。人力操作必然存在延遲業(yè)務中斷時間不可控。于是有了哨兵Sentinel機制。4. 哨兵模式讓主從復制具備故障自愈能力哨兵的本質是一個獨立運行的Redis實例它不存數據只負責監(jiān)控主從節(jié)點的健康狀況并在主節(jié)點故障時自動把一個從節(jié)點提升為新的主節(jié)點。哨兵通常也是集群部署的至少3個避免單點故障——哨兵自己掛了就沒人監(jiān)控了。4.1 為什么至少要3個哨兵這里有個概念叫法定人數quorum。當某個哨兵認為主節(jié)點不可達時它不會立刻執(zhí)行故障轉移而是和其他哨兵協(xié)商。只有當認為主節(jié)點故障的哨兵數達到quorum值才會真正觸發(fā)切換。quorum常見配置是2共3個哨兵時這么設計是為了避免網絡分區(qū)導致的誤判——萬一主節(jié)點其實活著只是某個哨兵到它的網絡斷了單個哨兵的判斷并不可靠。如果你只部署1個哨兵它把主節(jié)點誤判為宕機然后執(zhí)行切換可能造成腦裂舊主節(jié)點還活著但哨兵又提拔了一個新主節(jié)點兩個主節(jié)點同時接受寫請求數據就亂了。所以生產環(huán)境至少3個哨兵。4.2 哨兵配置與容器啟動哨兵有自己的配置文件。/opt/redis/26379/sentinel.confport 26379 daemonize no sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1逐行解釋sentinel monitor監(jiān)控名為mymaster的主節(jié)點地址是redis-master:6379最后的2就是quorum值表示至少2個哨兵同意才執(zhí)行故障轉移。down-after-milliseconds連續(xù)5秒聯系不上主節(jié)點就判定為主觀下線。這個值不要設太小否則網絡抖動會導致頻繁誤判。failover-timeout故障轉移超時時間60秒內沒完成切換就重試。parallel-syncs新主節(jié)點確定后同時允許多少個從節(jié)點同步數據。設1表示逐個同步避免網絡瞬間壓力過大。啟動哨兵容器docker run -d \ --name redis-sentinel-1 \ --network redis-net \ -p 26379:26379 \ -v /opt/redis/26379:/data \ -v /opt/redis/26379/sentinel.conf:/etc/redis/sentinel.conf \ redis:7.0 \ redis-sentinel /etc/redis/sentinel.conf同樣的方式再啟動兩個哨兵節(jié)點端口26380、26381注意配置文件里的端口要各自改好。3個哨兵都啟動后通過日志可以確認它們彼此發(fā)現了對方docker logs redis-sentinel-1正常會看到類似sentinel sentinel的日志表示哨兵之間已經建立了互相通信。4.3 故障轉移實測手動殺掉主節(jié)點看效果很多人搭完哨兵就在那干看著壓根不知道好不好用。我建議直接做一次混沌測試——手動殺掉主節(jié)點容器看哨兵能不能自動切換。docker stop redis-master等待10-15秒超過down-after-milliseconds閾值然后觀察哨兵日志docker logs redis-sentinel-1 --tail 50會看到類似switch-master mymaster 172.20.0.2 6379 172.20.0.3 6380的日志表示已經把6380節(jié)點提升為新的主節(jié)點。然后檢查從節(jié)點docker exec -it redis-master redis-cli info replication注意這里舊主節(jié)點的容器雖然停了但重新啟動后它會發(fā)現集群里已經有了新主節(jié)點自動降級為從節(jié)點并開始同步新主節(jié)點數據。這是哨兵模式非常體貼的一個設計——故障恢復后舊主節(jié)點不會搶回主位置。4.4 哨兵模式的坑客戶端感知與密碼問題哨兵模式的第一個潛在坑在客戶端?？蛻舳诉B接Redis的URL需要從redis://...改為sentinel://...并且要指定哨兵地址和主節(jié)點名稱例如sentinel://172.20.0.10:26379,172.20.0.11:26379,172.20.0.12:26379/mymaster如果你把客戶端還配置成直連某個Redis節(jié)點的IP那么主節(jié)點切換后客戶端依然連著舊主節(jié)點的IP自然就不可用了。這也是哨兵模式部署完以后必須重點測試客戶端是否具備故障轉移感知能力的原因。另一個老生常談的坑是密碼。哨兵模式涉及三類密碼Redis節(jié)點的requirepass從節(jié)點同步用的masterauth哨兵集群間通信的sentinel auth-pass任何一個沒配好都會導致哨兵無法監(jiān)控主節(jié)點或執(zhí)行切換。調試時多用docker logs redis-sentinel-1看日志錯誤信息里通常會直接寫明認證失敗還是連接超時。提示本地測試時可以先不設密碼把整個機制跑通后再逐步加上密碼。這樣即使出錯也容易定位是密碼配置的問題還是機制本身的問題。5. Redis Cluster真正的數據分片集群如果你要處理的數據量太大單節(jié)點內存裝不下或者寫并發(fā)超過單節(jié)點能承受的上限那么哨兵模式也不夠用了。哨兵模式的所有節(jié)點存的數據是一樣的數據量受限于單節(jié)點內存。這時候需要Redis Cluster——它將數據按照哈希槽hash slot分布到多個主節(jié)點上每個主節(jié)點只存一部分數據整體容量和性能可以水平擴展。5.1 哈希槽數據是如何分布的Redis Cluster固定有16384個哈希槽。每個key通過CRC16算法計算出一個值然后對16384取模得到所屬的槽位。集群的主節(jié)點各自負責一部分槽位。例如3主3從的集群中主節(jié)點A負責0-5460槽主節(jié)點B負責5461-10922槽主節(jié)點C負責10923-16383槽。當你get一個key時客戶端根據同樣的算法算出槽位然后直接找到對應的節(jié)點讀取數據。這個設計是Redis Cluster的靈魂也是它和哨兵模式最大的區(qū)別。理解了這個后面踩到MOVED重定向或者集群槽位不覆蓋這些錯誤時你就能秒懂原因。5.2 三個主節(jié)點的生產級配置文件Redis Cluster對配置文件有額外要求。以下是主節(jié)點1的配置/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000關鍵參數cluster-enabled yes開啟集群模式cluster-config-file集群節(jié)點信息文件Redis會自動維護你不用手動編輯cluster-node-timeout節(jié)點間通信超時時間超過后會被判定為疑似下線主節(jié)點2和主節(jié)點3的配置只需改port和cluster-config-file對應值即可。我這里為了演示方便把三個主節(jié)點都放在一臺機器上通過不同端口區(qū)分。生產環(huán)境建議每臺物理機部署一個節(jié)點避免宿主機宕機導致多個副本同時掛掉。啟動3個主節(jié)點容器以6379為例6380、6381同理docker run -d \ --name redis-cluster-master-1 \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf5.3 初始化集群與自動分配槽位3個主節(jié)點都啟動后執(zhí)行集群初始化命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster create \ 172.20.0.2:6379 172.20.0.3:6379 172.20.0.4:6379 \ --cluster-replicas 0注意這里的IP不是容器名。大多數情況下--cluster create命令不接受Docker容器名它需要的是從集群外部可訪問的IP。Docker容器之間可以通過容器名通信但Redis Cluster在啟動時會把這些IP記錄到集群拓撲里后續(xù)客戶端連接、節(jié)點間重定向都需要這些IP可被訪問。所以第一次搭建時IP規(guī)劃就非常重要。執(zhí)行后Redis會自動計算并分配16384個哈希槽給你指定的3個節(jié)點并輸出分配計劃。確認無誤后輸入yes集群開始初始化。初始化完成后檢查集群狀態(tài)docker exec -it redis-cluster-master-1 redis-cli --cluster info 172.20.0.2:6379看到cluster_state:ok并且所有槽位都已分配說明集群主節(jié)點部分已經就緒。5.4 添加從節(jié)點集群的高可用閉環(huán)Redis Cluster光有主節(jié)點是不行的因為主節(jié)點掛了它負責的槽位就全不可用了。所以生產環(huán)境必須為每個主節(jié)點配置至少一個從節(jié)點。從節(jié)點的作用是實時同步對應的主節(jié)點數據并在主節(jié)點故障時自動提升替代。啟動3個從節(jié)點配置里同樣開啟cluster-enabled yes端口分別用6382、6383、6384。然后執(zhí)行添加命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster add-node \ 172.20.0.5:6382 \ 172.20.0.2:6379 \ --cluster-slave \ --cluster-master-id 主節(jié)點ID主節(jié)點ID可以通過redis-cli --cluster info查到。如果不想手動指定主節(jié)點ID也可以讓Redis自己分配從節(jié)點給負載最低的主節(jié)點。不過我一般傾向于手動指定控制性更強。添加完成后再次查看集群狀態(tài)確保每個主節(jié)點都有對應的從節(jié)點。5.5 Cluster實操中的三個經典坑第一個坑MOVED重定向。如果你不是用redis-cli -ccluster模式連接而是直接連某個節(jié)點并執(zhí)行set而這個key的槽位不歸該節(jié)點管客戶端會收到一個MOVED錯誤提示你應該去另一個IP讀取數據。很多新手看到MOVED就以為集群壞了其實恰恰相反它在正常工作——只需要客戶端支持自動重定向就行。redis-cli -c就是集群感知模式docker exec -it redis-cluster-master-1 redis-cli -c第二個坑槽位分配不均。默認的--cluster create會平均分配槽位但如果你后續(xù)手動添加節(jié)點、刪除節(jié)點槽位可能不均勻導致部分節(jié)點負載過高。可以用redis-cli --cluster rebalance 任意節(jié)點IP:端口讓Redis自動重新平衡。第三個坑Docker端口映射與Cluster總線端口。Redis Cluster每個節(jié)點悄悄多了一個集群總線端口默認是Redis端口10000。比如6379對應16379。集群節(jié)點間的主從檢測、故障轉移選舉都走這個端口。使用Docker-p映射端口時從節(jié)點、外部客戶端通常只需要映射Redis端口即可但如果你需要讓外部工具如可視化面板接入就要把總線端口也映射出來。否則在你本機通過工具連接集群時節(jié)點返回的集群信息里包含16379地址外部網絡根本訪問不到工具會一直報錯。6. 從主從到Cluster的選型建議與生產環(huán)境注意點很多文章只會教你怎么搭卻很少告訴你什么時候該用哪個方案。我在下面按業(yè)務需求做個對照方便你直接抄作業(yè)。6.1 主從、哨兵、Cluster怎么選業(yè)務訴求推薦方案原因緩存數據量單機內存讀寫并發(fā)一般單節(jié)點或主從架構最簡單運維成本最低需要高可用主節(jié)點宕機自動切換哨兵模式故障轉移自動化客戶端可感知數據量超過單機內存天花板Redis Cluster數據分片水平擴展寫入并發(fā)極高單節(jié)點CPU成為瓶頸Redis Cluster多主節(jié)點分攤寫負載要注意的是一旦選擇了Cluster你就得接受一些限制。比如多key操作如MGET、事務、Lua腳本要求所有key必須在同一個哈希槽內。如果key的槽位不同操作會直接報錯CROSSSLOT。你需要使用哈希標簽hash tag來強制某些key進入同一個槽位例如{user:1001}:name和{user:1001}:age會計算同一個槽位因為Redis只對{}內的部分計算哈希。這是一把雙刃劍它能幫你實現批量操作但代價是需要自己管理key的分布提升了一些心智負擔。6.2 生產環(huán)境容器化部署的幾個細節(jié)Docker容器在開發(fā)環(huán)境跑通后生產環(huán)境部署時至少要檢查下面幾個點容器重啟策略加上--restartalways避免機器重啟后Redis容器沒有自動拉起。否則一次宿主機維護你的Redis就再也回不來了。資源限制給Redis容器設置內存上限。推薦--memory4g這類參數否則Redis吃滿宿主機內存觸發(fā)OOM時整個宿主機的其他容器都會遭殃。持久化策略生產環(huán)境建議開啟AOF和RDB雙持久化。RDB做快照恢復快AOF記錄增量操作更安全。兩者配合使用既能快速恢復又能減少數據丟失窗口。不使用--network host的注意事項有些教程推薦用host網絡模式好處是沒有端口映射的端口丟失問題Cluster總線端口天然可見。但host模式在非Linux環(huán)境Docker Desktop下不可用且多實例部署時端口管理困難。我建議使用自定義bridge網絡映射方式的常規(guī)做法生產環(huán)境用編排工具如容器編排平臺管理時也更符合習慣。6.3 故障演練是必修課最后必須強調的是搭好不等于能抗故障要真正驗證高可用需要主動制造故障。無論是哨兵模式還是Cluster模式我都建議定期做一次故障演練隨機選擇一個主節(jié)點停止它的容器觀察從節(jié)點是否自動提升觀察業(yè)務系統(tǒng)是否有感知、恢復時間是多少恢復舊主節(jié)點檢查數據能否重新同步。這份演練記錄比什么配置文檔都珍貴。尤其在聲明確保業(yè)務穩(wěn)定的前提下生產環(huán)境不做一次演練等于把高可用三個字停留在口號階段。我自己經手的集群項目上線前至少演練三輪每一次都會發(fā)現預料之外的問題——第一次是Webhook通知沒配好第二次是從節(jié)點數據同步延遲比預期大導致部分讀請求失敗第三次才真正實現了秒級切換。別嫌麻煩越早發(fā)現問題損失越小。再分享一個小技巧做故障演練別挑業(yè)務高峰時段盡量在凌晨流量低峰期進行。演練前通知所有相關的開發(fā)運維同事準備好回滾方案確保萬一自動切換失敗時能人工介入。這既是技術操作更是工程習慣。7. 總結一下我的實操體會回到開頭的問題Docker搭建Redis集群本質上是用容器技術降低分布式系統(tǒng)實驗門檻。你不需要堆一柜子的服務器一臺筆記本就能把主從、哨兵、Cluster全部跑通。我在這個過程中最大的感受是——三種方案演進的內在邏輯清晰而規(guī)整主從方案解決數據備份哨兵方案解決高可用Cluster方案解決容量和并發(fā)。每一層都是在補上一層方案的短板。如果你剛開始接觸我建議你老老實實按主從→哨兵→Cluster的順序推進不要跳級。每一步都親自動手搭建、故意破壞、再恢復這個過程中的Debug經驗比最終的集群本身值錢得多。等到某一天你在生產環(huán)境中遇到Redis集群告警能依據日志和info輸出快速定位而不是手忙腳亂翻文檔那就說明這套東西真正長在你身上了。最后補充一個我自己踩過很多次的坑命令敲得再完美配置文件的細節(jié)忘了就是會出問題。我后來習慣用docker exec進入容器內檢查實際生效的配置而不是只信宿主機上的文件。畢竟容器里走的是鏡像自帶的默認配置加你掛載的配置兩者疊加后最終生效值是什么redis-cli CONFIG GET *一看便知。這個習慣幫我省下了大量排查時間分享給你希望你也能少走彎路。 Docker搭建Redis集群實戰(zhàn)：從主從復制到哨兵模式與Cluster分片
1. 為什么要用Docker搭Redis集群從單節(jié)點到主從哨兵的演進邏輯先說一個很多人問我的問題單機Redis用得好好的為什么要費勁搭集群這個問題其實分兩層。第一層如果你的業(yè)務量還沒到單節(jié)點扛不住的程度那確實不用折騰集群帶來的復雜度可能比收益還大。但第二層一旦你開始遇到這些信號——CPU持續(xù)打滿、內存快不夠用、寫并發(fā)上不去、或者最怕的Redis宕機導致緩存雪崩那集群就不僅僅是進階玩法而是必須做的功課了。我在實際項目里見過不少類似的情況某公司起初單節(jié)點Redis扛著全部緩存數據某天凌晨主節(jié)點突然宕機整個訂單列表都查不到緩存數據庫壓力瞬間拉滿差點出事故。當時的第一反應就是趕緊弄個高可用方案。而Docker恰好能把這個過程大幅簡化——你不需要準備多臺物理機或虛擬機在一臺機器上就能模擬出完整的集群拓撲開發(fā)環(huán)境驗證通了再平滑遷移到多機生產環(huán)境。用Docker搭Redis集群常見的方案有三種方案核心機制適用場景復雜度主從復制Replication主節(jié)點寫從節(jié)點同步備份讀寫分離、數據備份低哨兵模式Sentinel在主從基礎上增加監(jiān)控和自動故障轉移高可用自動切換中Redis Cluster多主多從數據分片存儲海量數據、高并發(fā)寫入高很多人把這三者搞混以為集群就是Redis Cluster。實際上廣義的Redis集群方案包含了上面的全部形態(tài)。本文會按照從易到難的順序完整走一遍Docker下的三種搭建方式并重點講講我在每一步踩過的坑。這也是我認為一篇實操文章最應該有的內容——不是給你一堆命令復制粘貼而是讓你知道每條命令為什么這么寫、出了問題怎么排查。適合讀者已經了解Docker基本命令run、exec、network和Redis基本概念的人。如果你連docker ps都還沒跑過建議先花半小時熟悉Docker基礎再回來。2. 環(huán)境準備網絡、鏡像和目錄規(guī)劃少一個后面都難受開始動手前先做三件事。很多人省略了這一步結果搭到一半才發(fā)現網絡不通、目錄權限不對、版本不兼容來回折騰的時間比重新搭一遍還長。2.1 創(chuàng)建Docker網絡為什么不能用默認bridgeRedis集群節(jié)點之間需要互相通信而且后續(xù)擴容、重啟容器時IP可能變化所以最穩(wěn)妥的方式是創(chuàng)建一個自定義網絡。默認的bridge網絡雖然也能用但容器間通過容器名互相訪問的能力受限DNS解析不穩(wěn)定。docker network create redis-net加個--subnet參數會更可控比如docker network create --subnet172.20.0.0/16 redis-net這個子網段可以自己定只要和宿主機現有網段不沖突即可。指定了子網后后續(xù)給容器分配固定IP就方便了哨兵模式下尤其有用。2.2 Redis鏡像版本選擇別盲目latest我見過太多人直接docker pull redis:latest結果某次升級后配置項變了排查半天才發(fā)現是鏡像版本問題。這里我建議明確指定版本。docker pull redis:7.0目前Redis 7.x是主流穩(wěn)定版本7.0、7.2都在維護周期內。Redis 6.x也還能用但新特性如Function、Acl改進缺失沒必要。用固定版本號有兩個好處其一是保證本地和線上環(huán)境一致其二是你百度搜到的問題解決方案跟你的版本對得上不至于被版本差異誤導。2.3 目錄規(guī)劃配置文件持久化Docker容器的文件系統(tǒng)是臨時的容器刪了數據就沒了。Redis雖然主要做緩存但開啟AOF持久化后數據文件必須放在宿主機上否則容器重建等于丟數據。我的習慣是每個節(jié)點一個目錄mkdir -p /opt/redis/{6379,6380,6381}以三節(jié)點哨兵模式為例6379、6380、6381分別對應三個Redis實例。生產環(huán)境多機部署時這個目錄結構可以原樣拷貝到其他機器上路徑一致還能減少配置差異導致的低級錯誤。此外還需要準備Redis配置文件。下面這三個文件的細節(jié)我會在對應的章節(jié)逐步展開這里先把最小的骨架立起來touch /opt/redis/6379/redis.conf注意掛載配置文件時容器內的路徑和宿主機路徑要一一對應。我用/opt/redis/6379/redis.conf宿主機文件掛載到容器內/etc/redis/redis.conf這樣改配置文件只需要動宿主機文件不用進容器操作。提示如果你用的是SELinux強制模式的Linux發(fā)行版掛載文件前可能要執(zhí)行chcon -Rt svirt_sandbox_file_t /opt/redis否則容器可能因為權限問題啟動失敗。這個坑比較隱蔽啟動報錯時優(yōu)先檢查。3. 主從復制搭建最小可用集群的一小步主從復制是理解后面所有方案的基礎。它做的事情一句話概括一個主節(jié)點master接收寫請求一個或多個從節(jié)點slave實時同步主節(jié)點的數據讀請求可以打到從節(jié)點上分擔壓力。3.1 啟動主節(jié)點先寫主節(jié)點的配置文件/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof這里daemonize no是因為容器里應該讓Redis以前臺方式運行如果設成yesRedis進程會后臺化容器會因為沒有前臺進程而退出。這是Docker運行Redis的第一個經典坑。然后啟動容器docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf啟動后驗證一下docker exec -it redis-master redis-cli ping如果返回PONG說明主節(jié)點正常。3.2 啟動從節(jié)點并指定主節(jié)點從節(jié)點的配置和主節(jié)點幾乎一樣區(qū)別在于多了replicaof指令。Redis 5.0之前這個指令叫slaveof5.0之后改名為replicaof更準確的語義老版本命令依然兼容。新項目一律用replicaof。/opt/redis/6380/redis.confport 6380 daemonize no appendonly yes appendfilename appendonly.aof replicaof redis-master 6379注意replicaof后面的主機名我直接用了容器名redis-master。在自定義網絡里容器名就是獨立的DNS名稱容器間可以互相ping通。這也是我之前強調要先建自定義網絡的原因。啟動從節(jié)點docker run -d \ --name redis-slave-1 \ --network redis-net \ -p 6380:6380 \ -v /opt/redis/6380:/data \ -v /opt/redis/6380/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf驗證主從是否連通docker exec -it redis-slave-1 redis-cli info replication重點看這幾行輸出role:slave master_host:redis-master master_link_status:upmaster_link_status:up表示主從連接正常。如果顯示down大概率是網絡不通或replicaof配置寫錯。我遇到過一種情況是容器啟動時主節(jié)點還沒準備好從節(jié)點重試幾次后自然恢復等1-2分鐘再看就up了不用急著改配置。3.3 主從復制的數據驗證和誤區(qū)糾正寫幾個key驗證一下docker exec -it redis-master redis-cli set name hello docker exec -it redis-slave-1 redis-cli get name如果在從節(jié)點能讀到hello說明復制鏈路通了。這里必須特別提醒一個誤區(qū)從節(jié)點默認是只讀的。從節(jié)點上執(zhí)行寫命令會報錯READONLY You cant write against a read only replica。這不是故障是設計如此。從節(jié)點只負責同步主節(jié)點數據和分擔讀請求寫請求永遠走主節(jié)點。另外主從復制是異步的。異步意味著極端情況下主節(jié)點剛收到寫請求還沒來得及同步給從節(jié)點就宕機了這部分數據會丟失。對緩存場景通?？梢越邮艿珜祿恢滦砸髽O高的業(yè)務需要借助Wait命令或者直接換更嚴格的中間件Redis本身并不是強一致性的數據庫。提示如果主節(jié)點開啟了密碼驗證從節(jié)點的配置里要加masterauth 密碼否則復制會不斷報錯。這個坑在主從模式下不常見本地測試通常不設密碼但一上生產環(huán)境很多人就在這里卡住。同樣從節(jié)點自己的requirepass也要根據情況加上。3.4 主從模式的實際局限主從復制解決了數據備份和讀寫分離但解決不了自動故障轉移。主節(jié)點宕機后從節(jié)點雖然握著最新數據卻不會自動升級為主節(jié)點。該怎么辦人工干預——登錄服務器手動執(zhí)行replicaof no one讓某個從節(jié)點轉正。人力操作必然存在延遲業(yè)務中斷時間不可控。于是有了哨兵Sentinel機制。4. 哨兵模式讓主從復制具備故障自愈能力哨兵的本質是一個獨立運行的Redis實例它不存數據只負責監(jiān)控主從節(jié)點的健康狀況并在主節(jié)點故障時自動把一個從節(jié)點提升為新的主節(jié)點。哨兵通常也是集群部署的至少3個避免單點故障——哨兵自己掛了就沒人監(jiān)控了。4.1 為什么至少要3個哨兵這里有個概念叫法定人數quorum。當某個哨兵認為主節(jié)點不可達時它不會立刻執(zhí)行故障轉移而是和其他哨兵協(xié)商。只有當認為主節(jié)點故障的哨兵數達到quorum值才會真正觸發(fā)切換。quorum常見配置是2共3個哨兵時這么設計是為了避免網絡分區(qū)導致的誤判——萬一主節(jié)點其實活著只是某個哨兵到它的網絡斷了單個哨兵的判斷并不可靠。如果你只部署1個哨兵它把主節(jié)點誤判為宕機然后執(zhí)行切換可能造成腦裂舊主節(jié)點還活著但哨兵又提拔了一個新主節(jié)點兩個主節(jié)點同時接受寫請求數據就亂了。所以生產環(huán)境至少3個哨兵。4.2 哨兵配置與容器啟動哨兵有自己的配置文件。/opt/redis/26379/sentinel.confport 26379 daemonize no sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000 sentinel parallel-syncs mymaster 1逐行解釋sentinel monitor監(jiān)控名為mymaster的主節(jié)點地址是redis-master:6379最后的2就是quorum值表示至少2個哨兵同意才執(zhí)行故障轉移。down-after-milliseconds連續(xù)5秒聯系不上主節(jié)點就判定為主觀下線。這個值不要設太小否則網絡抖動會導致頻繁誤判。failover-timeout故障轉移超時時間60秒內沒完成切換就重試。parallel-syncs新主節(jié)點確定后同時允許多少個從節(jié)點同步數據。設1表示逐個同步避免網絡瞬間壓力過大。啟動哨兵容器docker run -d \ --name redis-sentinel-1 \ --network redis-net \ -p 26379:26379 \ -v /opt/redis/26379:/data \ -v /opt/redis/26379/sentinel.conf:/etc/redis/sentinel.conf \ redis:7.0 \ redis-sentinel /etc/redis/sentinel.conf同樣的方式再啟動兩個哨兵節(jié)點端口26380、26381注意配置文件里的端口要各自改好。3個哨兵都啟動后通過日志可以確認它們彼此發(fā)現了對方docker logs redis-sentinel-1正常會看到類似sentinel sentinel的日志表示哨兵之間已經建立了互相通信。4.3 故障轉移實測手動殺掉主節(jié)點看效果很多人搭完哨兵就在那干看著壓根不知道好不好用。我建議直接做一次混沌測試——手動殺掉主節(jié)點容器看哨兵能不能自動切換。docker stop redis-master等待10-15秒超過down-after-milliseconds閾值然后觀察哨兵日志docker logs redis-sentinel-1 --tail 50會看到類似switch-master mymaster 172.20.0.2 6379 172.20.0.3 6380的日志表示已經把6380節(jié)點提升為新的主節(jié)點。然后檢查從節(jié)點docker exec -it redis-master redis-cli info replication注意這里舊主節(jié)點的容器雖然停了但重新啟動后它會發(fā)現集群里已經有了新主節(jié)點自動降級為從節(jié)點并開始同步新主節(jié)點數據。這是哨兵模式非常體貼的一個設計——故障恢復后舊主節(jié)點不會搶回主位置。4.4 哨兵模式的坑客戶端感知與密碼問題哨兵模式的第一個潛在坑在客戶端?？蛻舳诉B接Redis的URL需要從redis://...改為sentinel://...并且要指定哨兵地址和主節(jié)點名稱例如sentinel://172.20.0.10:26379,172.20.0.11:26379,172.20.0.12:26379/mymaster如果你把客戶端還配置成直連某個Redis節(jié)點的IP那么主節(jié)點切換后客戶端依然連著舊主節(jié)點的IP自然就不可用了。這也是哨兵模式部署完以后必須重點測試客戶端是否具備故障轉移感知能力的原因。另一個老生常談的坑是密碼。哨兵模式涉及三類密碼Redis節(jié)點的requirepass從節(jié)點同步用的masterauth哨兵集群間通信的sentinel auth-pass任何一個沒配好都會導致哨兵無法監(jiān)控主節(jié)點或執(zhí)行切換。調試時多用docker logs redis-sentinel-1看日志錯誤信息里通常會直接寫明認證失敗還是連接超時。提示本地測試時可以先不設密碼把整個機制跑通后再逐步加上密碼。這樣即使出錯也容易定位是密碼配置的問題還是機制本身的問題。5. Redis Cluster真正的數據分片集群如果你要處理的數據量太大單節(jié)點內存裝不下或者寫并發(fā)超過單節(jié)點能承受的上限那么哨兵模式也不夠用了。哨兵模式的所有節(jié)點存的數據是一樣的數據量受限于單節(jié)點內存。這時候需要Redis Cluster——它將數據按照哈希槽hash slot分布到多個主節(jié)點上每個主節(jié)點只存一部分數據整體容量和性能可以水平擴展。5.1 哈希槽數據是如何分布的Redis Cluster固定有16384個哈希槽。每個key通過CRC16算法計算出一個值然后對16384取模得到所屬的槽位。集群的主節(jié)點各自負責一部分槽位。例如3主3從的集群中主節(jié)點A負責0-5460槽主節(jié)點B負責5461-10922槽主節(jié)點C負責10923-16383槽。當你get一個key時客戶端根據同樣的算法算出槽位然后直接找到對應的節(jié)點讀取數據。這個設計是Redis Cluster的靈魂也是它和哨兵模式最大的區(qū)別。理解了這個后面踩到MOVED重定向或者集群槽位不覆蓋這些錯誤時你就能秒懂原因。5.2 三個主節(jié)點的生產級配置文件Redis Cluster對配置文件有額外要求。以下是主節(jié)點1的配置/opt/redis/6379/redis.confport 6379 daemonize no appendonly yes appendfilename appendonly.aof cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000關鍵參數cluster-enabled yes開啟集群模式cluster-config-file集群節(jié)點信息文件Redis會自動維護你不用手動編輯cluster-node-timeout節(jié)點間通信超時時間超過后會被判定為疑似下線主節(jié)點2和主節(jié)點3的配置只需改port和cluster-config-file對應值即可。我這里為了演示方便把三個主節(jié)點都放在一臺機器上通過不同端口區(qū)分。生產環(huán)境建議每臺物理機部署一個節(jié)點避免宿主機宕機導致多個副本同時掛掉。啟動3個主節(jié)點容器以6379為例6380、6381同理docker run -d \ --name redis-cluster-master-1 \ --network redis-net \ -p 6379:6379 \ -v /opt/redis/6379:/data \ -v /opt/redis/6379/redis.conf:/etc/redis/redis.conf \ redis:7.0 \ redis-server /etc/redis/redis.conf5.3 初始化集群與自動分配槽位3個主節(jié)點都啟動后執(zhí)行集群初始化命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster create \ 172.20.0.2:6379 172.20.0.3:6379 172.20.0.4:6379 \ --cluster-replicas 0注意這里的IP不是容器名。大多數情況下--cluster create命令不接受Docker容器名它需要的是從集群外部可訪問的IP。Docker容器之間可以通過容器名通信但Redis Cluster在啟動時會把這些IP記錄到集群拓撲里后續(xù)客戶端連接、節(jié)點間重定向都需要這些IP可被訪問。所以第一次搭建時IP規(guī)劃就非常重要。執(zhí)行后Redis會自動計算并分配16384個哈希槽給你指定的3個節(jié)點并輸出分配計劃。確認無誤后輸入yes集群開始初始化。初始化完成后檢查集群狀態(tài)docker exec -it redis-cluster-master-1 redis-cli --cluster info 172.20.0.2:6379看到cluster_state:ok并且所有槽位都已分配說明集群主節(jié)點部分已經就緒。5.4 添加從節(jié)點集群的高可用閉環(huán)Redis Cluster光有主節(jié)點是不行的因為主節(jié)點掛了它負責的槽位就全不可用了。所以生產環(huán)境必須為每個主節(jié)點配置至少一個從節(jié)點。從節(jié)點的作用是實時同步對應的主節(jié)點數據并在主節(jié)點故障時自動提升替代。啟動3個從節(jié)點配置里同樣開啟cluster-enabled yes端口分別用6382、6383、6384。然后執(zhí)行添加命令docker exec -it redis-cluster-master-1 \ redis-cli --cluster add-node \ 172.20.0.5:6382 \ 172.20.0.2:6379 \ --cluster-slave \ --cluster-master-id 主節(jié)點ID主節(jié)點ID可以通過redis-cli --cluster info查到。如果不想手動指定主節(jié)點ID也可以讓Redis自己分配從節(jié)點給負載最低的主節(jié)點。不過我一般傾向于手動指定控制性更強。添加完成后再次查看集群狀態(tài)確保每個主節(jié)點都有對應的從節(jié)點。5.5 Cluster實操中的三個經典坑第一個坑MOVED重定向。如果你不是用redis-cli -ccluster模式連接而是直接連某個節(jié)點并執(zhí)行set而這個key的槽位不歸該節(jié)點管客戶端會收到一個MOVED錯誤提示你應該去另一個IP讀取數據。很多新手看到MOVED就以為集群壞了其實恰恰相反它在正常工作——只需要客戶端支持自動重定向就行。redis-cli -c就是集群感知模式docker exec -it redis-cluster-master-1 redis-cli -c第二個坑槽位分配不均。默認的--cluster create會平均分配槽位但如果你后續(xù)手動添加節(jié)點、刪除節(jié)點槽位可能不均勻導致部分節(jié)點負載過高。可以用redis-cli --cluster rebalance 任意節(jié)點IP:端口讓Redis自動重新平衡。第三個坑Docker端口映射與Cluster總線端口。Redis Cluster每個節(jié)點悄悄多了一個集群總線端口默認是Redis端口10000。比如6379對應16379。集群節(jié)點間的主從檢測、故障轉移選舉都走這個端口。使用Docker-p映射端口時從節(jié)點、外部客戶端通常只需要映射Redis端口即可但如果你需要讓外部工具如可視化面板接入就要把總線端口也映射出來。否則在你本機通過工具連接集群時節(jié)點返回的集群信息里包含16379地址外部網絡根本訪問不到工具會一直報錯。6. 從主從到Cluster的選型建議與生產環(huán)境注意點很多文章只會教你怎么搭卻很少告訴你什么時候該用哪個方案。我在下面按業(yè)務需求做個對照方便你直接抄作業(yè)。6.1 主從、哨兵、Cluster怎么選業(yè)務訴求推薦方案原因緩存數據量單機內存讀寫并發(fā)一般單節(jié)點或主從架構最簡單運維成本最低需要高可用主節(jié)點宕機自動切換哨兵模式故障轉移自動化客戶端可感知數據量超過單機內存天花板Redis Cluster數據分片水平擴展寫入并發(fā)極高單節(jié)點CPU成為瓶頸Redis Cluster多主節(jié)點分攤寫負載要注意的是一旦選擇了Cluster你就得接受一些限制。比如多key操作如MGET、事務、Lua腳本要求所有key必須在同一個哈希槽內。如果key的槽位不同操作會直接報錯CROSSSLOT。你需要使用哈希標簽hash tag來強制某些key進入同一個槽位例如{user:1001}:name和{user:1001}:age會計算同一個槽位因為Redis只對{}內的部分計算哈希。這是一把雙刃劍它能幫你實現批量操作但代價是需要自己管理key的分布提升了一些心智負擔。6.2 生產環(huán)境容器化部署的幾個細節(jié)Docker容器在開發(fā)環(huán)境跑通后生產環(huán)境部署時至少要檢查下面幾個點容器重啟策略加上--restartalways避免機器重啟后Redis容器沒有自動拉起。否則一次宿主機維護你的Redis就再也回不來了。資源限制給Redis容器設置內存上限。推薦--memory4g這類參數否則Redis吃滿宿主機內存觸發(fā)OOM時整個宿主機的其他容器都會遭殃。持久化策略生產環(huán)境建議開啟AOF和RDB雙持久化。RDB做快照恢復快AOF記錄增量操作更安全。兩者配合使用既能快速恢復又能減少數據丟失窗口。不使用--network host的注意事項有些教程推薦用host網絡模式好處是沒有端口映射的端口丟失問題Cluster總線端口天然可見。但host模式在非Linux環(huán)境Docker Desktop下不可用且多實例部署時端口管理困難。我建議使用自定義bridge網絡映射方式的常規(guī)做法生產環(huán)境用編排工具如容器編排平臺管理時也更符合習慣。6.3 故障演練是必修課最后必須強調的是搭好不等于能抗故障要真正驗證高可用需要主動制造故障。無論是哨兵模式還是Cluster模式我都建議定期做一次故障演練隨機選擇一個主節(jié)點停止它的容器觀察從節(jié)點是否自動提升觀察業(yè)務系統(tǒng)是否有感知、恢復時間是多少恢復舊主節(jié)點檢查數據能否重新同步。這份演練記錄比什么配置文檔都珍貴。尤其在聲明確保業(yè)務穩(wěn)定的前提下生產環(huán)境不做一次演練等于把高可用三個字停留在口號階段。我自己經手的集群項目上線前至少演練三輪每一次都會發(fā)現預料之外的問題——第一次是Webhook通知沒配好第二次是從節(jié)點數據同步延遲比預期大導致部分讀請求失敗第三次才真正實現了秒級切換。別嫌麻煩越早發(fā)現問題損失越小。再分享一個小技巧做故障演練別挑業(yè)務高峰時段盡量在凌晨流量低峰期進行。演練前通知所有相關的開發(fā)運維同事準備好回滾方案確保萬一自動切換失敗時能人工介入。這既是技術操作更是工程習慣。7. 總結一下我的實操體會回到開頭的問題Docker搭建Redis集群本質上是用容器技術降低分布式系統(tǒng)實驗門檻。你不需要堆一柜子的服務器一臺筆記本就能把主從、哨兵、Cluster全部跑通。我在這個過程中最大的感受是——三種方案演進的內在邏輯清晰而規(guī)整主從方案解決數據備份哨兵方案解決高可用Cluster方案解決容量和并發(fā)。每一層都是在補上一層方案的短板。如果你剛開始接觸我建議你老老實實按主從→哨兵→Cluster的順序推進不要跳級。每一步都親自動手搭建、故意破壞、再恢復這個過程中的Debug經驗比最終的集群本身值錢得多。等到某一天你在生產環(huán)境中遇到Redis集群告警能依據日志和info輸出快速定位而不是手忙腳亂翻文檔那就說明這套東西真正長在你身上了。最后補充一個我自己踩過很多次的坑命令敲得再完美配置文件的細節(jié)忘了就是會出問題。我后來習慣用docker exec進入容器內檢查實際生效的配置而不是只信宿主機上的文件。畢竟容器里走的是鏡像自帶的默認配置加你掛載的配置兩者疊加后最終生效值是什么redis-cli CONFIG GET *一看便知。這個習慣幫我省下了大量排查時間分享給你希望你也能少走彎路。