緩存之王 | Redis最佳實(shí)踐&開發(fā)規(guī)范&FAQ

點(diǎn)擊上方藍(lán)色字體，選擇“設(shè)為星標(biāo)”

回復(fù)”資源“獲取更多資源

本文是來自阿里云2021版最新Redis最佳實(shí)踐指南。文檔可以在云棲社區(qū)下載。

Redis–從問題說起

（一）Run-to-Completion in a solo thread–Redis最大的問題

event到來后，交由后端單線程執(zhí)行。等每個(gè)event處理完成后，才處理下一個(gè)；單線程run-to-completion就是沒有dispatcher，沒有后端的multi-worker。所以如果慢查詢，諸如單機(jī)版的keys、lrange、hgetall等拖慢了一次查詢，那么后面的請(qǐng)求就會(huì)被拖慢。

使用Sentinel判活的trick：

• Ping命令判活：ping命令同樣受到慢查詢影響，如果引擎被卡住，則ping失敗；

• Duplex Failure：sentinel由于慢查詢切備（備變主）再遇到慢查詢，Redis將出現(xiàn)OOS。

（二）擴(kuò)展為集群版，問題可解？

既然一個(gè)Redis進(jìn)程不行，采用分布式方案擴(kuò)展成集群版可以嗎？集群板確實(shí)能解決一部分問題，常見的請(qǐng)求是可以分散到不同DB上的。

但是，集群版也還是解決不了單個(gè)DB被卡住的問題，因?yàn)镽edis的key hash規(guī)則是按照外面的一層PK來做的，沒有按照里面的子key或者是field的來做，如果用戶調(diào)用了跨分片的命令，如mget，訪問到出問題的db，仍會(huì)block住，問題還是會(huì)存在。

（三）Protocol問題–大量客戶端與引擎Fully-Meshed問題

采用Redis協(xié)議（RESP）的問題:

• 擴(kuò)展性太差：基于Question-Answer模式，由于在Question/Answer里面沒有對(duì)應(yīng)的Sequence的存在，(如果不做復(fù)雜的轉(zhuǎn)換wrapper層)存儲(chǔ)引擎端沒法match請(qǐng)求和響應(yīng)，只能采用Run-To-Completion來掛住鏈接;

• C10K的問題：當(dāng)引擎掛住太多active鏈接的時(shí)候，性能下降太多。測(cè)試結(jié)果是當(dāng)有10k active連接時(shí)，性能下降30-35%，由于引擎端掛住的鏈接不能被返回，用戶大量報(bào)錯(cuò)。

（四）“Could not get a resource from the pool”

如下圖所示，由于Redis執(zhí)行Run-To-Completion特性，客戶端只能采用連接池的方案；Redis協(xié)議不支持連接池收斂，是因?yàn)镸essage沒有ID，所以Request和Response對(duì)不起來。連接池具體運(yùn)作方式是每次查詢，都要先從連接池拿出一根連接來，當(dāng)服務(wù)端返回結(jié)果后，再放回連接池。

如果用戶返回的及時(shí)，那么連接池一直保有的連接數(shù)并不高，但是一旦服務(wù)端未及時(shí)返回，客戶端又有新的請(qǐng)求，就只能再checkout一根連接。

當(dāng)Engine層出現(xiàn)慢查詢，就會(huì)讓請(qǐng)求返回的慢，造成的后果是很容易讓用戶把連接池用光，當(dāng)應(yīng)用機(jī)器特別多的情況，按每個(gè)client 連接池50個(gè)max link來算，很容易打到10K鏈接的限制，導(dǎo)致engine回調(diào)速度慢。

當(dāng)連接池被checkout完，就會(huì)爆沒有連接的異常："Could not get a resource from the pool"，這是非常常見的錯(cuò)誤，有惡性循環(huán)的邏輯在里面。比如說服務(wù)端返回的慢，連接池的連接就會(huì)創(chuàng)建的很快，用戶很容易達(dá)到1萬條，創(chuàng)建的連接越多，性能越差，返回越慢，服務(wù)容易血崩。

Redis–不要觸碰邊界

Redis的邊界 --紅色區(qū)域代表危險(xiǎn) 上述羅列的問題，是為了讓我們?cè)陂_發(fā)業(yè)務(wù)的時(shí)候，不要觸碰Redis的邊界。下面從計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)三個(gè)維度出發(fā)，總結(jié)了這張圖：

