（關注“資料庫架構師”公衆号，提升資料庫技能，助力職業發展）
Redis作為核心緩存服務，目前已經成為網際網路公司的标配。目前我們維護的Redis叢集規模：每日總請求超過10000億次，Redis節點超過10000個，伺服器500台，覆寫全部業務線，支援了包括資料緩存、消息隊列、分布式鎖等各種核心應用場景，應用的服務也越來越重要。作為DBA，運維了這麼久Redis，發現我們不少開發人員在使用Redis時，對于一些非常核心的監控名額缺乏了解，特整理如下，希望給大家帶來幫助。
1.通路QPS統計
名額解讀：
QPS反應了每秒Redis處理的指令數。如果這個名額有較大波動或者或預期不一緻需要警惕。運維中我們發現不少應用程式架構每次發送指令時會先發一個ping探活，導緻QPS值翻倍，建議關閉。
2.執行指令統計
名額解讀：
該名額展示了目前Redis節點最近一周時間通路最多的指令Top5統計。因為每套叢集存儲的資料結構類型不同，使用的通路指令也不同，是以這裡大家會發現不同的叢集指令不同。
3.命中率統計
名額解讀：
該名額展示了目前Redis節點每秒請求指令的命中情況，對于用于緩存服務的場景參考意義很大。如果自己的應用高度依賴緩存，那麼如果出現業務響應時間變長時，要優先關注這個名額的波動情況。
4.Key數量監控
名額解讀：
該名額展示了目前Redis節點Key數量的變化情況，如果記憶體波動厲害，建議優先關注這個參數值的變化。注意：這裡也統計了過期Key數量的變化，對于緩存的應用，建議都要合理設定過期時間。
5.記憶體使用統計
名額解讀：
Redis應用非常重要的名額，一般記憶體使用上限不要超過30G，在使用率超過90%時，會有報警提示。記憶體使用主要有兩個名額：實際使用記憶體和資料記憶體。
- 實際使用記憶體：作業系統配置設定給Redis執行個體的記憶體大小，表示該程序所占實體記憶體的大小。另外這個名額還包含了記憶體碎片的開銷，記憶體碎片是由作業系統低效的配置設定/回收實體記憶體導緻的
- 資料記憶體：就是實際資料占用的記憶體大小
- 碎片率：實際使用記憶體/資料記憶體 , 碎片率不宜過大，否則會影響請求的響應時間
6.連接配接數統計
名額解讀：
Redis内處理請求的連接配接數，上限為10000.正常的應用請求連接配接數應該比較平穩，如果出現忽高忽低現象，需要警惕是否有指令阻塞或者網絡異常情況。另外應用側jedis連接配接池的預設連接配接數最大為8個，如果通路量較大一定要記得調大該值。
7.網絡流量統計
名額解讀：
Redis請求的網絡流量進和出的統計。早期不少redis部署在千兆伺服器上，如果業務請求的Key-Value過大或者使用了hgetall等批量擷取的指令，很容易會将網卡打爆。如果發現自己業務響應時間時高時低甚至請求錯誤，也記得要關注該名額。
8.CPU負載
名額解讀：
該名額包含兩項，user 指的是指令在使用者态（User Mode）所消耗的CPU時間
sys指的是指令在核心态（Kernel Mode）所消耗的CPU時間。如果兩者之和超過75，說明CPU比較繁忙了，需要警惕是不是通路的QPS特别高或者有慢操作的指令。因為Redis單線程架構，如果達到100，就說明CPU滿負荷運作，會影響請求的處理響應時間。
如果這篇文章對你有幫助，還請幫忙點贊、轉發 以下，你的支援會激勵我們輸出更多高品質的文章！
如果你還想看更多優質文章，歡迎關注我的公衆号「資料庫架構師」，提升資料庫技能，助力職業發展。