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