計(jì)算方面：Wildcard、Lua并發(fā)、1對(duì)N PUBSUB、全局配置/熱點(diǎn)，會(huì)大量消耗計(jì)算資源（高計(jì)算消耗）；

存儲(chǔ)方面：Streaming慢消費(fèi)、Bigkey等，造成高存儲(chǔ)消耗。

網(wǎng)絡(luò)方面：Keys等掃全表、Huge Batch mget/mset、大Value、Bigkey Range （如hgetall，smembers），造成高網(wǎng)絡(luò)消耗。

Redis的邊界總結(jié)：

• 高并發(fā)不等于高吞吐 大 Value 的問題：高速存儲(chǔ)并不會(huì)有特別大的高吞吐收益，相反會(huì)很危險(xiǎn)；

• 數(shù)據(jù)傾斜和算力傾斜 bigKey 的問題：break掉存儲(chǔ)的分配律；熱點(diǎn)的問題，本質(zhì)上是cpu上的分配律不滿足；大 Range 的問題：對(duì)NoSQL的慢查詢和導(dǎo)致的危害沒有足夠的重視。

• 存儲(chǔ)邊界 Lua使用不當(dāng)造成的成本直線上升；數(shù)據(jù)傾斜帶來的成本飆升，無法有效利用；

• 對(duì)于 Latency 的理解問題（RT高） 存儲(chǔ)引擎的 Latency 都是P99 Latency，如：99.99%在1ms以內(nèi)，99.5%在3ms以內(nèi)，等；偶發(fā)性時(shí)延高是必然的。這個(gè)根因在于存儲(chǔ)引擎內(nèi)部的復(fù)雜性和熵。

Redis–阿里內(nèi)部開發(fā)規(guī)約

Redis的使用建議

推薦：

• 確定場(chǎng)景，是緩存（cache）還是存儲(chǔ)型；

• Cache的使用原則是：“無它也可，有它更強(qiáng)”；

• 永遠(yuǎn)不要強(qiáng)依賴Cache，它會(huì)丟，也會(huì)被淘汰；

• 優(yōu)先設(shè)計(jì)合理的數(shù)據(jù)結(jié)構(gòu)和邏輯；

• 設(shè)計(jì)避免bigKey，就避免了80%的問題；

• Keyspace能分開，就多申請(qǐng)幾個(gè)Redis實(shí)例；

• pubsub不適合做消息分發(fā)；

• 盡量避免用lua做事務(wù)。

不建議：

• 我的服務(wù)對(duì)RT很敏感。>> 低RT能讓我的服務(wù)運(yùn)行的更好;

• 我把存儲(chǔ)都公用在一個(gè)redis里。>> 區(qū)分cache和內(nèi)存數(shù)據(jù)庫用法，區(qū)分應(yīng)用;

• 我有一個(gè)大排行榜/大集合/大鏈表/消息隊(duì)列；我覺得服務(wù)能力足夠了。>> 盡量拆散，服務(wù)能力不夠可通過分布式集群版可以打散;

• 我有一個(gè)特別大的Value，存在redis里，訪問能好些。>> redis吞吐量有瓶頸。

（一）BigKey–洪水猛獸

BigKey，我們稱之為洪水猛獸，據(jù)初步統(tǒng)計(jì)，80%問題由bigKey導(dǎo)致。如下圖所示：集群中有4個(gè)分片，每個(gè)分片大約有102個(gè)key，實(shí)際上是均勻分布。圖中第三個(gè)key叫key301，hash301，中間有一個(gè)放了200w的hash，但因?yàn)楦鶕?jù)hash301打散的這個(gè)key是個(gè) bigkey，嚴(yán)重造成數(shù)據(jù)傾斜。

別的key只用了10%或20%的內(nèi)存，key301用了約80%，而且大概率是熱點(diǎn)。上圖的使用用法，有可能造成有一個(gè)分片內(nèi)存滿了，訪問出了問題，但是其他分片卻用的很閑。問題分片的訪問比較熱，造成網(wǎng)卡打滿，或者CPU打滿，導(dǎo)致限流，服務(wù)可能就夯住了。

（二）Redis LUA JIT

