Redis是典型的單線程架構(gòu)歉眷，所有的讀寫操作都是在一條主線程中完成的果复。當Redis用于高并發(fā)場景時缭裆，這條線程就變成了它的生命線键闺。如果出現(xiàn)阻塞，哪怕是很短時間澈驼，對于應用來說都是噩夢辛燥。
導致阻塞問題的原因：
內(nèi)在原因：不合理地使用API或數(shù)據(jù)結(jié)構(gòu)、CPU飽和缝其、持久化阻塞等
外在原因：CPU競爭挎塌、內(nèi)存交換、網(wǎng)絡(luò)問題等
一内边、發(fā)現(xiàn)阻塞
應用方加入異常監(jiān)控榴都，如日志系統(tǒng)，比如Java語言中的logback或log4j
Redis監(jiān)控系統(tǒng)漠其，如CacheCloud
二嘴高、內(nèi)在原因
2.1 API或數(shù)據(jù)結(jié)構(gòu)使用不合理
通常Redis執(zhí)行命令速度非常快和屎，但是拴驮，如果對一個包含上萬個元素的hash結(jié)構(gòu)執(zhí)行hgetall操作，由于數(shù)據(jù)量比較大且命令算法復雜度是O(n)柴信，這條命令執(zhí)行速度必然很慢套啤。
對于高并發(fā)的場景應該盡量避免在大對象上執(zhí)行算法復雜度超過O(n)的命令。
（1）如何發(fā)現(xiàn)慢查詢
Redis原生提供慢查詢統(tǒng)計功能颠印，執(zhí)行slowlog get{n}命令可以獲取最近的n條慢查詢命令纲岭，默認對于執(zhí)行超過10毫秒的命令都會記錄到一個定長隊列中，線上實例建議設(shè)置為1毫秒便于及時發(fā)現(xiàn)毫秒級以上的命令线罕。
（2）發(fā)現(xiàn)慢查詢后如何調(diào)整
修改為低算法復雜度的命令
調(diào)整大對象：縮減大對象數(shù)據(jù)或把大對象拆分為多個小對象止潮，防止一次命令操作過多的數(shù)據(jù)。大對象拆分過程需要視具體的業(yè)務決定钞楼，如用戶好友集合存儲在Redis中喇闸，有些熱點用戶會關(guān)注大量好友，這時可以按時間或其他維度拆分到多個集合中。
（3）如何發(fā)現(xiàn)大對象
Redis本身提供發(fā)現(xiàn)大對象的工具燃乍。具體命令：
redis-cli?-h?{ip}??-p?{port}?--bigkeys
內(nèi)部原理采用分段進行scan操作唆樊，把歷史掃描過的最大對象統(tǒng)計出來便于分析優(yōu)化。
2.2 CPU飽和
單線程的Redis處理命令時只能使用一個CPU刻蟹。而CPU飽和是指Redis把單核CPU使用率跑到接近100%逗旁。使用top命令很容易識別出對應Redis進程的CPU使用率。CPU飽和是非常危險的舆瘪，將導致Redis無法處理更多的命令片效，嚴重影響吞吐量和應用方的穩(wěn)定性。對于這種情況英古，首先判斷當前Redis的并發(fā)量是否達到極限淀衣，建議使用統(tǒng)計命令redis-cli -h {ip} -p {port} --stat獲取當前Redis使用情況
2.3 持久化阻塞
對于開啟了持久化功能的Redis節(jié)點，需要排查是否是持久化導致的阻塞召调。
fork阻塞：fork操作發(fā)生在RDB和AOF重寫時膨桥，Redis主線程調(diào)用fork操作產(chǎn)生共享內(nèi)存的子進程，由子進程完成持久化文件重寫工作唠叛。如果fork操作本身耗時過長只嚣，必然會導致主線程的阻塞。
AOF刷盤阻塞：當我們開啟AOF持久化功能時玻墅，文件刷盤的方式一般采用每秒一次介牙，后臺線程每秒對AOF文件做fsync操作。當硬盤壓力過大時澳厢，fsync操作需要等待环础，直到寫入完成。如果主線程發(fā)現(xiàn)距離上一次的fsync成功超過2秒剩拢，為了數(shù)據(jù)安全性它會阻塞直到后臺線程執(zhí)行fsync操作完成线得。這種阻塞行為主要是硬盤壓力引起。
HugePage寫操作阻塞：子進程在執(zhí)行重寫期間利用Linux寫時復制技術(shù)降低內(nèi)存開銷徐伐，因此只有寫操作時Redis才復制要修改的內(nèi)存頁贯钩。對于開啟Transparent HugePages的操作系統(tǒng)，每次寫命令引起的復制內(nèi)存頁單位由4K變?yōu)?MB办素，放大了512倍角雷，會拖慢寫操作的執(zhí)行時間，導致大量寫操作慢查詢性穿。
三勺三、外在原因
3.1 CPU競爭
進程競爭：Redis是典型的CPU密集型應用，不建議和其他多核CPU密集型服務部署在一起需曾。當其他進程過度消耗CPU時吗坚，將嚴重影響Redis吞吐量祈远。可以通過top商源、sar等命令定位到CPU消耗的時間點和具體進程车份，這個問題比較容易發(fā)現(xiàn)，需要調(diào)整服務之間部署結(jié)構(gòu)牡彻。
綁定CPU：部署Redis時為了充分利用多核CPU扫沼，通常一臺機器部署多個實例。常見的一種優(yōu)化是把Redis進程綁定到CPU上讨便，用于降低CPU頻繁上下文切換的開銷充甚。這個優(yōu)化技巧正常情況下沒有問題，但是存在例外情況霸褒，當Redis父進程創(chuàng)建子進程進行RDB/AOF重寫時，如果做了CPU綁定盈蛮，會與父進程共享使用一個CPU废菱。子進程重寫時對單核CPU使用率通常在90%以上，父進程與子進程將產(chǎn)生激烈CPU競爭抖誉，極大影響Redis穩(wěn)定性殊轴。因此對于開啟了持久化或參與復制的主節(jié)點不建議綁定CPU。
3.2 內(nèi)存交換
內(nèi)存交換（swap）對于Redis來說是非常致命的袒炉，Redis保證高性能的一個重要前提是所有的數(shù)據(jù)在內(nèi)存中旁理。如果操作系統(tǒng)把Redis使用的部分內(nèi)存換出到硬盤，由于內(nèi)存與硬盤讀寫速度差幾個數(shù)量級我磁，會導致發(fā)生交換后的Redis性能急劇下降孽文。
預防內(nèi)存交換：
保證機器充足的可用內(nèi)存。
確保所有Redis實例設(shè)置最大可用內(nèi)存（maxmemory）夺艰，防止極端情況下Redis內(nèi)存不可控的增長芋哭。
降低系統(tǒng)使用swap優(yōu)先級。
3.3 網(wǎng)絡(luò)問題
（1）連接拒絕
網(wǎng)絡(luò)閃斷（網(wǎng)絡(luò)割接或者帶寬耗盡）
Redis連接拒絕（超過客戶端最大連接數(shù)）
連接溢出（進程限制或backlog隊列溢出）
（2）網(wǎng)絡(luò)延遲
網(wǎng)絡(luò)延遲取決于客戶端到Redis服務器之間的網(wǎng)絡(luò)環(huán)境郁副。主要包括它們之間的物理拓撲和帶寬占用情況减牺。常見的物理拓撲按網(wǎng)絡(luò)延遲由快到慢可分為：同物理機>同機架>跨機架>同機房>同城機房>異地機房。但它們?nèi)轂男哉孟喾创婊眩锢頇C容災性最低而異地機房容災性最高拔疚。
網(wǎng)絡(luò)延遲問題經(jīng)常出現(xiàn)在跨機房的部署結(jié)構(gòu)上，對于機房之間延遲比較嚴重的場景需要調(diào)整拓撲結(jié)構(gòu)既荚，如把客戶端和Redis部署在同機房或同城機房等稚失。
帶寬瓶頸通常出現(xiàn)在以下幾個方面：
機器網(wǎng)卡帶寬。
機架交換機帶寬固以。
機房之間專線帶寬墩虹。
（3）網(wǎng)卡軟中斷
網(wǎng)卡軟中斷是指由于單個網(wǎng)卡隊列只能使用一個CPU嘱巾，高并發(fā)下網(wǎng)卡數(shù)據(jù)交互都集中在同一個CPU，導致無法充分利用多核CPU的情況诫钓。網(wǎng)卡軟中斷瓶頸一般出現(xiàn)在網(wǎng)絡(luò)高流量吞吐的場景旬昭。
歡迎工作一到五年的Java工程師朋友們加入Java架構(gòu)開發(fā)： 855835163
群內(nèi)提供免費的Java架構(gòu)學習資料（里面有高可用、高并發(fā)菌湃、高性能及分布式问拘、Jvm性能調(diào)優(yōu)、Spring源碼惧所，MyBatis骤坐，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構(gòu)資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰下愈！趁年輕纽绍，使勁拼，給未來的自己一個交代势似！
