據(jù)安全加固實(shí)戰(zhàn)：訪問控制、持久化與分布式鎖)
凌晨?jī)牲c(diǎn)半監(jiān)控面板上Redis主節(jié)點(diǎn)的CPU使用率突然拉滿慢查詢數(shù)量肉眼可見地往上跳。登錄服務(wù)器一看公網(wǎng)安全組里竟然掛著6379的放行規(guī)則一臺(tái)沒有任何認(rèn)證配置的Redis正被全網(wǎng)掃描工具輪番爆破。雖然最后沒造成數(shù)據(jù)清空但那一整晚排查的過程讓我意識(shí)到一個(gè)扎心的事實(shí)絕大多數(shù)團(tuán)隊(duì)對(duì)Redis數(shù)據(jù)安全的理解還停留在“不崩就行”的層面。Redis數(shù)據(jù)安全性這句話落到工程實(shí)踐里至少可以拆成四件事防非法訪問、防數(shù)據(jù)丟失、防運(yùn)行阻塞、防臟讀錯(cuò)寫。這四件事分別對(duì)應(yīng)網(wǎng)絡(luò)層防護(hù)、持久化策略、應(yīng)用層治理和分布式一致性。這篇文章我就按這幾個(gè)維度把我在生產(chǎn)環(huán)境里踩過的坑、排查過的事故、以及最終沉淀下來的一套可落地的加固方案完整梳理一遍。無論你把Redis當(dāng)緩存用、當(dāng)計(jì)數(shù)器用還是當(dāng)分布式鎖的底層存儲(chǔ)這篇文章都值得你花十分鐘過一遍。1. 先搞清楚Redis數(shù)據(jù)安全威脅模型的四個(gè)維度很多人一提數(shù)據(jù)安全第一反應(yīng)就是“加個(gè)密碼”。實(shí)際上Redis這類內(nèi)存型數(shù)據(jù)庫的安全問題遠(yuǎn)比一條requirepass配置復(fù)雜得多。我在評(píng)估一個(gè)Redis實(shí)例的安全性時(shí)通常按下面這張表來做威脅建模。威脅類型實(shí)際路徑后果示例未授權(quán)訪問端口暴露公網(wǎng)、空密碼、protected-mode關(guān)閉數(shù)據(jù)被遍歷、被篡改、被植入定時(shí)任務(wù)弱口令爆破Redis認(rèn)證協(xié)議簡(jiǎn)單高頻嘗試AUTH實(shí)例被接管數(shù)據(jù)被FLUSHALL清空危險(xiǎn)命令濫用KEYS、FLUSHALL、DEBUG等命令可執(zhí)行阻塞主線程、數(shù)據(jù)批量刪除、實(shí)例掛死進(jìn)程崩潰與宕機(jī)RDB/AOF配置不當(dāng)、服務(wù)器斷電丟失數(shù)分鐘甚至全部數(shù)據(jù)主從復(fù)制錯(cuò)亂failover后舊主重新加入、復(fù)制積壓區(qū)溢出新主數(shù)據(jù)被舊主覆蓋數(shù)據(jù)回退應(yīng)用層邏輯隱患Big Key、熱Key、序列化類型錯(cuò)亂慢查詢拖垮實(shí)例、incr命令報(bào)錯(cuò)、緩存雪崩分布式一致性問題鎖超時(shí)失效、主從切換鎖丟失并發(fā)重復(fù)執(zhí)行、超賣、重復(fù)下單這張表里的每一項(xiàng)我都見過真實(shí)的生產(chǎn)事故。比較諷刺的是最容易被團(tuán)隊(duì)忽視的恰恰是后半部分——很多人都認(rèn)真配過bind和requirepass但很少有人認(rèn)真回答“Redis所在服務(wù)器突然斷電你會(huì)丟多少數(shù)據(jù)”“主從切換的瞬間分布式鎖還能不能保證互斥”這兩個(gè)問題。Redis的安全范圍為什么和傳統(tǒng)數(shù)據(jù)庫不一樣關(guān)鍵在于它的定位。傳統(tǒng)MySQL是唯一數(shù)據(jù)源天然會(huì)有人認(rèn)真對(duì)待備份和權(quán)限Redis在很多團(tuán)隊(duì)眼里就是“加速層”丟了可以回源數(shù)據(jù)庫重建?？梢坏㏑edis里存了庫存、訂單號(hào)、驗(yàn)證碼、分布式鎖、接口冪等標(biāo)記這類有業(yè)務(wù)語義的數(shù)據(jù)它就的的確確是業(yè)務(wù)系統(tǒng)的一部分了。此時(shí)再拿“緩存隨便丟”的心態(tài)去運(yùn)維遲早會(huì)出事。所以這篇文章后續(xù)所有內(nèi)容都圍繞著上面表格里的四類風(fēng)險(xiǎn)展開訪問控制怎么收緊持久化怎么保證不丟應(yīng)用怎么寫才不把Redis搞掛分布式場(chǎng)景怎么避免錯(cuò)寫和重復(fù)執(zhí)行。2. 最容易出事的三個(gè)環(huán)節(jié)未授權(quán)訪問、弱口令、危險(xiǎn)命令這三個(gè)問題通常一起出現(xiàn)。早期Redis版本默認(rèn)配置只監(jiān)聽127.0.0.1這個(gè)默認(rèn)值其實(shí)是相對(duì)安全的真正出事的基本都是人為改配置改出來的bind 0.0.0.0、protected-mode no、不設(shè)密碼三件套齊活之后只要安全組或防火墻不小心放行了6379你的Redis就等于裸奔在公網(wǎng)。2.1 未授權(quán)訪問為什么這么普遍我接手過的一個(gè)項(xiàng)目?jī)?nèi)網(wǎng)Redis居然能被開發(fā)機(jī)直接無密碼連接登錄進(jìn)去發(fā)現(xiàn)里面存了大量用戶Session和驗(yàn)證碼。查下來原因很典型當(dāng)初搭建時(shí)圖省事復(fù)制了一份網(wǎng)上流傳的“通用配置”里面直接寫死了bind 0.0.0.0和protected-mode no然后一直沒人改。更隱蔽的情況是bind配置本身沒錯(cuò)但被部署在Docker容器里端口通過-p 6379:6379直接映射到了宿主機(jī)公網(wǎng)地址。容器內(nèi)部的bind 127.0.0.1只約束了容器網(wǎng)絡(luò)棧宿主機(jī)端口轉(zhuǎn)發(fā)根本不受這個(gè)限制。這種“容器隔離錯(cuò)覺”讓很多團(tuán)隊(duì)的Redis明明看著配置沒問題實(shí)際上公網(wǎng)一抓一個(gè)準(zhǔn)。檢查方法很簡(jiǎn)單在Redis服務(wù)器本地執(zhí)行redis-cli -h 127.0.0.1 -p 6379 ping如果能直接返回PONG而沒提示NOAUTH同時(shí)客戶端連接來源又不限于127.0.0.1那基本可以判定當(dāng)前實(shí)例處于未授權(quán)訪問狀態(tài)。2.2 弱口令和爆破Redis認(rèn)證機(jī)制的局限性Redis的認(rèn)證早期只有一層密碼也就是requirepass。它的問題在于密碼沒有強(qiáng)度校驗(yàn)機(jī)制而且Redis協(xié)議簡(jiǎn)單攻擊者可以用極低的成本暴力嘗試。某些掃描工具甚至專門維護(hù)了一份“Redis常見弱密碼表”從redis、123456到passw0rd挨個(gè)試。還有一種思路是直接限制來源。生產(chǎn)環(huán)境的Redis只應(yīng)該被特定應(yīng)用服務(wù)器訪問安全組/防火墻層面做來源IP白名單往往比一個(gè)強(qiáng)密碼更有效。密碼再強(qiáng)也怕客戶端連接串泄露來源IP限制住即使連接串泄露攻擊者也無法從外部觸達(dá)。2.3 危險(xiǎn)命令比刪庫更常見的是“手滑”和“爆破后的最后一擊”在Redis里KEYS *、FLUSHALL、FLUSHDB、CONFIG SET、DEBUG這類命令的破壞力很多人沒有概念。KEYS *在key數(shù)量達(dá)到百萬級(jí)別時(shí)會(huì)阻塞主線程數(shù)秒甚至更久。FLUSHALL一條命令清空所有數(shù)據(jù)卻不會(huì)像MySQL那樣彈出任何確認(rèn)。CONFIG SET甚至可以在運(yùn)行期動(dòng)態(tài)修改配置直接把保護(hù)機(jī)制關(guān)掉。我見過不止一次線上事故是因?yàn)橥略跍y(cè)試環(huán)境連錯(cuò)了Redis地址一個(gè)FLUSHALL把預(yù)發(fā)環(huán)境的緩存全部清掉接著流量全部打到數(shù)據(jù)庫把庫打出了慢查詢告警。防御上比較通用的是兩步第一在配置文件中用rename-command把危險(xiǎn)命令改名或禁用第二Redis 6.0之后的ACL功能能做到按用戶授權(quán)比如給業(yè)務(wù)應(yīng)用只開讀寫權(quán)限不開CONFIG、FLUSHALL等管理命令。2.4 網(wǎng)絡(luò)層安全別把安全寄托在Redis自身我在實(shí)際加固時(shí)會(huì)遵循一個(gè)原則Redis自身的安全配置是縱深防御的一層但絕不能是唯一一層。哪怕Redis配置得再嚴(yán)操作系統(tǒng)層面的防火墻、云平臺(tái)的安全組也要配合收斂端口暴露面。落地的檢查步驟大概是先看監(jiān)聽地址ss -lntp | grep 6379確認(rèn)只監(jiān)聽了內(nèi)網(wǎng)或回環(huán)地址。確認(rèn)云安全組和主機(jī)防火墻的入方向規(guī)則沒有放行0.0.0.0/0到6379。在配置文件中開啟protected-mode yes。設(shè)置強(qiáng)密碼或啟用ACL禁止空密碼啟動(dòng)。用rename-command禁用KEYS、FLUSHALL、CONFIG、DEBUG等管理類命令。定期用掃描工具做一次端口自檢模擬公網(wǎng)視角看6379是否可達(dá)。這套流程做完未授權(quán)訪問這個(gè)維度的風(fēng)險(xiǎn)基本就能堵住。3. 數(shù)據(jù)不丟比想象中難RDB、AOF與主從架構(gòu)的數(shù)據(jù)可靠性邊界很多團(tuán)隊(duì)對(duì)Redis持久化的理解就是“開了AOF應(yīng)該不會(huì)丟數(shù)據(jù)了吧”。實(shí)際排查過事故之后你會(huì)發(fā)現(xiàn)這句話離真相還差得很遠(yuǎn)。3.1 RDB快照的丟失窗口RDB是Redis默認(rèn)的持久化方式通過save或BGSAVE生成某個(gè)時(shí)間點(diǎn)的全量快照。它的最大特點(diǎn)是恢復(fù)快、文件緊湊但缺點(diǎn)也明顯在兩次快照之間的數(shù)據(jù)一旦進(jìn)程異常退出就全部丟失。默認(rèn)配置是save 900 1、save 300 10、save 60 10000意思是“900秒內(nèi)有1次寫入”“300秒內(nèi)有10次寫入”“60秒內(nèi)有1萬次寫入”三個(gè)條件任一滿足就觸發(fā)快照。注意這個(gè)條件組合意味著低流量時(shí)段理論上可能15分鐘才打一次快照這期間的數(shù)據(jù)丟失窗口就是15分鐘。3.2 AOF三種刷盤策略的取舍評(píng)估AOF通過追加日志的方式記錄每次寫操作重啟時(shí)重放日志來恢復(fù)數(shù)據(jù)。它的關(guān)鍵參數(shù)是appendfsync有三個(gè)取值appendfsync配置刷盤時(shí)機(jī)丟失窗口性能影響always每條寫命令都調(diào)用fsync最多一條命令最高吞吐量明顯下降everysec每秒調(diào)用一次fsync最多1秒數(shù)據(jù)中等生產(chǎn)環(huán)境常用no交給操作系統(tǒng)決定不確定可能較多最好但安全性最低生產(chǎn)環(huán)境我通常選everysec在性能和安全性之間找一個(gè)平衡點(diǎn)。Redis官方文檔的表述也是這樣一個(gè)默認(rèn)取向。但這里要特別提醒一件事AOF的“最多丟1秒”是建立在操作系統(tǒng)正常運(yùn)行的前提下的。服務(wù)器物理宕機(jī)、內(nèi)核panic、云主機(jī)被強(qiáng)制重啟這類場(chǎng)景數(shù)據(jù)丟失可能比預(yù)期更多。因?yàn)閑verysec策略下Redis子進(jìn)程獨(dú)立執(zhí)行fsync如果操作系統(tǒng)還沒來得及把緩沖落盤就斷電緩沖里積壓的那一小段時(shí)間數(shù)據(jù)就沒了。3.3 從庫強(qiáng)一致保護(hù)min-replicas機(jī)制主從架構(gòu)下很多人以為“有從庫就等于數(shù)據(jù)安全”。但從庫同步是有延遲的主庫會(huì)無腦接受寫入并返回成功從庫還沒跟上。如果此時(shí)主庫宕機(jī)觸發(fā)哨兵切換新主庫可能缺失了最后幾秒的寫入數(shù)據(jù)。更要命的是如果舊主庫恢復(fù)后重新加回集群它發(fā)現(xiàn)自己落后了新主會(huì)主動(dòng)清空本地?cái)?shù)據(jù)去追隨新主此時(shí)如果它的數(shù)據(jù)比新主還新反而會(huì)把新主覆蓋不會(huì)Redis的復(fù)制邏輯里舊主會(huì)被清空并復(fù)制新主數(shù)據(jù)這會(huì)造成一個(gè)“回退”——原本已寫入的數(shù)據(jù)被抹掉。針對(duì)這種場(chǎng)景Redis提供了min-replicas-to-write和min-replicas-max-lag兩個(gè)參數(shù)含義是當(dāng)健康的從庫數(shù)量低于閾值或從庫的復(fù)制延遲超過了max-lag秒主庫就拒絕寫入。這樣可以在極端情況下放棄可用性保數(shù)據(jù)一致性。min-replicas-to-write 1 min-replicas-max-lag 10這個(gè)配置的含義是至少要有1個(gè)從庫的延遲在10秒以內(nèi)主庫才接受寫入。如果所有從庫都掉隊(duì)了主庫會(huì)直接返回錯(cuò)誤而不是繼續(xù)無腦寫。代價(jià)是短暫的服務(wù)不可用但換來的是一次災(zāi)難恢復(fù)后數(shù)據(jù)不會(huì)無故回退。3.4 文件損壞與備份恢復(fù)演練Redis的數(shù)據(jù)文件在極端情況下也會(huì)損壞最常見的場(chǎng)景是AOF文件末尾寫了半條命令就斷電此時(shí)Redis啟動(dòng)會(huì)拒絕加載AOF。處理辦法是使用官方自帶的修復(fù)工具redis-check-aof --fix appendonly.aof它會(huì)掃描文件截?cái)喈惓Ｎ膊勘M可能保留可解析的數(shù)據(jù)。對(duì)RDB文件可以使用redis-check-rdb來校驗(yàn)完整性。但說實(shí)話工具修復(fù)只是最后一道防線更重要的習(xí)慣是定期做數(shù)據(jù)備份和恢復(fù)演練。我在團(tuán)隊(duì)里推行的做法是每天凌晨在從庫上執(zhí)行BGSAVE把生成的dump.rdb同步到對(duì)象存儲(chǔ)或異地服務(wù)器。每月做一次恢復(fù)演練從備份文件啟動(dòng)一個(gè)全新實(shí)例讓QA在實(shí)例上跑核心鏈路用例。演練結(jié)果記錄在案一旦發(fā)現(xiàn)問題及時(shí)調(diào)整備份策略。只有真正演練過你才知道備份文件能不能用、恢復(fù)流程需要多長(zhǎng)時(shí)間。別等到生產(chǎn)宕機(jī)了才第一次嘗試恢復(fù)數(shù)據(jù)。4. 應(yīng)用層常被忽視的隱性數(shù)據(jù)事故Big Key、熱Key與序列化異常如果說前面兩層是“數(shù)據(jù)庫安全”的常規(guī)議題那應(yīng)用層和Redis交互時(shí)的安全治理才是很多團(tuán)隊(duì)現(xiàn)有的真實(shí)短板。這類事故不涉及攻擊者純粹是代碼寫法或使用姿勢(shì)不對(duì)卻一樣會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)亂、服務(wù)雪崩。4.1 Big Key阻塞主線程Redis是單線程處理命令的所有讀寫在同一個(gè)線程里串行執(zhí)行。一個(gè)Big Key的讀取或刪除會(huì)讓整個(gè)實(shí)例卡住幾十毫秒甚至幾秒期間所有其他命令全部排隊(duì)等。怎么定義Big Key沒有絕對(duì)統(tǒng)一的標(biāo)準(zhǔn)我一般按照經(jīng)驗(yàn)值來判斷STRING類型value超過10KB就算偏大。LIST、SET、ZSET、HASH的元素?cái)?shù)量超過5000個(gè)或整體序列化后體積超過1MB就要警惕。發(fā)現(xiàn)Big Key的手段比較穩(wěn)妥的方式是用redis-cli --bigkeys來掃描但要選在業(yè)務(wù)低峰期。這個(gè)命令會(huì)遍歷所有key并統(tǒng)計(jì)最大的一些key原理是逐個(gè)執(zhí)行SCAN和類型專屬命令雖然不會(huì)阻塞主線程很久但仍有性能開銷生產(chǎn)高峰期慎用。Big Key的真正危害在于幾個(gè)動(dòng)作GET一個(gè)大字符串網(wǎng)絡(luò)傳輸耗時(shí)高客戶端超時(shí)概率增大。DEL一個(gè)包含幾百萬元素的LIST刪除操作會(huì)阻塞主線程。集群模式下大key還會(huì)導(dǎo)致內(nèi)存和數(shù)據(jù)訪問傾斜到單個(gè)分片其他分片閑著這一個(gè)分片被打滿。我在排查一次Redis慢查詢時(shí)定位到一個(gè)HASH里塞了兩百多萬個(gè)字段每次HGETALL耗時(shí)接近3秒把這個(gè)key一拆實(shí)例整體P99延遲立刻降了一半。4.2 熱Key放大單分片壓力熱Key是一個(gè)key在短時(shí)間內(nèi)被超高并發(fā)訪問。比如秒殺商品的庫存key、雙十一的活動(dòng)配置key單key QPS可能占到整個(gè)實(shí)例的一半以上。單線程模型下一個(gè)熱Key的讀取雖然不是特別耗時(shí)但每個(gè)請(qǐng)求都要經(jīng)過一次網(wǎng)絡(luò)和協(xié)議解析如果同一個(gè)key的并發(fā)太高對(duì)應(yīng)分片的CPU會(huì)先打滿進(jìn)而拖慢該分片上的所有其他key。常見解法是本地緩存Redis兜底、把熱key復(fù)制成多個(gè)帶后綴的副本分散讀壓力、或者直接上Redis Cluster讓key打散到不同分片。但注意集群模式解決不了單key熱點(diǎn)因?yàn)橥粋€(gè)key只會(huì)落到一個(gè)分片。4.3 序列化異常increment報(bào)錯(cuò)的經(jīng)典現(xiàn)場(chǎng)很多Java團(tuán)隊(duì)使用Spring Data Redis時(shí)都遇到過這個(gè)報(bào)錯(cuò)ERR value is not an integer or out of range這個(gè)報(bào)錯(cuò)的本意是對(duì)一個(gè)非整數(shù)類型的值執(zhí)行了INCR操作。但在實(shí)際場(chǎng)景里出現(xiàn)原因往往是序列化器配置不一致造成的“類型錯(cuò)亂”。舉個(gè)例子你用RedisTemplate默認(rèn)的JDK序列化器寫入了一個(gè)Integer對(duì)象底層會(huì)把Java對(duì)象的二進(jìn)制流加上類型頭存進(jìn)去。此時(shí)如果再用StringRedisTemplate去執(zhí)行incrementRedis看到的value是一串不可解析的二進(jìn)制內(nèi)容自然無法把它當(dāng)作整數(shù)自增。反過來的場(chǎng)景也很常見先用StringRedisTemplate.set(key, 1)存了字符串再用RedisTemplate.opsForValue().increment(key)自增同樣會(huì)因?yàn)檫@個(gè)key的value格式與當(dāng)前序列化器不匹配而報(bào)錯(cuò)。解決方案并不復(fù)雜關(guān)鍵是統(tǒng)一序列化器如果存儲(chǔ)的都是字符串就統(tǒng)一用StringRedisTemplate。如果必須用RedisTemplate則顯式設(shè)置StringRedisSerializer作為key和value的序列化器避免默認(rèn)的JDK序列化。如果存的是對(duì)象建議使用JSON序列化器比如GenericJackson2JsonRedisSerializer。我在團(tuán)隊(duì)里定了一條規(guī)矩項(xiàng)目里只允許出現(xiàn)兩種Redis訪問方式純字符串操作一律走StringRedisTemplate對(duì)象緩存一律走配置了JSON序列化器的RedisTemplate禁止在同一個(gè)key上混用兩種Template。4.4 緩存穿透、擊穿與雪崩緩存層的三個(gè)經(jīng)典問題——穿透、擊穿、雪崩本質(zhì)上也屬于數(shù)據(jù)安全范疇。它們帶來的不是“數(shù)據(jù)被刪”而是“數(shù)據(jù)源被流量打垮”進(jìn)而導(dǎo)致整個(gè)業(yè)務(wù)鏈路不可用。穿透查詢一個(gè)不存在的key緩存里沒有每次都打到數(shù)據(jù)庫。擊穿某一個(gè)熱點(diǎn)key過期瞬間大量請(qǐng)求同時(shí)打到數(shù)據(jù)庫。雪崩大量key在同一時(shí)間過期數(shù)據(jù)庫壓力瞬間飆升。這三類問題的治理方案都比較成熟了穿透用布隆過濾器或緩存空值擊穿用互斥鎖重建緩存雪崩給過期時(shí)間加隨機(jī)擾動(dòng)或者用多級(jí)緩存。我在實(shí)際項(xiàng)目里發(fā)現(xiàn)很多團(tuán)隊(duì)配置了緩存過期時(shí)間但從不關(guān)注過期key的分布。一個(gè)比較有效的習(xí)慣是給同類緩存key的TTL設(shè)置一個(gè)基礎(chǔ)值加隨機(jī)偏移讓過期時(shí)間在時(shí)間軸上均勻散開。5. 分布式鎖的誤用與多實(shí)例一致性問題Redis被廣泛用來實(shí)現(xiàn)分布式鎖這本身沒有問題但分布式鎖的安全邊界比單機(jī)鎖要復(fù)雜得多。我排查過的很多生產(chǎn)故障比如秒殺超賣、重復(fù)下單、定時(shí)任務(wù)重復(fù)執(zhí)行最后都指向了同一個(gè)根源分布式鎖寫錯(cuò)了。5.1 加鎖必須一條命令完成最經(jīng)典的錯(cuò)誤寫法是先SETNX再單獨(dú)EXPIRE。這兩條命令之間如果應(yīng)用進(jìn)程崩潰或者Redis連接斷開鎖就會(huì)變成永不過期的死鎖。正確寫法是用一條原子命令完成加鎖和過期時(shí)間設(shè)置SET lock:order:1001 unique-token NX EX 30對(duì)應(yīng)的Java代碼如下String lockKey lock:order: orderId; String requestId UUID.randomUUID().toString(); Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(30)); if (Boolean.TRUE.equals(locked)) { try { // 業(yè)務(wù)邏輯 } finally { // 釋放鎖時(shí)必須校驗(yàn)value是否還是自己的 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; stringRedisTemplate.execute(new DefaultRedisScript(script, Long.class), Arrays.asList(lockKey), requestId); } }注意釋放鎖不能用簡(jiǎn)單的DEL因?yàn)榭赡艹霈F(xiàn)這種情況線程A持有鎖業(yè)務(wù)執(zhí)行超過30秒鎖自動(dòng)過期線程B拿到鎖此時(shí)線程A執(zhí)行完業(yè)務(wù)如果A直接DEL會(huì)把B的鎖誤刪掉。所以釋放鎖要用Lua腳本先比較value確認(rèn)是自己的再刪除。5.2 鎖超時(shí)續(xù)期與看門狗上面的寫法默認(rèn)要求業(yè)務(wù)在鎖過期之前執(zhí)行完。如果業(yè)務(wù)執(zhí)行時(shí)間不可控就需要給鎖續(xù)期。Redisson內(nèi)置的看門狗機(jī)制會(huì)自動(dòng)續(xù)期默認(rèn)每10秒檢查一次如果鎖還存在就自動(dòng)續(xù)期到30秒直到業(yè)務(wù)釋放鎖或者進(jìn)程退出。自己實(shí)現(xiàn)續(xù)期時(shí)要注意續(xù)期本身也必須是一個(gè)原子操作比較穩(wěn)妥的方式是用Lua腳本在續(xù)期前檢查value是否仍是自己的。if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(expire, KEYS[1], ARGV[2]) else return 0 end5.3 主從切換與鎖丟失的邊界Redis單實(shí)例分布式鎖有個(gè)先天問題如果主庫加鎖成功但還沒同步到從庫主庫宕機(jī)觸發(fā)哨兵切換新主庫上根本沒有這把鎖另一個(gè)線程就能成功加上同一把鎖。這時(shí)互斥被破壞兩個(gè)線程同時(shí)進(jìn)入臨界區(qū)。對(duì)這個(gè)問題的處理業(yè)界存在爭(zhēng)議。Redlock算法試圖用多個(gè)獨(dú)立Redis節(jié)點(diǎn)來降低鎖丟失概率但它在復(fù)雜網(wǎng)絡(luò)環(huán)境下也有自身的理論爭(zhēng)議。我的個(gè)人經(jīng)驗(yàn)是如果業(yè)務(wù)場(chǎng)景對(duì)互斥不是絕對(duì)嚴(yán)苛比如下單防重少一單多一單都能通過對(duì)賬發(fā)現(xiàn)那單Redis實(shí)例鎖加上續(xù)期機(jī)制就夠用了如果場(chǎng)景真的需要強(qiáng)互斥與其寄希望于Redlock不如直接引入ZooKeeper或etcd這類帶共識(shí)算法的協(xié)調(diào)服務(wù)。從成本、運(yùn)維復(fù)雜度、可靠性三個(gè)方面綜合來看強(qiáng)一致分布式鎖最可靠的家還是ZooKeeper/etcd。5.4 分布式鎖之外的冪等防線分布式鎖不是萬能的。鎖能擋住同一時(shí)刻的并發(fā)但擋不住網(wǎng)絡(luò)超時(shí)后的重復(fù)提交、消息隊(duì)列的重試投遞這類場(chǎng)景。更穩(wěn)妥的做法是在數(shù)據(jù)層做冪等控制業(yè)務(wù)表加唯一索引處理前先查重、再插入數(shù)據(jù)庫唯一索引兜底。鎖和冪等一起上才能最大程度避免重復(fù)寫數(shù)據(jù)。6. 一套可以直接落地的Redis安全檢查清單與常用排查命令前面說了這么多理論最后我整理一份可以直接拿去用的安全檢查清單。這份清單是我在團(tuán)隊(duì)里做Redis巡檢時(shí)每天都在用的覆蓋了配置層、網(wǎng)絡(luò)層、數(shù)據(jù)層和應(yīng)用層。6.1 配置層自檢表檢查項(xiàng)推薦配置檢查命令監(jiān)聽地址bind 127.0.0.1 或內(nèi)網(wǎng)IPCONFIG GET bind保護(hù)模式protected-mode yesCONFIG GET protected-mode認(rèn)證requirepass強(qiáng)密碼或ACL授權(quán)CONFIG GET requirepass危險(xiǎn)命令rename-command禁用或改名查看redis.confRDB快照按業(yè)務(wù)容忍度配置save策略CONFIG GET saveAOFappendonly yeseverysecCONFIG GET appendonly appendfsync從庫保護(hù)min-replicas-to-write和max-lag合理設(shè)置CONFIG GET min-replicas-*版本至少6.x推薦7.xredis-server --version6.2 常用排查命令# 查看當(dāng)前連接客戶端 redis-cli CLIENT LIST # 查看慢查詢?nèi)罩?redis-cli SLOWLOG GET 50 redis-cli SLOWLOG RESET # 查看運(yùn)行信息 redis-cli INFO keyspace redis-cli INFO replication redis-cli INFO persistence # 查看ACL日志Redis 6 redis-cli ACL LOG # 掃描Big Key低峰期執(zhí)行 redis-cli --bigkeys # 查看某個(gè)key的內(nèi)存占用 redis-cli --bigkeys 或 MEMORY USAGE key名MONITOR命令也很常用它可以實(shí)時(shí)打印Redis執(zhí)行的所有命令但生產(chǎn)環(huán)境務(wù)必慎用。MONITOR開著的時(shí)候Redis會(huì)為每個(gè)命令額外做一次輸出對(duì)性能影響不小我見過有人開著MONITOR做在線調(diào)試結(jié)果Redis響應(yīng)時(shí)間直接翻倍。調(diào)試完記得第一時(shí)間關(guān)掉。Redis 6之后新增的ACL LOG很實(shí)用。它能記錄因權(quán)限不足被拒絕的命令排查時(shí)不用再傻乎乎地翻所有日志。比如懷疑某個(gè)客戶端在嘗試執(zhí)行CONFIG操作一條ACL LOG就能看到被攔截的記錄。6.3 安全基線之外的三點(diǎn)補(bǔ)充第一日志的審計(jì)往往被忽視。建議開啟Redis的慢查詢?nèi)罩竞虯CL日志的持久化為日后的安全事件回溯留下證據(jù)。雖然不能完全防止問題發(fā)生但出了事能快速定位到人和時(shí)間。第二保持版本更新。Redis 7.0之后AOF文件采用了多部分格式重寫和加載效率提升明顯也修復(fù)了不少歷史安全漏洞。如果一個(gè)實(shí)例已經(jīng)運(yùn)行了兩年以上沒動(dòng)過版本我建議列入升級(jí)計(jì)劃升級(jí)前先做全量備份和恢復(fù)演練。第三Redis未授權(quán)訪問類的攻擊在最近的安全通報(bào)里反復(fù)出現(xiàn)我個(gè)人的觀點(diǎn)是不要高估自己團(tuán)隊(duì)的安全水位每隔一個(gè)季度就按這份清單重新巡檢一遍。配置被改回去、安全組被重新放行、新同事不知道規(guī)則誤開端口這些情況我都遇到過。安全不是一次性的項(xiàng)目而是持續(xù)性的習(xí)慣。從我多年的實(shí)戰(zhàn)經(jīng)驗(yàn)來看Redis數(shù)據(jù)安全的本質(zhì)是“訪問可控、數(shù)據(jù)可恢復(fù)、運(yùn)行可預(yù)期、并發(fā)不踩踏”。訪問控制做在前面持久化兜住底應(yīng)用層寫代碼時(shí)多想一層分布式場(chǎng)景對(duì)一致性邊界有清醒認(rèn)知這四個(gè)維度都到位了Redis基本就不會(huì)成為拖垮業(yè)務(wù)的短板。 Redis數(shù)據(jù)安全加固實(shí)戰(zhàn)：訪問控制、持久化與分布式鎖
凌晨?jī)牲c(diǎn)半監(jiān)控面板上Redis主節(jié)點(diǎn)的CPU使用率突然拉滿慢查詢數(shù)量肉眼可見地往上跳。登錄服務(wù)器一看公網(wǎng)安全組里竟然掛著6379的放行規(guī)則一臺(tái)沒有任何認(rèn)證配置的Redis正被全網(wǎng)掃描工具輪番爆破。雖然最后沒造成數(shù)據(jù)清空但那一整晚排查的過程讓我意識(shí)到一個(gè)扎心的事實(shí)絕大多數(shù)團(tuán)隊(duì)對(duì)Redis數(shù)據(jù)安全的理解還停留在“不崩就行”的層面。Redis數(shù)據(jù)安全性這句話落到工程實(shí)踐里至少可以拆成四件事防非法訪問、防數(shù)據(jù)丟失、防運(yùn)行阻塞、防臟讀錯(cuò)寫。這四件事分別對(duì)應(yīng)網(wǎng)絡(luò)層防護(hù)、持久化策略、應(yīng)用層治理和分布式一致性。這篇文章我就按這幾個(gè)維度把我在生產(chǎn)環(huán)境里踩過的坑、排查過的事故、以及最終沉淀下來的一套可落地的加固方案完整梳理一遍。無論你把Redis當(dāng)緩存用、當(dāng)計(jì)數(shù)器用還是當(dāng)分布式鎖的底層存儲(chǔ)這篇文章都值得你花十分鐘過一遍。1. 先搞清楚Redis數(shù)據(jù)安全威脅模型的四個(gè)維度很多人一提數(shù)據(jù)安全第一反應(yīng)就是“加個(gè)密碼”。實(shí)際上Redis這類內(nèi)存型數(shù)據(jù)庫的安全問題遠(yuǎn)比一條requirepass配置復(fù)雜得多。我在評(píng)估一個(gè)Redis實(shí)例的安全性時(shí)通常按下面這張表來做威脅建模。威脅類型實(shí)際路徑后果示例未授權(quán)訪問端口暴露公網(wǎng)、空密碼、protected-mode關(guān)閉數(shù)據(jù)被遍歷、被篡改、被植入定時(shí)任務(wù)弱口令爆破Redis認(rèn)證協(xié)議簡(jiǎn)單高頻嘗試AUTH實(shí)例被接管數(shù)據(jù)被FLUSHALL清空危險(xiǎn)命令濫用KEYS、FLUSHALL、DEBUG等命令可執(zhí)行阻塞主線程、數(shù)據(jù)批量刪除、實(shí)例掛死進(jìn)程崩潰與宕機(jī)RDB/AOF配置不當(dāng)、服務(wù)器斷電丟失數(shù)分鐘甚至全部數(shù)據(jù)主從復(fù)制錯(cuò)亂failover后舊主重新加入、復(fù)制積壓區(qū)溢出新主數(shù)據(jù)被舊主覆蓋數(shù)據(jù)回退應(yīng)用層邏輯隱患Big Key、熱Key、序列化類型錯(cuò)亂慢查詢拖垮實(shí)例、incr命令報(bào)錯(cuò)、緩存雪崩分布式一致性問題鎖超時(shí)失效、主從切換鎖丟失并發(fā)重復(fù)執(zhí)行、超賣、重復(fù)下單這張表里的每一項(xiàng)我都見過真實(shí)的生產(chǎn)事故。比較諷刺的是最容易被團(tuán)隊(duì)忽視的恰恰是后半部分——很多人都認(rèn)真配過bind和requirepass但很少有人認(rèn)真回答“Redis所在服務(wù)器突然斷電你會(huì)丟多少數(shù)據(jù)”“主從切換的瞬間分布式鎖還能不能保證互斥”這兩個(gè)問題。Redis的安全范圍為什么和傳統(tǒng)數(shù)據(jù)庫不一樣關(guān)鍵在于它的定位。傳統(tǒng)MySQL是唯一數(shù)據(jù)源天然會(huì)有人認(rèn)真對(duì)待備份和權(quán)限Redis在很多團(tuán)隊(duì)眼里就是“加速層”丟了可以回源數(shù)據(jù)庫重建?？梢坏㏑edis里存了庫存、訂單號(hào)、驗(yàn)證碼、分布式鎖、接口冪等標(biāo)記這類有業(yè)務(wù)語義的數(shù)據(jù)它就的的確確是業(yè)務(wù)系統(tǒng)的一部分了。此時(shí)再拿“緩存隨便丟”的心態(tài)去運(yùn)維遲早會(huì)出事。所以這篇文章后續(xù)所有內(nèi)容都圍繞著上面表格里的四類風(fēng)險(xiǎn)展開訪問控制怎么收緊持久化怎么保證不丟應(yīng)用怎么寫才不把Redis搞掛分布式場(chǎng)景怎么避免錯(cuò)寫和重復(fù)執(zhí)行。2. 最容易出事的三個(gè)環(huán)節(jié)未授權(quán)訪問、弱口令、危險(xiǎn)命令這三個(gè)問題通常一起出現(xiàn)。早期Redis版本默認(rèn)配置只監(jiān)聽127.0.0.1這個(gè)默認(rèn)值其實(shí)是相對(duì)安全的真正出事的基本都是人為改配置改出來的bind 0.0.0.0、protected-mode no、不設(shè)密碼三件套齊活之后只要安全組或防火墻不小心放行了6379你的Redis就等于裸奔在公網(wǎng)。2.1 未授權(quán)訪問為什么這么普遍我接手過的一個(gè)項(xiàng)目?jī)?nèi)網(wǎng)Redis居然能被開發(fā)機(jī)直接無密碼連接登錄進(jìn)去發(fā)現(xiàn)里面存了大量用戶Session和驗(yàn)證碼。查下來原因很典型當(dāng)初搭建時(shí)圖省事復(fù)制了一份網(wǎng)上流傳的“通用配置”里面直接寫死了bind 0.0.0.0和protected-mode no然后一直沒人改。更隱蔽的情況是bind配置本身沒錯(cuò)但被部署在Docker容器里端口通過-p 6379:6379直接映射到了宿主機(jī)公網(wǎng)地址。容器內(nèi)部的bind 127.0.0.1只約束了容器網(wǎng)絡(luò)棧宿主機(jī)端口轉(zhuǎn)發(fā)根本不受這個(gè)限制。這種“容器隔離錯(cuò)覺”讓很多團(tuán)隊(duì)的Redis明明看著配置沒問題實(shí)際上公網(wǎng)一抓一個(gè)準(zhǔn)。檢查方法很簡(jiǎn)單在Redis服務(wù)器本地執(zhí)行redis-cli -h 127.0.0.1 -p 6379 ping如果能直接返回PONG而沒提示NOAUTH同時(shí)客戶端連接來源又不限于127.0.0.1那基本可以判定當(dāng)前實(shí)例處于未授權(quán)訪問狀態(tài)。2.2 弱口令和爆破Redis認(rèn)證機(jī)制的局限性Redis的認(rèn)證早期只有一層密碼也就是requirepass。它的問題在于密碼沒有強(qiáng)度校驗(yàn)機(jī)制而且Redis協(xié)議簡(jiǎn)單攻擊者可以用極低的成本暴力嘗試。某些掃描工具甚至專門維護(hù)了一份“Redis常見弱密碼表”從redis、123456到passw0rd挨個(gè)試。還有一種思路是直接限制來源。生產(chǎn)環(huán)境的Redis只應(yīng)該被特定應(yīng)用服務(wù)器訪問安全組/防火墻層面做來源IP白名單往往比一個(gè)強(qiáng)密碼更有效。密碼再強(qiáng)也怕客戶端連接串泄露來源IP限制住即使連接串泄露攻擊者也無法從外部觸達(dá)。2.3 危險(xiǎn)命令比刪庫更常見的是“手滑”和“爆破后的最后一擊”在Redis里KEYS *、FLUSHALL、FLUSHDB、CONFIG SET、DEBUG這類命令的破壞力很多人沒有概念。KEYS *在key數(shù)量達(dá)到百萬級(jí)別時(shí)會(huì)阻塞主線程數(shù)秒甚至更久。FLUSHALL一條命令清空所有數(shù)據(jù)卻不會(huì)像MySQL那樣彈出任何確認(rèn)。CONFIG SET甚至可以在運(yùn)行期動(dòng)態(tài)修改配置直接把保護(hù)機(jī)制關(guān)掉。我見過不止一次線上事故是因?yàn)橥略跍y(cè)試環(huán)境連錯(cuò)了Redis地址一個(gè)FLUSHALL把預(yù)發(fā)環(huán)境的緩存全部清掉接著流量全部打到數(shù)據(jù)庫把庫打出了慢查詢告警。防御上比較通用的是兩步第一在配置文件中用rename-command把危險(xiǎn)命令改名或禁用第二Redis 6.0之后的ACL功能能做到按用戶授權(quán)比如給業(yè)務(wù)應(yīng)用只開讀寫權(quán)限不開CONFIG、FLUSHALL等管理命令。2.4 網(wǎng)絡(luò)層安全別把安全寄托在Redis自身我在實(shí)際加固時(shí)會(huì)遵循一個(gè)原則Redis自身的安全配置是縱深防御的一層但絕不能是唯一一層。哪怕Redis配置得再嚴(yán)操作系統(tǒng)層面的防火墻、云平臺(tái)的安全組也要配合收斂端口暴露面。落地的檢查步驟大概是先看監(jiān)聽地址ss -lntp | grep 6379確認(rèn)只監(jiān)聽了內(nèi)網(wǎng)或回環(huán)地址。確認(rèn)云安全組和主機(jī)防火墻的入方向規(guī)則沒有放行0.0.0.0/0到6379。在配置文件中開啟protected-mode yes。設(shè)置強(qiáng)密碼或啟用ACL禁止空密碼啟動(dòng)。用rename-command禁用KEYS、FLUSHALL、CONFIG、DEBUG等管理類命令。定期用掃描工具做一次端口自檢模擬公網(wǎng)視角看6379是否可達(dá)。這套流程做完未授權(quán)訪問這個(gè)維度的風(fēng)險(xiǎn)基本就能堵住。3. 數(shù)據(jù)不丟比想象中難RDB、AOF與主從架構(gòu)的數(shù)據(jù)可靠性邊界很多團(tuán)隊(duì)對(duì)Redis持久化的理解就是“開了AOF應(yīng)該不會(huì)丟數(shù)據(jù)了吧”。實(shí)際排查過事故之后你會(huì)發(fā)現(xiàn)這句話離真相還差得很遠(yuǎn)。3.1 RDB快照的丟失窗口RDB是Redis默認(rèn)的持久化方式通過save或BGSAVE生成某個(gè)時(shí)間點(diǎn)的全量快照。它的最大特點(diǎn)是恢復(fù)快、文件緊湊但缺點(diǎn)也明顯在兩次快照之間的數(shù)據(jù)一旦進(jìn)程異常退出就全部丟失。默認(rèn)配置是save 900 1、save 300 10、save 60 10000意思是“900秒內(nèi)有1次寫入”“300秒內(nèi)有10次寫入”“60秒內(nèi)有1萬次寫入”三個(gè)條件任一滿足就觸發(fā)快照。注意這個(gè)條件組合意味著低流量時(shí)段理論上可能15分鐘才打一次快照這期間的數(shù)據(jù)丟失窗口就是15分鐘。3.2 AOF三種刷盤策略的取舍評(píng)估AOF通過追加日志的方式記錄每次寫操作重啟時(shí)重放日志來恢復(fù)數(shù)據(jù)。它的關(guān)鍵參數(shù)是appendfsync有三個(gè)取值appendfsync配置刷盤時(shí)機(jī)丟失窗口性能影響always每條寫命令都調(diào)用fsync最多一條命令最高吞吐量明顯下降everysec每秒調(diào)用一次fsync最多1秒數(shù)據(jù)中等生產(chǎn)環(huán)境常用no交給操作系統(tǒng)決定不確定可能較多最好但安全性最低生產(chǎn)環(huán)境我通常選everysec在性能和安全性之間找一個(gè)平衡點(diǎn)。Redis官方文檔的表述也是這樣一個(gè)默認(rèn)取向。但這里要特別提醒一件事AOF的“最多丟1秒”是建立在操作系統(tǒng)正常運(yùn)行的前提下的。服務(wù)器物理宕機(jī)、內(nèi)核panic、云主機(jī)被強(qiáng)制重啟這類場(chǎng)景數(shù)據(jù)丟失可能比預(yù)期更多。因?yàn)閑verysec策略下Redis子進(jìn)程獨(dú)立執(zhí)行fsync如果操作系統(tǒng)還沒來得及把緩沖落盤就斷電緩沖里積壓的那一小段時(shí)間數(shù)據(jù)就沒了。3.3 從庫強(qiáng)一致保護(hù)min-replicas機(jī)制主從架構(gòu)下很多人以為“有從庫就等于數(shù)據(jù)安全”。但從庫同步是有延遲的主庫會(huì)無腦接受寫入并返回成功從庫還沒跟上。如果此時(shí)主庫宕機(jī)觸發(fā)哨兵切換新主庫可能缺失了最后幾秒的寫入數(shù)據(jù)。更要命的是如果舊主庫恢復(fù)后重新加回集群它發(fā)現(xiàn)自己落后了新主會(huì)主動(dòng)清空本地?cái)?shù)據(jù)去追隨新主此時(shí)如果它的數(shù)據(jù)比新主還新反而會(huì)把新主覆蓋不會(huì)Redis的復(fù)制邏輯里舊主會(huì)被清空并復(fù)制新主數(shù)據(jù)這會(huì)造成一個(gè)“回退”——原本已寫入的數(shù)據(jù)被抹掉。針對(duì)這種場(chǎng)景Redis提供了min-replicas-to-write和min-replicas-max-lag兩個(gè)參數(shù)含義是當(dāng)健康的從庫數(shù)量低于閾值或從庫的復(fù)制延遲超過了max-lag秒主庫就拒絕寫入。這樣可以在極端情況下放棄可用性保數(shù)據(jù)一致性。min-replicas-to-write 1 min-replicas-max-lag 10這個(gè)配置的含義是至少要有1個(gè)從庫的延遲在10秒以內(nèi)主庫才接受寫入。如果所有從庫都掉隊(duì)了主庫會(huì)直接返回錯(cuò)誤而不是繼續(xù)無腦寫。代價(jià)是短暫的服務(wù)不可用但換來的是一次災(zāi)難恢復(fù)后數(shù)據(jù)不會(huì)無故回退。3.4 文件損壞與備份恢復(fù)演練Redis的數(shù)據(jù)文件在極端情況下也會(huì)損壞最常見的場(chǎng)景是AOF文件末尾寫了半條命令就斷電此時(shí)Redis啟動(dòng)會(huì)拒絕加載AOF。處理辦法是使用官方自帶的修復(fù)工具redis-check-aof --fix appendonly.aof它會(huì)掃描文件截?cái)喈惓Ｎ膊勘M可能保留可解析的數(shù)據(jù)。對(duì)RDB文件可以使用redis-check-rdb來校驗(yàn)完整性。但說實(shí)話工具修復(fù)只是最后一道防線更重要的習(xí)慣是定期做數(shù)據(jù)備份和恢復(fù)演練。我在團(tuán)隊(duì)里推行的做法是每天凌晨在從庫上執(zhí)行BGSAVE把生成的dump.rdb同步到對(duì)象存儲(chǔ)或異地服務(wù)器。每月做一次恢復(fù)演練從備份文件啟動(dòng)一個(gè)全新實(shí)例讓QA在實(shí)例上跑核心鏈路用例。演練結(jié)果記錄在案一旦發(fā)現(xiàn)問題及時(shí)調(diào)整備份策略。只有真正演練過你才知道備份文件能不能用、恢復(fù)流程需要多長(zhǎng)時(shí)間。別等到生產(chǎn)宕機(jī)了才第一次嘗試恢復(fù)數(shù)據(jù)。4. 應(yīng)用層常被忽視的隱性數(shù)據(jù)事故Big Key、熱Key與序列化異常如果說前面兩層是“數(shù)據(jù)庫安全”的常規(guī)議題那應(yīng)用層和Redis交互時(shí)的安全治理才是很多團(tuán)隊(duì)現(xiàn)有的真實(shí)短板。這類事故不涉及攻擊者純粹是代碼寫法或使用姿勢(shì)不對(duì)卻一樣會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)亂、服務(wù)雪崩。4.1 Big Key阻塞主線程Redis是單線程處理命令的所有讀寫在同一個(gè)線程里串行執(zhí)行。一個(gè)Big Key的讀取或刪除會(huì)讓整個(gè)實(shí)例卡住幾十毫秒甚至幾秒期間所有其他命令全部排隊(duì)等。怎么定義Big Key沒有絕對(duì)統(tǒng)一的標(biāo)準(zhǔn)我一般按照經(jīng)驗(yàn)值來判斷STRING類型value超過10KB就算偏大。LIST、SET、ZSET、HASH的元素?cái)?shù)量超過5000個(gè)或整體序列化后體積超過1MB就要警惕。發(fā)現(xiàn)Big Key的手段比較穩(wěn)妥的方式是用redis-cli --bigkeys來掃描但要選在業(yè)務(wù)低峰期。這個(gè)命令會(huì)遍歷所有key并統(tǒng)計(jì)最大的一些key原理是逐個(gè)執(zhí)行SCAN和類型專屬命令雖然不會(huì)阻塞主線程很久但仍有性能開銷生產(chǎn)高峰期慎用。Big Key的真正危害在于幾個(gè)動(dòng)作GET一個(gè)大字符串網(wǎng)絡(luò)傳輸耗時(shí)高客戶端超時(shí)概率增大。DEL一個(gè)包含幾百萬元素的LIST刪除操作會(huì)阻塞主線程。集群模式下大key還會(huì)導(dǎo)致內(nèi)存和數(shù)據(jù)訪問傾斜到單個(gè)分片其他分片閑著這一個(gè)分片被打滿。我在排查一次Redis慢查詢時(shí)定位到一個(gè)HASH里塞了兩百多萬個(gè)字段每次HGETALL耗時(shí)接近3秒把這個(gè)key一拆實(shí)例整體P99延遲立刻降了一半。4.2 熱Key放大單分片壓力熱Key是一個(gè)key在短時(shí)間內(nèi)被超高并發(fā)訪問。比如秒殺商品的庫存key、雙十一的活動(dòng)配置key單key QPS可能占到整個(gè)實(shí)例的一半以上。單線程模型下一個(gè)熱Key的讀取雖然不是特別耗時(shí)但每個(gè)請(qǐng)求都要經(jīng)過一次網(wǎng)絡(luò)和協(xié)議解析如果同一個(gè)key的并發(fā)太高對(duì)應(yīng)分片的CPU會(huì)先打滿進(jìn)而拖慢該分片上的所有其他key。常見解法是本地緩存Redis兜底、把熱key復(fù)制成多個(gè)帶后綴的副本分散讀壓力、或者直接上Redis Cluster讓key打散到不同分片。但注意集群模式解決不了單key熱點(diǎn)因?yàn)橥粋€(gè)key只會(huì)落到一個(gè)分片。4.3 序列化異常increment報(bào)錯(cuò)的經(jīng)典現(xiàn)場(chǎng)很多Java團(tuán)隊(duì)使用Spring Data Redis時(shí)都遇到過這個(gè)報(bào)錯(cuò)ERR value is not an integer or out of range這個(gè)報(bào)錯(cuò)的本意是對(duì)一個(gè)非整數(shù)類型的值執(zhí)行了INCR操作。但在實(shí)際場(chǎng)景里出現(xiàn)原因往往是序列化器配置不一致造成的“類型錯(cuò)亂”。舉個(gè)例子你用RedisTemplate默認(rèn)的JDK序列化器寫入了一個(gè)Integer對(duì)象底層會(huì)把Java對(duì)象的二進(jìn)制流加上類型頭存進(jìn)去。此時(shí)如果再用StringRedisTemplate去執(zhí)行incrementRedis看到的value是一串不可解析的二進(jìn)制內(nèi)容自然無法把它當(dāng)作整數(shù)自增。反過來的場(chǎng)景也很常見先用StringRedisTemplate.set(key, 1)存了字符串再用RedisTemplate.opsForValue().increment(key)自增同樣會(huì)因?yàn)檫@個(gè)key的value格式與當(dāng)前序列化器不匹配而報(bào)錯(cuò)。解決方案并不復(fù)雜關(guān)鍵是統(tǒng)一序列化器如果存儲(chǔ)的都是字符串就統(tǒng)一用StringRedisTemplate。如果必須用RedisTemplate則顯式設(shè)置StringRedisSerializer作為key和value的序列化器避免默認(rèn)的JDK序列化。如果存的是對(duì)象建議使用JSON序列化器比如GenericJackson2JsonRedisSerializer。我在團(tuán)隊(duì)里定了一條規(guī)矩項(xiàng)目里只允許出現(xiàn)兩種Redis訪問方式純字符串操作一律走StringRedisTemplate對(duì)象緩存一律走配置了JSON序列化器的RedisTemplate禁止在同一個(gè)key上混用兩種Template。4.4 緩存穿透、擊穿與雪崩緩存層的三個(gè)經(jīng)典問題——穿透、擊穿、雪崩本質(zhì)上也屬于數(shù)據(jù)安全范疇。它們帶來的不是“數(shù)據(jù)被刪”而是“數(shù)據(jù)源被流量打垮”進(jìn)而導(dǎo)致整個(gè)業(yè)務(wù)鏈路不可用。穿透查詢一個(gè)不存在的key緩存里沒有每次都打到數(shù)據(jù)庫。擊穿某一個(gè)熱點(diǎn)key過期瞬間大量請(qǐng)求同時(shí)打到數(shù)據(jù)庫。雪崩大量key在同一時(shí)間過期數(shù)據(jù)庫壓力瞬間飆升。這三類問題的治理方案都比較成熟了穿透用布隆過濾器或緩存空值擊穿用互斥鎖重建緩存雪崩給過期時(shí)間加隨機(jī)擾動(dòng)或者用多級(jí)緩存。我在實(shí)際項(xiàng)目里發(fā)現(xiàn)很多團(tuán)隊(duì)配置了緩存過期時(shí)間但從不關(guān)注過期key的分布。一個(gè)比較有效的習(xí)慣是給同類緩存key的TTL設(shè)置一個(gè)基礎(chǔ)值加隨機(jī)偏移讓過期時(shí)間在時(shí)間軸上均勻散開。5. 分布式鎖的誤用與多實(shí)例一致性問題Redis被廣泛用來實(shí)現(xiàn)分布式鎖這本身沒有問題但分布式鎖的安全邊界比單機(jī)鎖要復(fù)雜得多。我排查過的很多生產(chǎn)故障比如秒殺超賣、重復(fù)下單、定時(shí)任務(wù)重復(fù)執(zhí)行最后都指向了同一個(gè)根源分布式鎖寫錯(cuò)了。5.1 加鎖必須一條命令完成最經(jīng)典的錯(cuò)誤寫法是先SETNX再單獨(dú)EXPIRE。這兩條命令之間如果應(yīng)用進(jìn)程崩潰或者Redis連接斷開鎖就會(huì)變成永不過期的死鎖。正確寫法是用一條原子命令完成加鎖和過期時(shí)間設(shè)置SET lock:order:1001 unique-token NX EX 30對(duì)應(yīng)的Java代碼如下String lockKey lock:order: orderId; String requestId UUID.randomUUID().toString(); Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, Duration.ofSeconds(30)); if (Boolean.TRUE.equals(locked)) { try { // 業(yè)務(wù)邏輯 } finally { // 釋放鎖時(shí)必須校驗(yàn)value是否還是自己的 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; stringRedisTemplate.execute(new DefaultRedisScript(script, Long.class), Arrays.asList(lockKey), requestId); } }注意釋放鎖不能用簡(jiǎn)單的DEL因?yàn)榭赡艹霈F(xiàn)這種情況線程A持有鎖業(yè)務(wù)執(zhí)行超過30秒鎖自動(dòng)過期線程B拿到鎖此時(shí)線程A執(zhí)行完業(yè)務(wù)如果A直接DEL會(huì)把B的鎖誤刪掉。所以釋放鎖要用Lua腳本先比較value確認(rèn)是自己的再刪除。5.2 鎖超時(shí)續(xù)期與看門狗上面的寫法默認(rèn)要求業(yè)務(wù)在鎖過期之前執(zhí)行完。如果業(yè)務(wù)執(zhí)行時(shí)間不可控就需要給鎖續(xù)期。Redisson內(nèi)置的看門狗機(jī)制會(huì)自動(dòng)續(xù)期默認(rèn)每10秒檢查一次如果鎖還存在就自動(dòng)續(xù)期到30秒直到業(yè)務(wù)釋放鎖或者進(jìn)程退出。自己實(shí)現(xiàn)續(xù)期時(shí)要注意續(xù)期本身也必須是一個(gè)原子操作比較穩(wěn)妥的方式是用Lua腳本在續(xù)期前檢查value是否仍是自己的。if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(expire, KEYS[1], ARGV[2]) else return 0 end5.3 主從切換與鎖丟失的邊界Redis單實(shí)例分布式鎖有個(gè)先天問題如果主庫加鎖成功但還沒同步到從庫主庫宕機(jī)觸發(fā)哨兵切換新主庫上根本沒有這把鎖另一個(gè)線程就能成功加上同一把鎖。這時(shí)互斥被破壞兩個(gè)線程同時(shí)進(jìn)入臨界區(qū)。對(duì)這個(gè)問題的處理業(yè)界存在爭(zhēng)議。Redlock算法試圖用多個(gè)獨(dú)立Redis節(jié)點(diǎn)來降低鎖丟失概率但它在復(fù)雜網(wǎng)絡(luò)環(huán)境下也有自身的理論爭(zhēng)議。我的個(gè)人經(jīng)驗(yàn)是如果業(yè)務(wù)場(chǎng)景對(duì)互斥不是絕對(duì)嚴(yán)苛比如下單防重少一單多一單都能通過對(duì)賬發(fā)現(xiàn)那單Redis實(shí)例鎖加上續(xù)期機(jī)制就夠用了如果場(chǎng)景真的需要強(qiáng)互斥與其寄希望于Redlock不如直接引入ZooKeeper或etcd這類帶共識(shí)算法的協(xié)調(diào)服務(wù)。從成本、運(yùn)維復(fù)雜度、可靠性三個(gè)方面綜合來看強(qiáng)一致分布式鎖最可靠的家還是ZooKeeper/etcd。5.4 分布式鎖之外的冪等防線分布式鎖不是萬能的。鎖能擋住同一時(shí)刻的并發(fā)但擋不住網(wǎng)絡(luò)超時(shí)后的重復(fù)提交、消息隊(duì)列的重試投遞這類場(chǎng)景。更穩(wěn)妥的做法是在數(shù)據(jù)層做冪等控制業(yè)務(wù)表加唯一索引處理前先查重、再插入數(shù)據(jù)庫唯一索引兜底。鎖和冪等一起上才能最大程度避免重復(fù)寫數(shù)據(jù)。6. 一套可以直接落地的Redis安全檢查清單與常用排查命令前面說了這么多理論最后我整理一份可以直接拿去用的安全檢查清單。這份清單是我在團(tuán)隊(duì)里做Redis巡檢時(shí)每天都在用的覆蓋了配置層、網(wǎng)絡(luò)層、數(shù)據(jù)層和應(yīng)用層。6.1 配置層自檢表檢查項(xiàng)推薦配置檢查命令監(jiān)聽地址bind 127.0.0.1 或內(nèi)網(wǎng)IPCONFIG GET bind保護(hù)模式protected-mode yesCONFIG GET protected-mode認(rèn)證requirepass強(qiáng)密碼或ACL授權(quán)CONFIG GET requirepass危險(xiǎn)命令rename-command禁用或改名查看redis.confRDB快照按業(yè)務(wù)容忍度配置save策略CONFIG GET saveAOFappendonly yeseverysecCONFIG GET appendonly appendfsync從庫保護(hù)min-replicas-to-write和max-lag合理設(shè)置CONFIG GET min-replicas-*版本至少6.x推薦7.xredis-server --version6.2 常用排查命令# 查看當(dāng)前連接客戶端 redis-cli CLIENT LIST # 查看慢查詢?nèi)罩?redis-cli SLOWLOG GET 50 redis-cli SLOWLOG RESET # 查看運(yùn)行信息 redis-cli INFO keyspace redis-cli INFO replication redis-cli INFO persistence # 查看ACL日志Redis 6 redis-cli ACL LOG # 掃描Big Key低峰期執(zhí)行 redis-cli --bigkeys # 查看某個(gè)key的內(nèi)存占用 redis-cli --bigkeys 或 MEMORY USAGE key名MONITOR命令也很常用它可以實(shí)時(shí)打印Redis執(zhí)行的所有命令但生產(chǎn)環(huán)境務(wù)必慎用。MONITOR開著的時(shí)候Redis會(huì)為每個(gè)命令額外做一次輸出對(duì)性能影響不小我見過有人開著MONITOR做在線調(diào)試結(jié)果Redis響應(yīng)時(shí)間直接翻倍。調(diào)試完記得第一時(shí)間關(guān)掉。Redis 6之后新增的ACL LOG很實(shí)用。它能記錄因權(quán)限不足被拒絕的命令排查時(shí)不用再傻乎乎地翻所有日志。比如懷疑某個(gè)客戶端在嘗試執(zhí)行CONFIG操作一條ACL LOG就能看到被攔截的記錄。6.3 安全基線之外的三點(diǎn)補(bǔ)充第一日志的審計(jì)往往被忽視。建議開啟Redis的慢查詢?nèi)罩竞虯CL日志的持久化為日后的安全事件回溯留下證據(jù)。雖然不能完全防止問題發(fā)生但出了事能快速定位到人和時(shí)間。第二保持版本更新。Redis 7.0之后AOF文件采用了多部分格式重寫和加載效率提升明顯也修復(fù)了不少歷史安全漏洞。如果一個(gè)實(shí)例已經(jīng)運(yùn)行了兩年以上沒動(dòng)過版本我建議列入升級(jí)計(jì)劃升級(jí)前先做全量備份和恢復(fù)演練。第三Redis未授權(quán)訪問類的攻擊在最近的安全通報(bào)里反復(fù)出現(xiàn)我個(gè)人的觀點(diǎn)是不要高估自己團(tuán)隊(duì)的安全水位每隔一個(gè)季度就按這份清單重新巡檢一遍。配置被改回去、安全組被重新放行、新同事不知道規(guī)則誤開端口這些情況我都遇到過。安全不是一次性的項(xiàng)目而是持續(xù)性的習(xí)慣。從我多年的實(shí)戰(zhàn)經(jīng)驗(yàn)來看Redis數(shù)據(jù)安全的本質(zhì)是“訪問可控、數(shù)據(jù)可恢復(fù)、運(yùn)行可預(yù)期、并發(fā)不踩踏”。訪問控制做在前面持久化兜住底應(yīng)用層寫代碼時(shí)多想一層分布式場(chǎng)景對(duì)一致性邊界有清醒認(rèn)知這四個(gè)維度都到位了Redis基本就不會(huì)成為拖垮業(yè)務(wù)的短板。