下面的示意圖表示了一次腳本的執(zhí)行過程，客戶端調(diào)用EVAL script之后會(huì)產(chǎn)生SCRIPT Load的行為，Lua JIT開始編譯生成字節(jié)碼，這時(shí)產(chǎn)生一個(gè)SHA字符串，表示 bytecode的緩存。Loading bytecode之后，開始執(zhí)行腳本，還需要保證在副本上執(zhí)行成功，最后unload和Cleaning，整個(gè)過程結(jié)束。

示意圖中有3個(gè)火形圖標(biāo)，表示耗費(fèi)CPU的程度，腳本的compile-load-run-unload非常耗費(fèi)CPU。整個(gè)lua相當(dāng)于把復(fù)雜事務(wù)推送到Redis中執(zhí)行，如果稍有不慎CPU會(huì)爆，引擎算力耗光后掛住redis。對(duì)上述的情況，Redis做了一些優(yōu)化，比如“Script + EVALSHA”，可以先把腳本在redis中預(yù)編譯和加載（不會(huì)unload和clean），使用EVALSHA執(zhí)行，會(huì)比純EVAL省CPU，但是Redis重啟/切換/變配bytecode cache會(huì)失效，需要reload，仍是缺陷方案。建議使用復(fù)雜數(shù)據(jù)結(jié)構(gòu)，或者module來取代lua。

• 對(duì)于JIT技術(shù)在存儲(chǔ)引擎中而言，“EVAL is evil”，盡量避免使用lua耗費(fèi)內(nèi)存和計(jì)算資源（省事不省心）；

• 某些SDK（如Redisson）很多高級(jí)實(shí)現(xiàn)都內(nèi)置使用lua，開發(fā)者可能莫名走入CPU運(yùn)算風(fēng)暴中，須謹(jǐn)慎。

（三）Pubsub/Transaction/Pipeline

Pubsub的典型場(chǎng)景 Pubsub適合悲觀鎖和簡(jiǎn)單信號(hào)，不適合穩(wěn)定的更新，因?yàn)榭赡軙?huì)丟消息。在1對(duì)N的消息轉(zhuǎn)發(fā)通道中，服務(wù)瓶頸。還有模糊通知方面，算力瓶頸。在channel和client比較多的情況下，造成CPU打滿、服務(wù)夯住。Transaction Transaction是一種偽事物，沒有回滾條件；集群版需要所有key使用hashtag保證，代碼比較復(fù)雜，hashtag也可能導(dǎo)致算力和存儲(chǔ)傾斜；Lua中封裝了multi-exec，但更耗費(fèi)CPU，比如編譯、加載時(shí)，經(jīng)常出現(xiàn)問題。

Pipeline

Pipeline用的比較多，如下面的示意圖，實(shí)際上是把多個(gè)請(qǐng)求封裝在一個(gè)請(qǐng)求中，合并在一個(gè)請(qǐng)求里發(fā)送，服務(wù)端一次性返回，能夠有效減少IO，提高執(zhí)行效率。需要注意的是，用戶需要聚合小的命令，避免在pipeline里做大range。注意Pipeline中的批量任務(wù)不是原子執(zhí)行的（從來不是），所以要處理Pipeline其中部分命令失敗的場(chǎng)景。

（四）KEYS 命令

KEYS命令，一定會(huì)出問題，即使當(dāng)前沒有，客戶數(shù)據(jù)量上漲后必然引發(fā)慢查，出現(xiàn)后無能為力。這種情況，需要在一開始就提前預(yù)防，可以在控制臺(tái)通過危險(xiǎn)命令禁用，禁止掉keys命令，出現(xiàn)時(shí)也可以使用一些手段優(yōu)化。KEYS命令的模糊匹配：

• Redis存儲(chǔ)key是無序的，匹配時(shí)必然全表掃描， key數(shù)目一多必然卡住，所以一定要去優(yōu)化。如下圖所例子中所示，修改為hash結(jié)構(gòu)：

• 可以從全表掃描變?yōu)辄c(diǎn)查/部分range, 雖然hash結(jié)構(gòu)中field太多也會(huì)慢，但比keys性能提升一個(gè)到兩個(gè)數(shù)量級(jí)。

這個(gè)例子里面，Product1前綴可以提取成為hash的KEY，如果要去product1前綴的所有東西，其實(shí)可以下發(fā)一個(gè)HGETALL，這樣的就是優(yōu)化了。

（五）除去KEYS，下面命令依然危險(xiǎn)

