redis哪些情況會(huì)導(dǎo)致長(zhǎng)時(shí)間阻塞

為什么阻塞
  • 內(nèi)部原因
    (1)redis采用單線程處理請(qǐng)求,reactor是同步IO,需要等待命令執(zhí)行完成,才會(huì)返回執(zhí)行結(jié)果,然后進(jìn)入下一個(gè)請(qǐng)求(隊(duì)列)
    (2)持久化阻塞
    (3)CPU飽和
  • 外部原因
    (1)不合理使用API和數(shù)據(jù)結(jié)構(gòu)(bigkes、慢查詢)
    (2)網(wǎng)絡(luò)問(wèn)題(最大連接數(shù)、網(wǎng)絡(luò)延遲)
    (3)內(nèi)存交換
持久化阻塞
  • fork阻塞: fork操作發(fā)生在rdb和aof重寫(xiě)時(shí),redis主線程調(diào)用fork操作產(chǎn)生共享內(nèi)存的子進(jìn)程,由子進(jìn)程完成持久化文件重寫(xiě)工作,若fork操作本身耗時(shí)過(guò)長(zhǎng),則必會(huì)導(dǎo)致主線程阻塞;可執(zhí)行info stats命令獲取到latest_fork_usec指標(biāo),表示redis最近一次fork操作耗時(shí),若超過(guò)1s,則需要做出優(yōu)化調(diào)整
  • aof刷盤(pán)阻塞: 當(dāng)開(kāi)啟aof持久化功能時(shí),文件刷盤(pán)的方式一般采用每秒一次,后臺(tái)線程每秒對(duì)aof文件做fsync操作,硬盤(pán)壓力過(guò)大時(shí),fsync操作需要等待,直到寫(xiě)入完成如果主線程發(fā)現(xiàn)距離上一次的fsync成功超過(guò)2秒,為了數(shù)據(jù)安全性它會(huì)阻塞直到后臺(tái)線程執(zhí)行fsync操作完成,這種阻塞行為主要是硬盤(pán)壓力引起,可查看Redis日志識(shí)別出這種情況
CPU飽和

單線程的Redis處理命令時(shí)只能使用一個(gè)CPU。而CPU飽和是指Redis把單核CPU使用率跑到接近100%。使用top命令很容易識(shí)別出對(duì)應(yīng)Redis進(jìn)程的CPU使用率。CPU飽和是非常危險(xiǎn)的,將導(dǎo)致Redis無(wú)法處理更多的命令,嚴(yán)重影響吞吐量和應(yīng)用方的穩(wěn)定性。
應(yīng)對(duì)之策是做好CPU監(jiān)控報(bào)警策略,如果使用的阿里云redis,可以在阿里云后臺(tái)設(shè)置CPU使用閾值預(yù)警

不合理使用API和數(shù)據(jù)結(jié)構(gòu)(bigkes、慢查詢)
  • 使用大對(duì)象

    1. 將大對(duì)象拆分為小對(duì)象
    2. 發(fā)現(xiàn)大對(duì)象的命令:redis-cli -h{ip} -p{port} bigkeys ,內(nèi)部原理采用分段進(jìn)行scan操作,把歷史掃描過(guò)的最大對(duì)象統(tǒng)計(jì)出來(lái)便于分析優(yōu)化。
  • 使用keys取出所有key

    1. keys [pattern] 一次性全部返回符合條件的key,如果數(shù)據(jù)量很大將會(huì)阻塞其他客戶端
    2. 在數(shù)量未知或者數(shù)量較大的情況下使用scan遍歷來(lái)獲取所有的key
  • 大量的key同時(shí)過(guò)期

    1. 如果有很多key在同一秒內(nèi)過(guò)期,超過(guò)了所有key的25%,redis主線程就會(huì)阻塞直到過(guò)期key比例下降到25%以內(nèi)
    2. 因?yàn)橐苊獯罅康膋ey同時(shí)過(guò)期
網(wǎng)絡(luò)問(wèn)題
  • redis連接拒絕(超過(guò)客戶端最大連接數(shù))
  • 網(wǎng)絡(luò)延遲
  • 網(wǎng)卡軟中斷(一般出現(xiàn)在網(wǎng)絡(luò)高流量吞吐的場(chǎng)景)
內(nèi)存交換
  • 內(nèi)存交換(swap)對(duì)于Redis來(lái)說(shuō)是非常致命的,Redis保證高性能的一個(gè)重要前提是所有的數(shù)據(jù)在內(nèi)存中。如果操作系統(tǒng)把Redis使用的部分內(nèi)存換出到硬盤(pán),由于內(nèi)存與硬盤(pán)讀寫(xiě)速度差幾個(gè)數(shù)量級(jí),會(huì)導(dǎo)致發(fā)生交換后的Redis性能急劇下降。
感謝

原文鏈接:http://www.itdecent.cn/p/94a83f57bf94
原文鏈接:https://blog.csdn.net/linbiaorui/article/details/79822318
原文鏈接:http://www.itdecent.cn/p/b8880db58241

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

友情鏈接更多精彩內(nèi)容