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