最近好幾個朋友來問我同一個問題docker啟動redis 到底卡在哪一步了。有人是鏡像拉下來了但容器幾秒就退出有人是容器起來了可客戶端怎么都連不上還有人更慘卡在Docker Desktop本身啟動不了報(bào)錯信息在搜索引擎里一搜一大片。這些坑我早期全都踩過而且回頭看絕大多數(shù)都不是Redis本身的問題而是對Docker運(yùn)行機(jī)制的一兩個關(guān)鍵點(diǎn)沒想清楚。這篇文章我就按自己實(shí)際的操作順序來寫怎么把第一個Redis容器跑起來、怎么讓數(shù)據(jù)持久化、怎么把Docker Desktop啟動失敗的坑填平、怎么用Compose做一主一從以及跑起來之后的日常運(yùn)維。無論你用Windows、macOS還是Linux這個思路都通用適合剛上手Docker的新手也適合那些已經(jīng)能啟動但不知道怎么配置持久化和安全的同學(xué)。1. 為什么我建議用Docker跑Redis而不是直接裝1.1 一條命令解決版本與環(huán)境的老大難問題如果你在裸機(jī)環(huán)境裝過Redis大概率經(jīng)歷過這么幾個場景Ubuntu上用apt裝了個老版本macOS上用brew install又裝了個新版本公司服務(wù)器上可能還是編譯安裝的3.2。版本之間命令有差異配置文件散落在不同目錄升級一次還要小心翼翼處理數(shù)據(jù)兼容性。Docker把這些麻煩全擋在外面了。鏡像就像打包好的運(yùn)行時里面帶了Redis二進(jìn)制、依賴庫和默認(rèn)配置你只需要關(guān)心數(shù)據(jù)放在哪、端口暴露在哪、密碼是什么。更重要的是多個版本可以共存。docker run -d --name redis7 -p 6379:6379 redis:7 docker run -d --name redis6 -p 6380:6379 redis:6.2這兩個容器互不干擾一個用6379一個用6380本質(zhì)上就是兩個獨(dú)立進(jìn)程。不想用了直接docker rm -f宿主機(jī)干干凈凈不會留下編譯殘留、系統(tǒng)服務(wù)和路徑配置。這就是我推薦Docker跑Redis的最重要原因隔離帶來的干凈。1.2 官方鏡像這么多 tag到底該選哪個Redis官方鏡像的tag很多常見的有redis:7、redis:7.2-alpine、redis:7-bookworm、redis:6.2-alpine。選的時候主要看基礎(chǔ)系統(tǒng)和體積。鏡像tag基礎(chǔ)系統(tǒng)體積適合場景redis:7Debian bookworm約120MB生產(chǎn)主力調(diào)試工具全redis:7-alpineAlpine Linux約35MB本地快速驗(yàn)證追求體積redis:6.2-alpineAlpine Linux約35MB老版本兼容需求redis:7.2Debian bookworm約120MB指定7.2小版本我的建議是本地開發(fā)用redis:7-alpine體積小、啟動快生產(chǎn)環(huán)境用redis:7這種Debian系鏡像出問題的時候容器里可以apt-get裝排查工具。盡量別用latest因?yàn)槟悴恢滥奶炖聛淼淖钚掳鍾edis改了什么行為對比版本差異的時候會很痛苦。1.3 Docker Desktop 和裸 Docker Engine 怎么選本地開發(fā)跑Docker最常見的選擇是Docker Desktop。它自帶了Docker Engine、Compose插件還有圖形界面能看容器狀態(tài)和volume。Linux用戶則直接用Docker Engine就行不需要桌面端。Windows和macOS的Docker Desktop本質(zhì)上是靠虛擬機(jī)來模擬Linux內(nèi)核Windows下面走的是WSL2或者Hyper-VmacOS走的是Apple虛擬化框架。這就是為什么網(wǎng)上那么多Docker Desktop failed to start because virtualisation support wasnt detected的報(bào)錯虛擬化支持是它的命門。如果你現(xiàn)在還無法啟動Docker Desktop別急著往下讀Redis命令先跳到第4章把虛擬化問題解決。2. 跑起來再說第一個Redis容器的最小可用命令2.1 五條命令把Redis拉起來并完成自檢第一步別想太復(fù)雜先跑一個不帶任何持久化、不帶密碼的最小容器。docker pull redis:7 docker run -d --name redis-demo -p 6379:6379 redis:7 docker ps docker exec -it redis-demo redis-cli pingdocker pull redis:7是把鏡像拉到本地。docker run里的-d表示后臺運(yùn)行不然終端會一直掛著。--name redis-demo是給容器起名之后操作都用這個名字不需要記容器ID。-p 6379:6379是端口映射左邊的6379是宿主機(jī)端口右邊的6379是容器內(nèi)Redis監(jiān)聽的端口。如果一切正常最后一條命令會輸出PONG。這說明容器里的Redis進(jìn)程活著redis-cli也能和它正常對話。2.2 你連不上Redis八成是少了 -p 這個參數(shù)我見過不少新手執(zhí)行docker run -d --name redis-demo redis:7然后拿著可視化客戶端去連127.0.0.1:6379結(jié)果連接被拒絕。原因很簡單沒有-p的時候宿主機(jī)6379端口根本沒有監(jiān)聽Redis只存在于容器內(nèi)部網(wǎng)絡(luò)里。-p做的事情是把宿主機(jī)的一個端口轉(zhuǎn)發(fā)到容器內(nèi)部的端口。用-p 16379:6379這種寫法宿主機(jī)端口可以是16379容器內(nèi)Redis照常監(jiān)聽6379。這樣你即使本機(jī)有別的服務(wù)占了6379也能用16379訪問Redis。驗(yàn)證宿主機(jī)到容器的通路是否正?？梢灾苯釉诒緳C(jī)執(zhí)行redis-cli -h 127.0.0.1 -p 6379 ping如果本機(jī)沒有安裝Redis客戶端也可以用Dockerexec進(jìn)去執(zhí)行redis-cli但這樣就繞過了端口映射無法驗(yàn)證網(wǎng)絡(luò)轉(zhuǎn)發(fā)。2.3 容器管理的基本動作和端口占用的坑日常操作容器就三組命令docker stop redis-demo docker start redis-demo docker rm -f redis-demostop是優(yōu)雅停止start是重新啟動rm -f是先強(qiáng)制停止再刪除。注意rm不會刪除鏡像只是把容器銷毀。端口占用是最常見的報(bào)錯場景。假設(shè)你6379端口被一個殘留容器占著重新run時會看到類似這樣的錯誤Error response from daemon: driver failed programming external connectivity on endpoint redis-demo: Bind for 0.0.0.0:6379 failed: port is already allocated解決辦法不是換端口而是先看看是哪個容器占了端口docker ps --format table {{.Names}}\t{{.Ports}}找到占用的容器判斷能不能刪。如果只是端口被本機(jī)進(jìn)程占了那就在run命令里換一個宿主機(jī)端口比如-p 6380:6379。3. 持久化與配置文件從玩具級變成能用3.1 容器一刪數(shù)據(jù)就消失不是玄學(xué)用第2章的命令跑起來的Redis一旦執(zhí)行docker rm -f里面存的Key全部消失。這不是Redis不持久化而是容器文件系統(tǒng)本身是臨時的。容器被刪除時它的可寫層也跟著沒了。要讓數(shù)據(jù)活下來就必須把Redis的數(shù)據(jù)目錄掛載到宿主機(jī)。Redis默認(rèn)會把數(shù)據(jù)寫到/data目錄所以掛載時瞄準(zhǔn)這個路徑。docker run -d --name redis-stable -p 6379:6379 -v redis-data:/data redis:7 --appendonly yes這里的-v redis-data:/data是創(chuàng)建一個名為redis-data的命名卷掛到容器的/data。--appendonly yes是讓Redis開啟AOF持久化因?yàn)槟J(rèn)情況下Redis只存快照可能好幾秒才寫一次掛載了目錄也不一定能第一時間看到數(shù)據(jù)。AOF開啟后每次寫操作都會被追加到文件里數(shù)據(jù)安全性高很多。驗(yàn)證一下docker exec -it redis-stable redis-cli set foo bar docker rm -f redis-stable docker run -d --name redis-stable2 -p 6379:6379 -v redis-data:/data redis:7 --appendonly yes docker exec -it redis-stable2 redis-cli get foo最后一條命令輸出bar說明數(shù)據(jù)成功跨容器存活。注意用的是同一個命名卷redis-data。3.2 要讓 redis.conf 生效啟動命令必須這樣寫官方鏡像雖然自帶一份配置但很多時候我們需要改maxmemory、requirepass、appendonly這些關(guān)鍵項(xiàng)。正確姿勢是把配置文件掛載進(jìn)容器然后在啟動命令里顯式指定配置路徑。先準(zhǔn)備一份配置文件建議放在~/docker/redis/redis.confbind 0.0.0.0 protected-mode yes port 6379 daemonize no appendonly yes appendfsync everysec requirepass your-strong-password maxmemory 512mb maxmemory-policy allkeys-lru然后啟動docker run -d \ --name redis-conf \ -p 6379:6379 \ -v ~/docker/redis/redis.conf:/usr/local/etc/redis/redis.conf \ -v redis-data:/data \ redis:7 \ redis-server /usr/local/etc/redis/redis.conf注意最后一行。官方鏡像的默認(rèn)入口會執(zhí)行redis-server但你給了配置文件路徑之后Redis會讀指定文件而不是鏡像內(nèi)置配置。這里有兩個必須說的坑一daemonize一定要寫成no。Docker容器要求前臺保持一個主進(jìn)程如果Redis自己fork到后臺變成守護(hù)進(jìn)程容器會認(rèn)為主進(jìn)程退出然后直接停止。二文件權(quán)限對不上可能報(bào)錯。官方鏡像里Redis是以UID 999的用戶運(yùn)行的如果掛載進(jìn)來的配置文件屬主不是999有可能讀到日志目錄時出現(xiàn)Permission denied。簡單粗暴的辦法是sudo chown -R 999:999 ~/docker/redis3.3 密碼、bind、protected-mode三件套缺一不可把Redis暴露到Docker端口之后千萬別裸奔。公網(wǎng)上有大量掃描器在掃6379端口一旦發(fā)現(xiàn)沒有密碼的Redis分分鐘給你寫入挖礦程序成為肉雞。這不是危言聳聽真實(shí)環(huán)境里我見過太多因?yàn)镽edis沒設(shè)密碼被打穿的案例。設(shè)置密碼有三種方式方式命令/配置特點(diǎn)配置文件在redis.conf里寫requirepass xxx推薦可版本管理命令行參數(shù)docker run ... redis-server --requirepass xxx快速測試但容易被ps看到環(huán)境變量官方鏡像7.x支持REDIS_PASSWORDxxx適合Compose里管理同時還要理解Redis的默認(rèn)保護(hù)邏輯。Redis 3.2之后默認(rèn)protected-mode yes如果沒設(shè)密碼Redis只允許本機(jī)回環(huán)地址訪問宿主機(jī)從外部連過來會被拒絕。當(dāng)你用-p 6379:6379把端口暴露出來時docker網(wǎng)絡(luò)轉(zhuǎn)發(fā)里的源IP不是127.0.0.1所以必須設(shè)密碼并且把bind設(shè)為0.0.0.0才能穩(wěn)定訪問。如果不想讓Redis對宿主機(jī)所有網(wǎng)卡開放只給局域網(wǎng)用可以這樣寫配置bind 127.0.0.1 192.168.1.100 protected-mode yes requirepass your-strong-password這會在宿主機(jī)IP上監(jiān)聽但不會暴露到公網(wǎng)網(wǎng)卡。4. Docker Desktop 啟動失敗排查從報(bào)錯到跑通4.1 先把報(bào)錯原文記住Docker Desktop在Windows上最常見的啟動報(bào)錯就是Docker Desktop failed to start because virtualisation support wasnt detected.有些版本也會顯示Virtualization support not detected這行字一旦出現(xiàn)基本可以斷定Docker Desktop想要的虛擬化后端沒就緒。它要么是WSL2沒裝好要么是Hyper-V無效要么是CPU的硬件虛擬化沒開啟。別第一時間重裝先按下面的鏈路排查。4.2 虛擬化是什么為什么Docker Desktop偏偏依賴它Docker Desktop運(yùn)行原理和Linux上的Docker Engine不太一樣。Linux上的Docker直接調(diào)用Linux內(nèi)核的命名空間和cgroup天生就是原生的。而macOS和Windows的進(jìn)程并不是Linux程序Docker Desktop必須在系統(tǒng)里養(yǎng)一個輕量級Linux虛擬機(jī)所有容器都跑在這臺虛擬機(jī)里。這臺虛擬機(jī)總得有東西支撐。Windows上要么用WSL2要么用Hyper-VmacOS上用的是Apple虛擬化框架。這些基礎(chǔ)設(shè)施全都依賴CPU硬件虛擬化能力也就是Intel的VT-x或AMD的AMD-V。如果CPU虛擬化沒打開或者WSL2/Hyper-V組件沒啟用Docker Desktop當(dāng)然無法啟動。你可以理解成Docker Desktop像個雜技演員虛擬化就是舞臺。舞臺沒搭好演員再專業(yè)也上不了場。4.3 Windows 修復(fù)鏈路WSL2、系統(tǒng)功能、BIOSWindows上排查順序我建議從軟件到硬件第一步看任務(wù)管理器。按CtrlShiftEsc切到性能標(biāo)簽底部有個虛擬化狀態(tài)。如果顯示已啟用說明CPU沒問題問題出在系統(tǒng)組件如果顯示已禁用得進(jìn)BIOS打開。第二步啟用Windows功能。WinR輸入optionalfeatures把這三項(xiàng)勾上適用于Linux的Windows子系統(tǒng)虛擬機(jī)平臺Windows虛擬機(jī)監(jiān)控程序平臺第三步安裝WSL2。以管理員身份打開PowerShellwsl --install wsl --set-default-version 2裝好以后重啟電腦再打開Docker Desktop。如果還是報(bào)錯在Docker Desktop設(shè)置里找到Resources - WSL Integration確認(rèn)WSL2后端已經(jīng)啟用。第四步如果任務(wù)管理器里虛擬化顯示已禁用那就重啟進(jìn)BIOS/UEFI找Intel Virtualization TechnologyIntel平臺或SVM ModeAMD平臺把它設(shè)為Enabled。不同主板叫法不同但核心詞就是Virtualization。我遇到過一臺Windows 11的機(jī)器所有組件都開了虛擬化也開了Docker Desktop還是起不來。最后發(fā)現(xiàn)是之前裝過舊版本Hyper-V沒完全卸載干凈跟WSL2后端沖突。解決辦法是把Docker Desktop的后端切換成Hyper-V試試或者徹底卸載重裝。這種問題很折騰但能擺平。4.4 macOS 上的啟動授權(quán)與資源分配macOS上的Docker Desktop啟動失敗相對少一些但有兩個常見的坎。一個是首次安裝后需要授權(quán)。第一次打開Docker Desktop系統(tǒng)會彈窗提示需要Docker訪問某些資源必須去系統(tǒng)設(shè)置 - 隱私與安全性里手動允許不然界面會卡在Docker Engine is starting。另一個是資源不夠。如果你用Docker Desktop同時跑Redis、MySQL、Kibana多個容器默認(rèn)內(nèi)存配額很容易不夠。柚子容器起一個崩一個Redis容器起來以后docker logs里全是Cannot allocate memory。這時去Docker Desktop的Settings - Resources把Memory調(diào)高到4GB以上CPU也可以給2到4核。蘋果芯片的Mac跑Docker性能通常比Intel版流暢但個別舊版本Docker Desktop在Rosetta模式下會有兼容性問題。直接選Use Rosetta for x86/amd64 emulation on Apple Silicon這個選項(xiàng)如果勾了反而啟動慢就把勾去掉。4.5 Docker起來了但Redis容器網(wǎng)絡(luò)不通怎么辦Docker Desktop本身能啟動了可Redis容器還是連不上這時候按三個方向排查。第一確認(rèn)容器真的在跑。docker ps看看redis-demo的狀態(tài)是不是Up。如果顯示Exited (0)大概率是redis.conf里daemonize yes導(dǎo)致的回第3章改成no。第二看日志。docker logs redis-demo如果有網(wǎng)絡(luò)相關(guān)錯誤直接搜索錯誤關(guān)鍵字基本上能找到答案。第三查看容器IP和網(wǎng)絡(luò)模式。如果不做任何網(wǎng)絡(luò)配置Redis容器默認(rèn)在bridge網(wǎng)絡(luò)上宿主機(jī)通過-p映射訪問即可。有些同學(xué)為了讓Redis連MySQL自己創(chuàng)建了自定義網(wǎng)絡(luò)卻忘了-p不能和自定義網(wǎng)絡(luò)同時生效于容器啟動命令的場景導(dǎo)致宿主機(jī)永遠(yuǎn)連不上Redis。我的建議是開發(fā)環(huán)境一律用-p映射多容器互通靠Docker Compose的自定義網(wǎng)絡(luò)不要手工混用。還有一個最容易被忽略的點(diǎn)Docker Desktop重啟后之前那些沒有設(shè)置自動重啟的Redis容器不會自己起來。啟動Redis時加上--restart unless-stopped能省下一半的運(yùn)維事故。5. 從單機(jī)到主從用Docker Compose編排一主一從5.1 為什么要多一個從節(jié)點(diǎn)單機(jī)Redis能跑通只是第一步。實(shí)際項(xiàng)目里Redis承擔(dān)緩存、分布式鎖、臨時數(shù)據(jù)存儲這些職責(zé)一旦單節(jié)點(diǎn)掛了緩存全部穿透到數(shù)據(jù)庫很容易把服務(wù)打垮。最輕量級的容災(zāi)方案就是主從復(fù)制一個主節(jié)點(diǎn)負(fù)責(zé)寫一個或多個從節(jié)點(diǎn)負(fù)責(zé)同步數(shù)據(jù)讀請求可以分散到從節(jié)點(diǎn)。這種方案還有個額外好處備份的時候可以從從節(jié)點(diǎn)導(dǎo)出數(shù)據(jù)不影響主節(jié)點(diǎn)性能。做分布式鎖之類的場景主從也能提供一些基礎(chǔ)保障但要真正保證安全得配合紅鎖或哨兵這里先不展開。主從本身不是高可用方案主節(jié)點(diǎn)掛掉后從節(jié)點(diǎn)不會自動頂上需要哨兵或人工介入。但對于個人項(xiàng)目、中小型內(nèi)部系統(tǒng)一主一從的內(nèi)存型Redis已經(jīng)足夠爽了。5.2 目錄結(jié)構(gòu)和配置文件先寫好用Docker Compose管理主從最清晰。先建一個目錄比如redis-clusterredis-cluster/ ├── docker-compose.yml ├── master.conf └── slave.confmaster.confbind 0.0.0.0 protected-mode yes port 6379 daemonize no appendonly yes requirepass 123456slave.confbind 0.0.0.0 protected-mode yes port 6379 daemonize no appendonly yes requirepass 123456 masterauth 123456 replicaof redis-master 6379關(guān)鍵點(diǎn)是slave.conf里必須有兩行masterauth填主節(jié)點(diǎn)的密碼replicaof指定主節(jié)點(diǎn)的服務(wù)名和端口。Docker Compose默認(rèn)會創(chuàng)建一個網(wǎng)絡(luò)服務(wù)名redis-master在容器內(nèi)可以直接當(dāng)作DNS解析。docker-compose.ymlservices: redis-master: image: redis:7 container_name: redis-master ports: - 6379:6379 volumes: - ./master.conf:/usr/local/etc/redis/redis.conf command: [redis-server, /usr/local/etc/redis/redis.conf] redis-slave: image: redis:7 container_name: redis-slave ports: - 6380:6379 depends_on: - redis-master volumes: - ./slave.conf:/usr/local/etc/redis/redis.conf command: [redis-server, /usr/local/etc/redis/redis.conf]從節(jié)點(diǎn)的ports寫6380:6379意思是宿主機(jī)用6380訪問從節(jié)點(diǎn)。容器內(nèi)部從節(jié)點(diǎn)依然監(jiān)聽6379和主節(jié)點(diǎn)不沖突。5.3 啟動并驗(yàn)證復(fù)制狀態(tài)在redis-cluster目錄下執(zhí)行docker compose up -d docker compose ps兩條命令都正常后分別看主從的復(fù)制信息docker exec -it redis-master redis-cli -a 123456 info replication docker exec -it redis-slave redis-cli -a 123456 info replication主節(jié)點(diǎn)預(yù)期輸出role:master connected_slaves:1從節(jié)點(diǎn)預(yù)期輸出role:replica master_host:redis-master master_link_status:up如果master_link_status是down說明同步?jīng)]建立。接著實(shí)測數(shù)據(jù)復(fù)制docker exec -it redis-master redis-cli -a 123456 set hello world docker exec -it redis-slave redis-cli -a 123456 get hello主節(jié)點(diǎn)寫入hello從節(jié)點(diǎn)能讀到world主從復(fù)制鏈路就通了。5.4 主從常見兩個坑NOAUTH和bind限制第一次搭主從時我踩過最深的坑就是NOAUTH Authentication required?，F(xiàn)象是主節(jié)點(diǎn)能正常寫從節(jié)點(diǎn)一直連不上docker logs redis-slave刷出來MASTER - REPLICA sync started Error reply to MASTERAUTH: NOAUTH Authentication required.原因很簡單主節(jié)點(diǎn)設(shè)置了requirepass 123456但從節(jié)點(diǎn)沒有配置masterauth 123456所以每次握手都被主節(jié)點(diǎn)拒絕。解決辦法就是在slave.conf里補(bǔ)上masterauth。另一個坑是bind限制。如果主節(jié)點(diǎn)的配置里只寫了bind 127.0.0.1從節(jié)點(diǎn)在容器網(wǎng)絡(luò)里訪問redis-master:6379時會發(fā)現(xiàn)主節(jié)點(diǎn)只監(jiān)聽回環(huán)地址連接直接被拒絕。我在3.2節(jié)特意強(qiáng)調(diào)Docker環(huán)境要把bind設(shè)為0.0.0.0就是這個原因。這兩個問題都不難但報(bào)錯信息很有迷惑性第一次遇到可能花掉一下午。6. 容器跑起來之后的日常運(yùn)維與備份6.1 日志、資源占用以及給Redis限量Redis啟動后第一時間看日志docker logs -f redis-demo-f是持續(xù)跟蹤日志輸出CtrlC退出查看。啟動階段有沒有加載配置文件、主從同步有沒有異常都能在日志里看到。資源占用用docker stats它像個任務(wù)管理器實(shí)時顯示每個容器的CPU、內(nèi)存、網(wǎng)絡(luò)IO。如果Redis內(nèi)存不設(shè)上限一旦業(yè)務(wù)里寫入大量緩存它可能會把宿主機(jī)內(nèi)存吃光。開發(fā)環(huán)境下可以在啟動命令里加上資源限制docker run -d --name redis-limited --memory 512m --cpus 1 redis:7更優(yōu)雅的做法是在配置文件里設(shè)maxmemory讓Redis自己控制內(nèi)存超了就走maxmemory-policy指定的淘汰策略。allkeys-lru是常用策略適合緩存場景如果只是做分布式鎖和臨時狀態(tài)存儲建議用noeviction寧可報(bào)錯也不丟數(shù)據(jù)。6.2 可視化客戶端怎么連、連不上怎么查命令行用多了總想偷懶可視化客戶端確實(shí)更適合日常看監(jiān)控和key分布。市面上的選擇很多客戶端特點(diǎn)Another Redis Desktop Manager輕量、跨平臺、免費(fèi)Redis Insight官方出品功能全面自帶分析和集群管理redis-cli命令行排查最快連接參數(shù)就是三件套host填宿主機(jī)IPport填映射出來的宿主機(jī)端口password填配置里的密碼。比如本機(jī)Docker映射的Redishost填127.0.0.1、port填6379。連不上的時候照著這個順序查docker ps確認(rèn)容器是Up狀態(tài)docker logs redis-demo看有沒有報(bào)錯宿主機(jī)直接curl或者用nc測端口通不通確認(rèn)不是防火墻攔截如果Redis運(yùn)行在云服務(wù)器上還要檢查云廠商的安全組是否放行了6379端口。這個坑特別隱蔽本地客戶端死活連接超時容器明明在跑最后發(fā)現(xiàn)是安全組沒開。6.3 備份Redis數(shù)據(jù)別只靠Docker的volume掛載volume能解決容器刪除的數(shù)據(jù)丟失問題但解決不了整塊磁盤損壞和誤刪容器卷的問題。備份是另一回事。Redis持久化文件就兩種RDB快照和AOF日志。日常備份最簡單的做法是直接打包volume比如把redis-data卷導(dǎo)出成一個tar包docker run --rm -v redis-data:/data -v $(pwd):/backup alpine tar czf /backup/redis-data.tar.gz -C /data .這條命令會啟動一個臨時Alpine容器把redis-data卷的數(shù)據(jù)打包到當(dāng)前目錄。也可以趁Redis運(yùn)行中用客戶端觸發(fā)一次持久化docker exec -it redis-demo redis-cli -a 123456 --rdb /tmp/dump.rdb但它寫的是容器內(nèi)的臨時路徑還是要把文件拷貝出來docker cp redis-demo:/tmp/dump.rdb ./dump.rdb恢復(fù)的時候先把容器停掉把備份文件放到正確的persist目錄再啟動容器。千萬別在Redis運(yùn)行的時候直接往數(shù)據(jù)目錄塞文件文件損壞概率極高。6.4 順手把緩存治理和容器清理做了Redis做中間件用久了最大的敵人不是性能而是緩存本身。Key設(shè)計(jì)不合理、value過大、過期時間設(shè)成永久慢慢把內(nèi)存拖垮。容器環(huán)境下我見過太多人把所有數(shù)據(jù)塞進(jìn)Redis然后看著內(nèi)存報(bào)警。緩存治理的基礎(chǔ)操作就是給Redis設(shè)置淘汰策略。6.1里提到的maxmemory-policy allkeys-lru適合大部分緩存場景內(nèi)存滿了自動淘汰最久沒用的Key。同時要在業(yè)務(wù)層給Key加統(tǒng)一的過期時間別指望兜底策略扛住所有臟數(shù)據(jù)。另外容器體積會隨著鏡像的更新越來越大。定期清理一下沒用的容器和鏡像能避免磁盤爆掉docker container prune docker image prune這些命令不會影響正在運(yùn)行的容器但會清掉已停止的容器和懸空鏡像。如果要強(qiáng)制清空所有未使用資源用docker system prune -a執(zhí)行前想清楚Redis的volume如果沒有掛載宿主機(jī)路徑會連數(shù)據(jù)一起刪掉。最后說一點(diǎn)我自己的習(xí)慣。用Docker跑Redis踩過的最大跟頭就是一開始只圖能啟動密碼不設(shè)、數(shù)據(jù)不掛volume、配置不持久化結(jié)果一次docker system prune把開發(fā)環(huán)境的緩存全清空了?，F(xiàn)在我的做法是每個項(xiàng)目第一次拉Redis容器時先把redis.conf、命名卷、密碼三類事情配齊再考慮端口和主從。你按這篇文章的順序先把最小命令跑通然后立刻補(bǔ)上持久化和密碼再研究主從后面基本不會有大坑。如果你在Windows上還卡在Docker Desktop啟動階段別急著繼續(xù)往下折騰容器回頭把虛擬化那一章看完要先讓舞臺搭起來演員才有地方施展。