• hgetall，smembers，lrange，zrange，exhgetall 直接與數(shù)據(jù)結(jié)構(gòu)的subkey（field）多少相關(guān)，O(n)，攜帶value爆網(wǎng)卡。建議使用scan來替代。

• bitop，bitset 設(shè)置過遠(yuǎn)的bit會(huì)直接導(dǎo)致OOM。

• flushall，flushdb 數(shù)據(jù)丟失。

用戶在操作的時(shí)候，需要很小心，因?yàn)闀?huì)清空數(shù)據(jù)庫。在阿里云Redis控制臺(tái)里面點(diǎn)清除數(shù)據(jù)時(shí)，需要使用二次校驗(yàn)，避免隨意清除數(shù)據(jù)。另外還可以單獨(dú)清理過期數(shù)據(jù)，對(duì)其他正常訪問的數(shù)據(jù)沒有影響。

• 配置中和ziplist相關(guān)的參數(shù) Redis在存儲(chǔ)相關(guān)數(shù)據(jù)結(jié)構(gòu)時(shí)，數(shù)據(jù)量比較小，底層使用了ziplist結(jié)構(gòu)，達(dá)到一定的量級(jí)，比如key/field變多了，會(huì)轉(zhuǎn)換數(shù)據(jù)結(jié)構(gòu)。當(dāng)結(jié)構(gòu)在ziplist結(jié)構(gòu)體下時(shí)，算力開銷變大，部分查詢變O(n)級(jí)別，匹配變O(m*n)，極端情況容易打滿CPU，不過占用的內(nèi)存確實(shí)變少了（需要評(píng)估帶來的收益是否匹配付出的代價(jià)？）。

建議用戶盡量使用默認(rèn)參數(shù)。

規(guī)范總結(jié) [ Just FYI ] 1.選型：用戶需要確定場(chǎng)景是cache還是內(nèi)存數(shù)據(jù)庫使用

• Cache場(chǎng)景，關(guān)閉AOF；內(nèi)存數(shù)據(jù)庫選擇雙副本

• 如果keyspace能夠分開，就申請(qǐng)不同的實(shí)例來隔離

2.使用：避免觸發(fā)高速存儲(chǔ)的邊界

• set/hash/zset/list/tairhash/bloom/gis等大key（內(nèi)部叫做godkey）不要超過3000，會(huì)記錄sillylog

• 避免使用keys，hgetall，lrange0-1等大range（使用scan替代）

• 避免使用大value（10k以上就算大value，50k會(huì)記錄）

3.SDK：使用規(guī)范

• 嚴(yán)禁設(shè)置低讀超時(shí)和緊密重試（建議設(shè)置200ms以下read timeout）

• 需要接受P99時(shí)延，對(duì)超時(shí)和慢做容錯(cuò)處理

• 盡量使用擴(kuò)展數(shù)據(jù)結(jié)構(gòu)，避免使用lua

• 盡量避免pubsub和blocking的API

4.接受主動(dòng)運(yùn)維

• 在阿里云上，如果機(jī)器宕機(jī)，或者是機(jī)器后面有風(fēng)險(xiǎn)，我們會(huì)做主動(dòng)運(yùn)維保證服務(wù)的穩(wěn)定性。

Redis–常見問題處理

（一）Tair/Redis內(nèi)存模型

內(nèi)存控制是Redis的精華部分，大部分遇到的問題都是跟內(nèi)存有，Tair/Redis內(nèi)存模型，如下圖所示，總內(nèi)存分為3個(gè)部分：鏈路內(nèi)存（動(dòng)態(tài)）、數(shù)據(jù)內(nèi)存、管理內(nèi)存（靜態(tài)）。

• 鏈路內(nèi)存（動(dòng)態(tài)）：主要包括Input buff、Output buff等，Input buff與Output buff跟每個(gè)客戶端的連接有關(guān)系，正常情況下比較小，但是當(dāng)Range操作的時(shí)候，或者有大key收發(fā)比較慢的時(shí)候，這兩個(gè)區(qū)的內(nèi)存會(huì)增大，影響數(shù)據(jù)區(qū)，甚至?xí)斐蒓OM。還包括JIT Overhead、Fake Lua Link，包含了Code cache執(zhí)行緩存等等。

• 數(shù)據(jù)內(nèi)存：用戶數(shù)據(jù)區(qū)，就是用戶實(shí)際存儲(chǔ)的value。

