通過這篇文章你會(huì)知曉如下內(nèi)容：
- redis阻塞的常規(guī)的內(nèi)在原因和外在原因都有哪些过咬？
- API不合理引起的阻塞排查方法有哪些？
- 造成CPU出現(xiàn)飽和的因素 有哪些制妄，如何排查掸绞？
- 持久化過程中哪些方面會(huì)引起阻塞，如何排查耕捞？
-
API或者數(shù)據(jù)結(jié)構(gòu)使用不合理
對(duì)于高并發(fā)的場景我們應(yīng)該**盡量避免在大對(duì)象上執(zhí)行算法復(fù)雜度超過O（n） 的命令
-
發(fā)現(xiàn)慢查詢
慢查詢本身只記錄了命令執(zhí)行時(shí)間衔掸， 不包括數(shù)據(jù)網(wǎng)絡(luò)傳輸時(shí)間和命令排隊(duì)時(shí)間， 因此客戶端發(fā)生阻塞異常后俺抽， 可能不是當(dāng)前命令緩慢敞映， 而是在等待其他命令執(zhí)行。 需要重點(diǎn)比對(duì)異常和慢查詢發(fā)生的時(shí)間點(diǎn)磷斧， 確認(rèn)是否有慢查詢造成的命令阻塞排隊(duì) -
發(fā)現(xiàn)大對(duì)象
通過命令redis-cli --bigkeys查詢大對(duì)象
-
CPU的飽和
CPU飽和振愿，將導(dǎo)致Redis無法處理更多的命令捷犹， 嚴(yán)重影響吞吐量和應(yīng)用方的穩(wěn)定性
通過命令 redis-cli --stat 查看redis使用情況
通過命令 info commandstats 查看命令的不合理開銷時(shí)間，同時(shí)這個(gè)命令要結(jié)合各個(gè)API的時(shí)間復(fù)雜度來分析冕末，是否存在一些不合理的使用
-
持久化阻塞
對(duì)于開啟了持久化功能的Redis節(jié)點(diǎn)萍歉， 需要排查是否是持久化導(dǎo)致的阻塞。 持久化引起主線程阻塞的操作主要有： fork阻塞栓霜、 AOF刷盤阻塞翠桦、HugePage寫操作阻塞
-
fork阻塞
fork操作發(fā)生在RDB和AOF重寫時(shí)， Redis主線程調(diào)用fork操作產(chǎn)生共享內(nèi)存的子進(jìn)程胳蛮， 由子進(jìn)程完成持久化文件重寫工作销凑。 如果fork操作本身耗時(shí)過長， 必然會(huì)導(dǎo)致主線程的阻塞
可以執(zhí)行info stats命令獲取到latest_fork_usec指標(biāo)仅炊， 表示Redis最近一次fork操作耗時(shí)斗幼，如果過大要進(jìn)行優(yōu)化，針對(duì)fork的各個(gè)執(zhí)行過程進(jìn)行優(yōu)化 -
AOF刷盤阻塞
當(dāng)我們開啟AOF持久化功能時(shí)抚垄， 文件刷盤的方式一般采用每秒一次蜕窿， 后臺(tái)線程每秒對(duì)AOF文件做fsync操作。 當(dāng)硬盤壓力過大時(shí)呆馁， fsync操作需要等待桐经， 直到寫入完成。
查看info persistence統(tǒng)計(jì)中的iaof_delayed_fsync指標(biāo)浙滤， 每次發(fā)生fdatasync阻塞主線程時(shí)會(huì)累加
使用iotop命令可以查詢各個(gè)進(jìn)程對(duì)硬盤的使用情況
同時(shí)可以查閱官網(wǎng)的阻塞問題分析
-
CPU競爭
Redis是典型的CPU密集型應(yīng)用阴挣， 不建議和其他多核CPU密集型服務(wù)部署在一起。 當(dāng)其他進(jìn)程過度消耗CPU時(shí)纺腊， 將嚴(yán)重影響Redis吞吐量畔咧。 可以通過top、 sar等命令定位到CPU消耗的時(shí)間點(diǎn)和具體進(jìn)程揖膜，更多的linux命令監(jiān)控可以查閱這篇文章
-
內(nèi)存交換
內(nèi)存交換
