1. 開篇Redis三件套到底指的是哪三樣如果你跟Redis打交道超過一周遲早會在各種文檔、招聘要求、生產(chǎn)事故復(fù)盤里撞見這三個名字redis-cli、hiredis 和 redis-benchmark。它們偶爾被混為一談但實際上分工完全不同。redis-cli是Redis官方自帶的命令行客戶端一堆運維命令和日常調(diào)試都靠它hiredis是C語言的客戶端庫凡是需要在自己的程序里操作Redis的C/C開發(fā)者基本繞不開它redis-benchmark則是跟Redis一起發(fā)布的壓測工具想搞清楚你的Redis到底能扛多少并發(fā)它是最省事的選擇。這三樣東西放在一起恰好覆蓋了Redis使用場景里最核心的三個維度第一人直接操作Redis也就是調(diào)試、排查、管理第二程序操作Redis也就是業(yè)務(wù)代碼里的數(shù)據(jù)讀寫第三Redis本身的能力邊界也就是在沒有業(yè)務(wù)邏輯干擾下的極限性能。一個后端工程師如果能把這三樣東西吃透那Redis的日常使用基本不會有什么大坑了。這篇文章我會把自己實際用下來的經(jīng)驗寫清楚包括命令細節(jié)、C客戶端接入的常見坑、壓測參數(shù)怎么解讀以及現(xiàn)在網(wǎng)上特別熱的“redis-cli flushall”這個危險命令的前因后果。適合誰看呢如果你是剛接觸Redis的運維或后端開發(fā)這篇文章能幫你把工具鏈路串起來少走不少彎路如果你已經(jīng)在生產(chǎn)環(huán)境里用了Redis那中間那些關(guān)于hiredis超時設(shè)置、benchmark結(jié)果誤讀、flushall誤操作的內(nèi)容應(yīng)該也能讓你有點收獲。我不打算照著官方文檔復(fù)讀一遍那些你隨時能查我這里只講折騰過之后才明白的事情。2. 三者定位與選型邏輯先搞清楚誰負責哪一層2.1 一條Redis請求的完整生命周期在聊工具之前我們得先想清楚一個最基本的問題一條數(shù)據(jù)是怎么從你的業(yè)務(wù)程序里跑到Redis服務(wù)器的簡單說就是TCP連接、發(fā)命令、收響應(yīng)這三步。但工具不一樣它們的關(guān)注點差很多。redis-cli站在人的角度幫你把命令拼成RESP協(xié)議格式發(fā)送出去再把返回結(jié)果顯示在終端上。你輸入GET foo它負責的是把這個命令變成Redis服務(wù)器能解析的字節(jié)流。這個過程里你不需要考慮序列化、連接池、重連這些cli全都默默處理了。它的價值在于交互性一條命令敲下去馬上看到結(jié)果出了問題也能立刻復(fù)現(xiàn)驗證。hiredis是站在C程序的角度。它是一套庫你編譯鏈接它之后可以在自己的代碼里調(diào)用redisCommand這類API來和Redis通信。這個時候核心矛盾就不是“人能不能看懂輸出”而是“程序能不能穩(wěn)定高效地跑”。hiredis要處理連接管理、命令拼接、緩沖區(qū)讀寫、響應(yīng)解析、錯誤處理這些事情在cli里看不見但在庫的使用中全得面對。為什么很多公司把hiredis稱為Redis客戶端的事實標準因為它夠底層、夠穩(wěn)定、夠簡單沒有花里胡哨的框架邏輯一個文件就能集成進去。redis-benchmark有點特殊它不是客戶端而是“壓測負載生成器”。它用最簡單的模型不斷往Redis發(fā)命令統(tǒng)計每秒能完成多少次請求以及延遲分布。它的價值在于基準測試衡量的是Redis服務(wù)器本身在不同命令、不同數(shù)據(jù)大小、不同并發(fā)下的表現(xiàn)。注意它衡量的不是你的業(yè)務(wù)程序?qū)懙煤貌缓枚荝edis這顆“發(fā)動機”在理想工況下能輸出多少馬力。2.2 日常使用里的場景取舍我在實際工作中見過不少把這三者混為一談的情況。比如有人寫業(yè)務(wù)代碼時為了圖省事直接system調(diào)redis-cli去執(zhí)行命令這在大促鏈路里就是定時炸彈進程fork、網(wǎng)絡(luò)連接反復(fù)建立性能損耗遠高于直接用hiredis這類庫也有人拿redis-benchmark的測試結(jié)果去估算生產(chǎn)環(huán)境的容量這也是誤區(qū)因為生產(chǎn)環(huán)境有業(yè)務(wù)邏輯、網(wǎng)絡(luò)抖動、慢查詢、大Key等各種干擾因素benchmark只能作為上限參考。選型邏輯其實一句話就能講清楚你需要交互式排查用redis-cli你的程序要連Redis用hiredis或者你所在語言對應(yīng)的官方客戶端你想知道Redis的硬件資源能支撐多高并發(fā)用redis-benchmark。三個工具之間不是替代關(guān)系而是互補關(guān)系。新手最容易犯的錯就是把它們放在同一個維度里比較然后問“哪個更好”實際答案是“哪個更合適你現(xiàn)在要做的事”。3. redis-cli實戰(zhàn)細節(jié)不只是敲命令的工具3.1 連接方式與常用參數(shù)很多人用redis-cli就是redis-cli回車連本機的默認端口6379再輸入命令。但這遠遠不夠。生產(chǎn)環(huán)境里Redis往往有密碼、在不同機器上、甚至有多個實例如果只會默認連接那基本寸步難行。我常用的連接寫法是這樣的redis-cli -h 10.0.1.5 -p 6380 -a 你的密碼 --no-auth-warning這里有個細節(jié)容易坑到新手-a參數(shù)直接帶密碼的話服務(wù)器日志和shell歷史里會留下痕跡所以一般建議用環(huán)境變量REDISCLI_AUTH來傳密碼命令長這樣export REDISCLI_AUTH你的密碼 redis-cli -h 10.0.1.5 -p 6380另外如果Redis實例數(shù)量多我強烈建議在配置文件或者啟動腳本里把這些默認值固化下來。用--connect-timeout控制連接超時--tls開啟TLS加密連接--sni指定SNI這些參數(shù)在高安全要求的環(huán)境里都用得上。實操中還有個很實用的用法就是不進入交互模式直接執(zhí)行單條命令后返回結(jié)果這在shell腳本里非常好用redis-cli -h 10.0.1.5 -p 6380 GET user:123:name配合管道符還可以批量處理比如把一堆key從文件里讀出來挨個查詢cat keys.txt | xargs -I{} redis-cli -h 10.0.1.5 -p 6380 GET {}這會一個key建立一次連接效率不高但勝在簡單直觀。如果key數(shù)量大我更推薦用--pipe模式批量導(dǎo)入命令那個后面單獨說。3.2 排查慢查詢和熱Key的實用命令說實話日常排查Redis性能問題用redis-cli的幾個內(nèi)置命令能解決大部分問題。首推的是SLOWLOG命令它負責查看Redis執(zhí)行的慢查詢記錄。Redis的慢查詢標準是執(zhí)行時間超過某個閾值默認是10毫秒可以通過配置slowlog-log-lower-than調(diào)整。實際排查時我會這樣操作redis-cli slowlog get 10這條命令取最近10條慢查詢記錄能看到執(zhí)行時間戳、耗時、執(zhí)行的命令。當年查線上問題時用slowlog get一眼就看出來有個SMEMBERS操作掃了百萬級別的集合耗時1.2秒直接把那個key拖垮了。另一個排查熱Key的思路是--hotkeys不過要注意這個功能需要Redis 4.0及以上版本并且需要打開object-max-scan相關(guān)配置運行后它會掃內(nèi)存找出訪問頻率最高的keyredis-cli --hotkeys輸出里會顯示每個key的訪問頻次、占用內(nèi)存等信息做緩存熱點分析時相當直觀。不過注意這命令會掃描整個key空間生產(chǎn)環(huán)境用的時候要挑業(yè)務(wù)低峰期。還有個排查集群狀態(tài)的命令組合redis-cli --cluster check能檢查集群健康度redis-cli --cluster info能看到槽位分配情況。哪怕是單機環(huán)境redis-cli info memory、redis-cli info stats這些都值得養(yǎng)成習慣畢竟定位問題最快的路徑往往是從基本信息開始的。3.3 --pipe批量導(dǎo)入的正確姿勢如果你要往Redis里塞大量數(shù)據(jù)一條條SET太慢for循環(huán)也是淚。官方其實給了一個效率很高的方式--pipe參數(shù)。它的原理是客戶端把命令按RESP協(xié)議格式組裝好一次性發(fā)給Redis服務(wù)端服務(wù)端再批量執(zhí)行。我實測過千級、萬級的key用這種方式導(dǎo)入速度比逐條命令快一個數(shù)量級以上。構(gòu)建數(shù)據(jù)格式是個小門檻。注意這里不是簡單的換行分隔而是RESP協(xié)議格式。比如要設(shè)置一個字符串key對應(yīng)的數(shù)據(jù)文件要寫成這樣*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n人肉寫這個格式容易瘋所以我一般用腳本生成。比如用Pythonimport sys def build_resp_command(*args): parts [f*{len(args)}\r\n] for arg in args: arg_bytes arg.encode(utf-8) parts.append(f${len(arg_bytes)}\r\n) parts.append(arg.decode(utf-8)) parts.append(\r\n) return .join(parts).encode(utf-8) with open(data.txt, wb) as f: for i in range(10000): cmd build_resp_command(SET, fbatch:key:{i}, fvalue-{i}) f.write(cmd)生成后用redis-cli --pipe data.txt導(dǎo)入。注意--pipe模式下如果數(shù)據(jù)量大會占較多內(nèi)存因為客戶端要構(gòu)建完整的輸出緩沖區(qū)。導(dǎo)入完成后命令行的反饋里會顯示導(dǎo)入的數(shù)據(jù)量、錯誤數(shù)、耗時反正我每次看到那個數(shù)字都比一條條set快好幾倍心情還是不錯的。3.4 千萬別手滑redis-cli flushall與誤刪數(shù)據(jù)的保護說道redis-cli我必須專門開一個小節(jié)來講“redis-cli flushall”這件事因為網(wǎng)上相關(guān)的討論熱度一直不減身邊也確實有人因此吃過虧。FLUSHALL這個命令的作用是清空當前Redis實例里的所有數(shù)據(jù)還有個FLUSHDB是清空當前選中的數(shù)據(jù)庫。開發(fā)環(huán)境里隨便用無所謂但生產(chǎn)環(huán)境一旦執(zhí)行數(shù)據(jù)瞬間就沒了如果沒開AOF重寫或RDB快照恢復(fù)成本能讓人崩潰。為什么隨手敲了FLUSHALL會“誤執(zhí)行”我分析下來主要原因有兩個一是redis-cli默認不會二次確認二是很多人的備份策略不完善。Redis官方其實早就考慮過這個場景從4.0開始你可以在配置文件里開啟rename-command把FLUSHALL重命名成一個別人猜不到的名字比如rename-command FLUSHALL admin_flushall_2024這樣即使別人連上你的Redis敲FLUSHALL也會收到未知命令的錯誤。但說實話這招防君子不防小人真正接入生產(chǎn)系統(tǒng)的程序如果寫了FLUSHALL重命名后它會直接報錯反而暴露了代碼問題。我的建議是生產(chǎn)環(huán)境把下面的保護措施做成標配開啟AOF持久化并配置appendfsync everysec這樣最多丟1秒數(shù)據(jù)用SAVE或BGSAVE定期做RDB快照備份文件備份到異地禁止應(yīng)用賬號使用CONFIG SET和FLUSHALL用rename-command把這些高危命令換掉使用Redis 6.0及以后版本中的ACL功能為業(yè)務(wù)賬號分配最小權(quán)限。再補充一句很多人有個誤解以為FLUSHALL之后馬上用SHUTDOWN NOSAVE可以避免數(shù)據(jù)落盤從而防止數(shù)據(jù)被清掉。實際情況恰恰相反如果你開了RDB執(zhí)行FLUSHALL之后再做SHUTDOWN SAVE或自動快照清空后的狀態(tài)反而會被寫進快照文件里恢復(fù)出來的還是一個空庫。所以一旦發(fā)生誤操作正確順序是第一時間斷開應(yīng)用連接檢查有沒有AOF重寫進程或者RDB快照進程正在跑能停就停然后從最近的備份做恢復(fù)。這些操作要提前演練過等事故真發(fā)生了再翻文檔那心態(tài)完全不一樣。4. hiredis接入指南C程序里操作Redis的硬碰硬體驗4.1 初始化與連接池基本套路hiredis的安裝方式很直接從GitHub拉源碼或者通過系統(tǒng)的包管理器安裝。在Linux上包名一般是libhiredis-dev裝好后會有/usr/include/hiredis/hiredis.h和libhiredis.so這樣的文件。代碼里最基本的連接方式是這樣#include hiredis/hiredis.h redisContext *ctx redisConnect(127.0.0.1, 6379); if (ctx NULL || ctx-err) { if (ctx) { printf(連接錯誤: %s\n, ctx-errstr); redisFree(ctx); } else { printf(無法分配redisContext\n); } return -1; } redisFree(ctx);很多開發(fā)者第一次寫完這段代碼都會問一個問題為什么每次操作Redis都要重復(fù)創(chuàng)建連接如果你只是寫個一次性腳本無所謂但在高并發(fā)服務(wù)里每次都重新建立TCP連接的開銷非常大。正確的做法是維護一個連接池把redisContext對象復(fù)用起來或者用redisConnectWithTimeout加超時防止連接卡死struct timeval timeout {1, 500000}; // 1.5秒 redisContext *ctx redisConnectWithTimeout(127.0.0.1, 6379, timeout);4.2 命令執(zhí)行與結(jié)果解析的幾種寫法hiredis里最常用的命令函數(shù)是redisCommand和redisCommandArgv。前者把命令格式化成字符串后發(fā)送后者用參數(shù)數(shù)組方式避免拼接注入風險。直接看一眼代碼redisReply *reply; reply redisCommand(ctx, SET %s %s, name, 張三); if (reply NULL) { printf(命令執(zhí)行失敗\n); return -1; } if (reply-type REDIS_REPLY_ERROR) { printf(命令錯誤: %s\n, reply-str); freeReplyObject(reply); return -1; } printf(結(jié)果類型: %d\n, reply-type); if (reply-type REDIS_REPLY_STRING) { printf(值: %s\n, reply-str); } freeReplyObject(reply);這里有個細節(jié)值得注意redisReply對象的類型有很多種常見的包括REDIS_REPLY_STRING、REDIS_REPLY_ARRAY、REDIS_REPLY_INTEGER、REDIS_REPLY_NIL、REDIS_REPLY_STATUS、REDIS_REPLY_ERROR。每種類型對應(yīng)的解析方式完全不同。新手最容易踩的坑是把REDIS_REPLY_INTEGER當成字符串解析打印出來全是奇怪的數(shù)字或者反過來拿字符串去當數(shù)字做運算直接段錯誤。一定要養(yǎng)成先檢查type再決定怎么讀內(nèi)容的習慣。在非阻塞模式下處理方法是完全不同的。hiredis為異步場景提供了事件驅(qū)動APIredisAsyncContext配合redisAsyncCommand注冊回調(diào)函數(shù)。你的程序在發(fā)出命令后不等結(jié)果繼續(xù)處理其他事情Redis返回的數(shù)據(jù)到了之后事件循環(huán)觸發(fā)回調(diào)。這個方式在單線程高性能網(wǎng)絡(luò)服務(wù)里很有優(yōu)勢但代碼復(fù)雜度也上來了。我在自己的工具里用的比較多的是同步模式異步模式一般配合libevent或libuv使用。redisAsyncContext *actx redisAsyncConnect(127.0.0.1, 6379); if (actx-err) { printf(異步連接失敗: %s\n, actx-errstr); return -1; } redisAsyncCommand(actx, callback, SET key value);回調(diào)函數(shù)里處理redisReply指針記得在回調(diào)里用完調(diào)用freeReplyObject釋放內(nèi)存不然內(nèi)存泄漏得悄無聲息。4.3 超時、重連與內(nèi)存管理的坑hiredis最被詬病的一點是它不太管“重連”這件事。連接斷了就是斷了它不會自動幫你恢復(fù)你需要自己用redisReconnect或者重新redisConnect。我在日志系統(tǒng)里接入Redis時第一版代碼就漏了重連判斷結(jié)果Redis實例一重啟日志全丟了排查半天才發(fā)現(xiàn)連接已經(jīng)是死連接傻傻往里寫。后來養(yǎng)成了習慣每次命令執(zhí)行前檢查ctx-err出錯就嘗試重連。另一個高頻問題是內(nèi)存管理。我記得redisReply必須用freeReplyObject釋放這是hiredis最基礎(chǔ)的內(nèi)存紀律。多線程環(huán)境下線程安全同樣要小心同一個redisContext不能被多個線程同時使用每個線程要么建獨立連接要么加鎖。因為hiredis內(nèi)部緩沖區(qū)不是線程安全的并發(fā)讀寫輕則數(shù)據(jù)錯亂重則崩潰。命令拼接的安全問題我在這里額外強調(diào)一下。用redisCommand(ctx, SET %s, user_input)這種寫法如果user_input里帶了引號或者特殊字符很可能被解析成多個參數(shù)甚至導(dǎo)致命令注入。雖然Redis沒有SQL那種強結(jié)構(gòu)注入但安全風格還是要小心。更推薦的寫法是redisCommandArgv它接受參數(shù)數(shù)組不會把輸入當命令去解析char *argv[] {SET, user:name, 張三}; size_t argvlen[] {3, 9, 6}; redisReply *reply redisCommandArgv(ctx, 3, argv, argvlen);實際編碼時用redisCommand做調(diào)試很方便但正式上線代碼我一般全部改成redisCommandArgv省心很多。5. redis-benchmark壓測指南讀懂數(shù)字背后的門道5.1 壓測參數(shù)的正確打開方式redis-benchmark作為Redis自帶的壓測工具用起來其實很簡單但看懂輸出一點都不簡單。直接跑redis-benchmark -h 127.0.0.1 -p 6379它會用50個并發(fā)客戶端發(fā)100000個請求默認使用PING_INLINE、SET、GET等若干命令進行測試。輸出結(jié)果類似下面這樣 SET 100000 requests completed in 1.20 seconds 50 parallel clients 3 bytes payload keep alive: 1 99.57% 1 milliseconds 100.00% 1 milliseconds 83333.33 requests per second我見過不少人一看到83333 requests per second就開始拿這個數(shù)字去估算生產(chǎn)容量這是特別危險的。這個數(shù)字是極限理想值它沒有經(jīng)過業(yè)務(wù)邏輯、沒有限制連接數(shù)、沒有磁盤持久化競爭更不能代表真實線上表現(xiàn)。壓測前有幾個參數(shù)值得重點關(guān)注我先列出來-n請求總數(shù)越大越穩(wěn)定建議至少十萬級。-c并發(fā)連接數(shù)模擬同時活動的客戶端數(shù)量。-P管道批處理數(shù)量用管道時客戶端可以一次性發(fā)送多個請求吞吐會大幅度提升。-d數(shù)據(jù)大小默認3字節(jié)壓測大Key需要改大這個值。-t只壓測指定命令比如-t SET,GET。-r隨機key范圍避免所有請求都落在同一個key上。-q安靜模式只輸出最終結(jié)果。比如你想模擬100個客戶端并發(fā)寫10萬次、數(shù)據(jù)大小128字節(jié)、key隨機分布在100萬個里命令就可以寫成redis-benchmark -h 127.0.0.1 -p 6379 -t SET -n 100000 -c 100 -d 128 -r 1000000 -q5.2 延遲分布與百分位的解讀很多人只看requests per second這一行忽略了延遲百分位信息。Redis的延遲分布能暴露許多吞吐量掩蓋的問題比如99%的請求都在1毫秒內(nèi)完成但99.9%的請求突然跳到50毫秒這中間往往有阻塞點可能是慢查詢、網(wǎng)絡(luò)抖動、或者Redis后臺的RDB快照在fork時引發(fā)的短暫暫停。壓測輸出里的百分位數(shù)據(jù)非常重要我一般會關(guān)注這幾個值1 milliseconds的占比、10 milliseconds的占比、最大響應(yīng)時間。如果你發(fā)現(xiàn)尾部延遲很高就需要用--latency參數(shù)做更細的統(tǒng)計它會輸出平均延遲、最大延遲和標準差。用--csv參數(shù)還能把結(jié)果導(dǎo)出成CSV方便做多次測試對比redis-benchmark -h 127.0.0.1 -p 6379 -t GET -n 100000 -c 100 --csv result1.csv在生產(chǎn)環(huán)境做基準測試時最好在Redis服務(wù)器上用INFO命令把當時的內(nèi)存、連接數(shù)、命中率、持久化狀態(tài)都記錄下來。這樣后續(xù)再比對壓測數(shù)據(jù)才能準確歸因。純壓一次不記上下文等于白測。5.3 常見誤區(qū)把benchmark結(jié)果當承諾這里我專門辟幾個謠這些全是我見過或踩過的坑。第一個誤區(qū)壓測數(shù)字高就代表機器好。不一定。同樣是這臺機器如果壓測時用了管道-P 16吞吐量會大幅上漲甚至翻幾倍但這并不能直接體現(xiàn)在你的業(yè)務(wù)里因為業(yè)務(wù)程序不可能每時每刻都靠管道把請求攢起來發(fā)。第二個誤區(qū)并發(fā)數(shù)越大越好。實際壓測時你會發(fā)現(xiàn)一個規(guī)律并發(fā)數(shù)從50提升到500吞吐量一開始上漲隨后會趨于平緩甚至下降。原因是CPU核心數(shù)有限一旦處理能力飽和更多并發(fā)只會增加隊列等待和上下文切換開銷。要找準這個拐點就多跑幾組不同并發(fā)數(shù)對比比如-c 50、-c 200、-c 500記錄各自的QPS和延遲分布。第三個誤區(qū)壓測命令太單一。生產(chǎn)環(huán)境里有讀有寫有大Key小Key有TTL過期甚至還有LREM、ZADD這類復(fù)雜操作。只測GET/SET得出來的結(jié)論放到真實場景里基本不可用。想壓測復(fù)雜命令可以用-t指定命令比如redis-benchmark -h 127.0.0.1 -p 6379 -t LPUSH,LRANGE -n 50000 -c 100 -r 100000這里LPUSH模擬寫入LRANGE模擬讀列表。把多種命令混合起來才能模擬出比較接近業(yè)務(wù)的請求模型。5.4 基準測試的進階用法與擴展方案其實redis-benchmark的定位是“快速驗證用的標準負載發(fā)生器”如果壓測要求更高比如需要自定義腳本模擬業(yè)務(wù)邏輯、控制請求的發(fā)送間隔那更合適的方式是用memtier_benchmark這類工具或者直接自己寫壓測腳本。個人實踐中我一般先用redis-benchmark做一輪粗測快速判斷Redis實例有沒有明顯的性能瓶頸比如是不是到了網(wǎng)絡(luò)帶寬極限、CPU是不是已經(jīng)打滿然后如果有必要再編排更復(fù)雜的壓測場景。比較推薦的做法是在保持-n請求總量不變的前提下做幾組對照實驗。比如一組是數(shù)據(jù)大小32字節(jié)一組是1024字節(jié)一組是10KB。Redis的吞吐量會隨數(shù)據(jù)大小明顯變化這條曲線對你的容量規(guī)劃非常有參考價值。Redis官方還提供了一個調(diào)試利器--bigkeys它能掃描Key空間里占用內(nèi)存最大的key在壓測過程中能發(fā)現(xiàn)是否有大Key拖慢了其他命令。這個配合redis-benchmark使用往往能找到性能問題的根源。簡單說benchmark只是告訴你“多快”而--bigkeys告訴你“為什么沒想象中的快”。6. 守護Redis實例安全指南與日常體檢清單6.1 ACL權(quán)限與高危命令治理Redis 6.0之后ACLAccess Control List成為標配。用redis-cli管理ACL非常方便可以為不同程序、不同人員分配不同權(quán)限。比如給業(yè)務(wù)程序賬號只授權(quán)基本讀寫命令不授權(quán)FLUSHALL、CONFIG、SHUTDOWN這類高危命令redis-cli ACL SETUSER app_user on 密碼 ~app:* read write -admin這里read write -admin的意思是允許讀取和寫入類命令禁止admin類別命令。~app:*是key模式表示只能訪問以app:開頭的key。這套ACL權(quán)限下來就算應(yīng)用被入侵能造成的最大危害也被限制在app前綴的key里不能翻看全庫的數(shù)據(jù)。6.2 日常體檢這些信息你多久沒看了我在每周的巡檢里會固定跑幾條redis-cli命令用來判斷Redis的運行狀態(tài)是否健康redis-cli info memory查看used_memory、used_memory_rss、mem_fragmentation_ratio內(nèi)存碎片率如果長期大于1.5說明內(nèi)存碎片嚴重可能需要重啟實例或調(diào)整jemalloc配置。redis-cli info persistence確認rdb_last_bgsave_status和aof_last_bgrewrite_status是否都是ok一旦出現(xiàn)失敗磁盤IO可能存在瓶頸。redis-cli info stats看total_commands_processed、expired_keys、evicted_keys等指標。突然飆升的evicted_keys說明內(nèi)存壓力大可能導(dǎo)致緩存雪崩。redis-cli info clients確認connected_clients是否合理有沒有積壓連接。redis-cli info cpu看used_cpu_sys和used_cpu_user如果CPU長期跑滿就需要考慮集群擴容了。不建議每次都敲一長串命令可以把它們寫進一個腳本定時執(zhí)行把輸出拉到一個監(jiān)控系統(tǒng)里去。沒有監(jiān)控的Redis等于蒙著眼睛開車出事是必然的只是時間問題。6.3 誤操作后的恢復(fù)流程復(fù)盤接前面第3.4節(jié)我再詳細展開一次誤執(zhí)行FLUSHALL后的恢復(fù)流程。這個場景我是真真實實在測試環(huán)境里演過的也見過同行分享生產(chǎn)事故復(fù)盤。整個流程按時間線分三步第一步凍結(jié)。一旦發(fā)現(xiàn)誤操作先別急著重啟Redis。用redis-cli shutdown nosave關(guān)閉實例避免后續(xù)的自動快照把清空后的狀態(tài)持久化覆蓋掉最后一份RDB文件。如果你的Redis開啟了AOF關(guān)閉過程會觸發(fā)AOF重寫嗎這部分不同版本有差異建議先把Redis停了再檢查磁盤上的AOF文件大小和時間戳。第二步檢查備份。找出最近的RDB文件或AOF文件。注意RDB文件的生成時間非常重要如果在FLUSHALL之前幾分鐘剛剛生成過那是最理想的如果你只開AOF恢復(fù)時用redis-check-aof先校驗一下文件完整性再讓Redis加載。用合適的備份文件覆蓋掉本地的dump.rdb和appendonly.aof再啟動Redis實例。第三步回放增量操作。AOF文件里如果有FLUSHALL命令本身恢復(fù)時會再次執(zhí)行一遍又把庫清空。所以在啟動之前要手動編輯AOF文件把FLUSHALL、FLUSHDB這樣的高危命令行刪除。用編輯器處理AOF文件時要格外小心必須保留RESP協(xié)議的格式刪完再用redis-check-aof驗證一下。如果數(shù)據(jù)量巨大可以選用Redis 6.2版本以上提供的MODULE或者更自動化的恢復(fù)腳本但核心思路還是那兩個字快、準。經(jīng)過這個流程我最大的體會是與其每次祈禱不要手滑不如提前把權(quán)限、備份、重命名高危命令這些事做成自動化。Redis本身是一個極其可靠的工具出事故的從來不是它自己而是用的人。7. 三件套協(xié)同工作的一個實戰(zhàn)案例講了這么多概念不如串起來看一個真實案例。假設(shè)我有個活動服務(wù)用Redis做用戶維度的計數(shù)和排行榜一天要處理千萬級請求。為了保證穩(wěn)定我想知道當前這臺機器上的Redis能不能扛住明天的活動峰值。這個場景里三件套是怎么配合的首先我用redis-cli查看當前實例的負載情況內(nèi)存占用、連接數(shù)、慢查詢、命中率。結(jié)果發(fā)現(xiàn)used_memory_rss偏高說明內(nèi)存碎片需要關(guān)注同時connected_clients只有40個遠低于預(yù)期慢查詢里經(jīng)常出現(xiàn)ZRANGEBYSCORE對大key的操作這提示排行榜可能需要分片了。然后我用redis-benchmark按業(yè)務(wù)比例做壓力摸底參數(shù)上模擬活動的兩個主要動作寫計數(shù)INCR和讀排行榜ZREVRANGE。命令大概是redis-benchmark -h 127.0.0.1 -p 6379 -t INCR,ZREVRANGE -n 200000 -c 200 -r 1000000 -d 64 -P 2 -q跑完發(fā)現(xiàn)INCR的QPS大約8萬ZREVRANGE因為key長度和數(shù)據(jù)量的影響只有2萬多差距明顯。這提示如果活動高峰里讀排行占比很高需要給Redis加緩存或者做讀寫分離否則扛不住。最后我需要確認自己寫的C程序接的hiredis連接池參數(shù)是否合理。于是我在壓測的同時跑了一個接入hiredis的模擬程序連續(xù)發(fā)起INCR請求。結(jié)果發(fā)現(xiàn)hiredis側(cè)的最大延遲比redis-benchmark報出來的高了近3倍。排查后定位是因為連接池只開了10個連接在200并發(fā)需求面前嚴重排隊。調(diào)大連接池到50后延遲立即掉下來了。整個過程把三件套從運維排查、性能摸底、代碼接入三個角度串聯(lián)了起來。沒有redis-cli我很難快速定位到已有的大Key問題沒有redis-benchmark我拿不出量化參數(shù)做容量評估沒有hiredis的實戰(zhàn)驗證我只能停留在工具層面根本沒能發(fā)現(xiàn)連接池造成的性能瓶頸。這三樣東西在真實運維和開發(fā)場景里缺一不可。8. 收尾我在實操中的一點體會最后說點個人的經(jīng)驗吧。用Redis這么多年redis-cli、hiredis 和 redis-benchmark這三樣其實不只是一個工具鏈更像是一面鏡子照出你對Redis整體的理解程度。很多人覺得redis-cli太簡單實際上--pipe、--bigkeys、--hotkeys這些高級用法才是效率分水嶺很多人覺得hiredis只是C語言的API封裝實際上連接池、超時、重連、內(nèi)存管理這些你想躲都躲不掉很多人拿benchmark跑個分就完事實際上延遲百分位、key大小、并發(fā)數(shù)、命令混合度這些變量才是壓測里真正有價值的信息。我自己的習慣是每接手一個新的Redis環(huán)境第一件事就是先跑一輪redis-cli的信息收集和慢查詢檢查再跑一輪benchmark做基線記錄最后再檢查程序接入層用的客戶端庫hiredis或者其他語言等價物的連接參數(shù)配置。這套流程走下來大部分風險點基本都能提前暴露出來。至少到目前為止我還沒在Redis上出過特別丟臉的生產(chǎn)事故提前做功課的功勞占一大半。數(shù)據(jù)無價操作有風險。希望大家在享受Redis高性能的同時也保持一份敬畏心多花十分鐘做權(quán)限治理和備份演練這比任何事后補救都值。