• 管理內(nèi)存（靜態(tài)）：是靜態(tài)buff，啟動(dòng)的時(shí)候比較小，比較恒定。這個(gè)區(qū)域主要管理data的hash開銷，當(dāng)key非常多的時(shí)候，比如幾千萬、幾個(gè)億，會(huì)占用非常大的內(nèi)存。還包括Repl-buff、aof-buff（32M～64M）通常來說比較小。

OOM場(chǎng)景，大都是動(dòng)態(tài)內(nèi)存管理失效，例如限流的影響（plus timer mem），限流的時(shí)候請(qǐng)求出不去，導(dǎo)致請(qǐng)求堆積后動(dòng)態(tài)內(nèi)存極速飆升，造成OOM；無所畏懼的Lua腳本也有可能造成OOM。原生的Redis被定義為“緩存”，在動(dòng)態(tài)內(nèi)存上控制比較粗糙。Tair對(duì)這部分做了加強(qiáng)，致力于footprint control，售賣內(nèi)存接近User Dataset。

（二）緩存分析–內(nèi)存分布統(tǒng)計(jì)、bigKey，key pattern

對(duì)于內(nèi)存，阿里云有現(xiàn)成的功能一鍵分析，使用入口在“實(shí)例管理”-》“CloudDBA”下面的“緩存分析”，熱Key分析無需主動(dòng)觸發(fā)。數(shù)據(jù)源支持歷史備份集，現(xiàn)有備份集，可以準(zhǔn)實(shí)時(shí)或者對(duì)歷史備份做分析。支持線上所有的社區(qū)版和企業(yè)版。也支持線上所有的架構(gòu)，包括標(biāo)準(zhǔn)版、讀寫分離版、集群版。

使用入口

• “實(shí)例管理”-->“CloudDBA”-->“緩存分析”-->“立即分析”；熱Key分析無需主動(dòng)觸發(fā)。

數(shù)據(jù)源

• 支持已有備份集；

• 支持自動(dòng)新建備份集。

支持版本

• 社區(qū)版（2.8~6.0）；

• 企業(yè)版（Tair）。

支持架構(gòu)

• 標(biāo)準(zhǔn)版；

• 讀寫分離版；

• 集群版。

下圖所示，是阿里云控制臺(tái)使用截圖，這個(gè)功能比較常用，已開放OpenApi，可被集成。

下圖所示，是緩存分析報(bào)告，可以看到每一個(gè)DB內(nèi)存分布統(tǒng)計(jì)，包括不同類型的數(shù)據(jù)結(jié)構(gòu)內(nèi)存統(tǒng)計(jì)，key對(duì)應(yīng)的元素?cái)?shù)分級(jí)統(tǒng)計(jì)，可以統(tǒng)計(jì)到總體上大概有多少個(gè)大key；統(tǒng)計(jì) key過期時(shí)間分布，可以發(fā)現(xiàn)過期時(shí)間設(shè)置的是否合理。Top 100 BigKey(按內(nèi)存)，可以發(fā)現(xiàn)具體有哪些大key，業(yè)務(wù)上可以參照這個(gè)做優(yōu)化。Top 100 BigKey前綴是做了key pattern統(tǒng)計(jì)，如果key是按照業(yè)務(wù)模塊來制定的前綴，可以統(tǒng)計(jì)到各個(gè)業(yè)務(wù)上用了多少內(nèi)存，也可以大體上指導(dǎo)業(yè)務(wù)優(yōu)化。

（三）熱Key分析

阿里云提供了在線和離線兩種熱Key分析方式：在線實(shí)時(shí)分析熱key

• 使用入口：“實(shí)例管理” --> “CloudDBA” --> “緩存分析” -->“HotKey”；

• 使用須知：Tair版，或Redis版本>=redis4.0；

• 精確統(tǒng)計(jì)（非采樣），能抓出當(dāng)前所有 Per Key QPS > 3000的記錄；

離線分析熱key

• 方法1：緩存分析也可以分析出相對(duì)較熱的key，通過工具實(shí)現(xiàn)；

• 方法2：最佳實(shí)踐，imonitor命令 + redis-faina 分析出熱點(diǎn)Key；

  （四）Tair/Redis全鏈路診斷

