redis是典型的單執行緒架構，所有的讀寫操作都是在一條主線程中完成的。當redis用於高併發場景時，這條執行緒就變成了它的生命線。如果出現阻塞，哪怕是很短時間，對於應用來說都是噩夢。
導致阻塞問題的原因：
通常redis執行命令速度非常快，但是，如果對乙個包含上萬個元素的hash結構執行hgetall操作，由於資料量比較大且命令演算法複雜度是o(n)，這條命令執行速度必然很慢。
對於高併發的場景應該盡量避免在大物件上執行演算法複雜度超過o(n)的命令。
（1）如何發現慢查詢
redis原生提供慢查詢統計功能，執行slowlog get命令可以獲取最近的n條慢查詢命令，預設對於執行超過10毫秒的命令都會記錄到乙個定長佇列中，線上例項建議設定為1毫秒便於及時發現毫秒級以上的命令。
（2）發現慢查詢後如何調整
（3）如何發現大物件
redis本身提供發現大物件的工具。具體命令：
redis-cli -h -p --bigkeys單執行緒的redis處理命令時只能使用乙個cpu。而cpu飽和是指redis把單核cpu使用率跑到接近100%。使用top命令很容易識別出對應redis程序的cpu使用率。cpu飽和是非常危險的，將導致redis無法處理更多的命令，嚴重影響吞吐量和應用方的穩定性。對於這種情況，首先判斷當前redis的併發量是否達到極限，建議使用統計命令redis-cli -h -p --stat獲取當前redis使用情況
對於開啟了持久化功能的redis節點，需要排查是否是持久化導致的阻塞。
記憶體交換（swap）對於redis來說是非常致命的，redis保證高效能的乙個重要前提是所有的資料在記憶體中。如果作業系統把redis使用的部分記憶體換出到硬碟，由於記憶體與硬碟讀寫速度差幾個數量級，會導致發生交換後的redis效能急劇下降。
預防記憶體交換：
（1）連線拒絕
（2）網路延遲
網路延遲取決於客戶端到redis伺服器之間的網路環境。主要包括它們之間的物理拓撲和頻寬占用情況。常見的物理拓撲按網路延遲由快到慢可分為：同物理機》同機架》跨機架》同機房》同城機房》異地機房。但它們容災性正好相反，同物理機容災性最低而異地機房容災性最高。
網路延遲問題經常出現在跨機房的部署結構上，對於機房之間延遲比較嚴重的場景需要調整拓撲結構，如把客戶端和redis部署在同機房或同城機房等。
頻寬瓶頸通常出現在以下幾個方面：
（3）網絡卡軟中斷
網絡卡軟中斷是指由於單個網絡卡佇列只能使用乙個cpu，高併發下網絡卡資料互動都集中在同乙個cpu，導致無法充分利用多核cpu的情況。網絡卡軟中斷瓶頸一般出現在網路高流量吞吐的場景。
《Redis開發與運維》筆記 初識Redis
目錄 redis優點 redis特性 速度快基於鍵值對的資料結構伺服器 豐富的功能 簡單穩定 客戶端語言多 持久化主從複製 高可用和分布式 redis使用場景 redis可以做什麼 redis不可以做什麼 用好redis的建議 切勿當作黑盒使用，開發與運維同樣重要 閱讀原始碼 redis重大版本 r...
《Redis開發與運維》筆記 發布與訂閱
redis提供了基於 發布 訂閱 模式的訊息機制。訊息發布者與訂閱者不直接通訊，發布者客戶端向指定的頻道 channel 發布訊息，訂閱該頻道的每個客戶端都可以接收到資訊。發布訊息 publish channel message 示例 向 channel layne 通道發布一條 hello wor...
redis 開發與運維 1
由於手上負責的專案很依賴redis，而且redis曾經出過問題，故決定好好系統學習一下redis的知識，本文打算先介紹一下redis的基礎知識 首先我們必須明確的幾個知識點1 1 keys 這個命令可以檢視所有的鍵,這是這個 當前db所有的key 127.0 0.1 6379 keys 1 haha...