Tair/Redis全鏈路診斷，從“APP端的SDK”到“網(wǎng)絡(luò)”到“VIP”到“ Proxy”再到“DB”，每個(gè)部分都有可能會(huì)出問題。問題排查包括：前端排查和后端排查。前段排查首先需要確定是一臺(tái)出問題，還是全部有問題，如果是一臺(tái)出問題，大概率是客戶端自己的問題，包括：

• ECS

• Load，內(nèi)存等；

• PPS限制。

• 客戶端

• 鏈接池滿；

• RT高（跨地域，gc等）；

• 建鏈接慢（K8s DNS等）；

• 大查詢，發(fā)快收慢。

• 網(wǎng)絡(luò)

• 丟包，收斂；

• 運(yùn)營(yíng)商網(wǎng)絡(luò)抖動(dòng)。

后端排查：主要是慢查和CPU排查，包括“VIP”、“ Proxy”、“DB”。Tair/Redis 80%的問題是RT（latency）相關(guān)。

• VIP（SLB/NGLB）

• 建鏈接瓶頸（極少）；

• 流量不均衡（少）；

• 流量瓶頸（極少）。

• Proxy

• 分發(fā)慢查；

• 流量高（擴(kuò)容proxy）；

• 消息堆積；

• Backend網(wǎng)絡(luò)抖動(dòng)。

• DB

• 容量，CPU，流量（見前文）；

• 主機(jī)故障，HA速度；

• 慢查詢。

  （五）Tair/Redis診斷報(bào)告

對(duì)于全鏈路診斷，我們推出了診斷報(bào)告功能，可以對(duì)某個(gè)時(shí)間段發(fā)起“一鍵診斷”，這里主要是后端排查，目前都是“DB”相關(guān)，可以看到有哪些異常情況發(fā)生。如下圖所示：

核心曲線：核心指標(biāo)的曲線，可以看哪些時(shí)間點(diǎn)，哪些節(jié)點(diǎn)有峰值。

慢請(qǐng)求：展示了Top 10節(jié)點(diǎn)的Top 10慢命令統(tǒng)計(jì)；

性能水位：可以看到哪些指標(biāo)、哪些節(jié)點(diǎn)超過了預(yù)設(shè)水位，或者是這些節(jié)點(diǎn)是不是發(fā)生了傾斜，對(duì)發(fā)現(xiàn)問題有很大的幫助。

診斷：準(zhǔn)實(shí)時(shí)的對(duì)過去最近半小時(shí)，1小時(shí)，或者對(duì)過去某一天、某幾天的診斷。

（六）Tair/Redis慢日志

設(shè)置合理的Proxy和DB慢日志采集參數(shù)

• slowlog-log-slower-than：DB分片上慢日志閾值，不可設(shè)置過低！；

• slowlog-max-len：DB分片slowlog鏈表最大保持長(zhǎng)度；

• rt_threshold_ms：Proxy上慢日志閾值，不可設(shè)置過低！。

以上建議使用默認(rèn)的參數(shù)，不要設(shè)置過小，因?yàn)槿绻@些閾值設(shè)置的過小，那么DB在采集慢日志的時(shí)候會(huì)頻繁記錄，可能造成引擎的性能降低，所以盡量使用默認(rèn)參數(shù)。

慢日志查詢功能分為歷史慢日志和實(shí)時(shí)慢日志，入口也不相同，區(qū)別在于歷史慢日志可獲取近72小時(shí)內(nèi)的慢日志。實(shí)時(shí)慢日志能抓出當(dāng)前所有分片slowlog，但是有一個(gè)局限性，如果節(jié)點(diǎn)發(fā)生了HA或者手動(dòng)清理慢日志，這部分慢日志就沒有了。使用入口如下圖所示：

歷史慢日志

• 使用入口：“實(shí)例管理” --> “日志管理” --> “慢日志”；

• 使用須知：Tair版，或Redis版本>=redis4.0，具體查看幫助文檔；

• 可獲取近72小時(shí)內(nèi)的慢日志。

實(shí)時(shí)慢日志

• 使用入口：“實(shí)例管理” --> “CloudDBA” --> “慢請(qǐng)求”；

• 實(shí)時(shí)獲取，能抓出當(dāng)前所有分片slowlog。

【大數(shù)據(jù)技術(shù)與架構(gòu)】2021年大數(shù)據(jù)面試進(jìn)階系列系統(tǒng)總結(jié)