零
一 觀察指標
1 cpu 效能監控圖 關注 user 和system的使用率
2 network 效能監控圖
出口流量1 可能存在大key或者高併發查詢(get)
2 可能存在rdb快照/增量命令傳輸 ,新搭建的從庫或者主從切換導致
進口流量 1 代表可能存在高併發寫入(set)
3 iops 效能監控圖
備份機制導致 頻繁的aof操作和間隔性的rdb操作都可能導致io公升高
4 記憶體效能監控圖
redis本身內存在配置檔案中有定製 ,如果超過了報警的閾值就需要減少key的量或者給伺服器記憶體擴容
5 key相關
1 hits/misses key的命中問題,如果大量沒有命中,會導致快取穿透
2 expiring/not-expiring key key的失效問題,如果過期的值瞬間公升高,會導致快取失效
3 command-calls 各種操作型別的統計,排查哪個動作耗費的cpu過高
4 clients 總的連線數大小統計,排查現在整體的連線水平
5 evicted_keys 由於 maxmemory 限制，而被**記憶體的 key 的總數 被**的key
6 qps
1 常見查詢操作
字串型別->get
hash型別 hget 單個(select one)
hmget 多個(select manay)
hgetall 所有(select all)
list型別 lrange key start stop select manay
lindex key index select one
2 常見寫入操作
字串型別-> set setnx(setnx 是『set if not exists』(如果不存在,則 set)的簡寫)
hash型別->hset(如果雜湊表不存在，乙個新的雜湊表被建立並進行 hset 操作。如果字段已經存在於雜湊表中，舊值將被覆蓋)
集合 ->sadd 多個元素寫入集合
列表->lpop lset
3 常見刪除操作
刪除型別->del
4 通用操作 1 確認value是否存在 exits 有些程式是先exists確定key是否存在 再進行訪問,所以有可能出現exists統計量很高的情況
2 檢視key型別 type 系統
3 健康檢測 ping 系統
4 設定過期時間 expire 程式 主動設定過期時間,但是頻率不高
5 配置檔案 config 系統
6 整體檢視 info 系統
5 排序聚合操作
6 總結效能操作問題
1 平常的查詢 類get操作 針對 big key hot key
2 特殊查詢 聚合 排序等操作
3 平常寫入 大的string等 big key
4 頻繁寫入 set hset等
二 redis引數
1 maxclients 最大連線數
redis-cli -p port client list|grep -evi "name=sentinel-|addr=127.0.0.1"|awk -f'=|:' ''|sort -n|uniq -c|sort -nr 分組統計連線數
redis-cli -p port info|grep list 統計總連線數
2 maxmemory 最大記憶體
根據監控圖-記憶體 進行分析資料記憶體占用
3 慢日誌 slowlog get n
三 具體問題分析
1 redis連線超時
可能原因
1 到達了redis設定的maxclients數量
2 程式本身redis配置有問題
3 redis本身服務不可用
4 redis本身服務處於高負載狀態,導致阻塞無法處理新的連線
2 排查手段
redis-cli -h -p --latency 延時測試
redis-cli -h -p --latency-history 延時取樣測試 15s 一次
redis-cli -h -p --intrinsic-latency 60 響應延時
2 redis key不淘汰的問題
現象: redis key 的記憶體占用一直公升高，預設設定了淘汰策略沒有起作用
可能原因
1 由於人為或者程式更改了淘汰策略,進行手動檢視 redis info|grep maxmemory_policy,進行對比即可,我們線上用的是allkeys-lru(allkeys-lru: 所有key通用; 優先刪除最近最少使用(less recently used ,lru) 的 key) 這也是3.0以上版本預設的淘汰機制
3 出口流量問題
1 通過 iftop -i eth0 -nnb -m 10m 過濾出出口流量大於10m的應用ip,確定具體應用服務
2 獲取pmm監控資料
1 總的命令數是否有異常
2 具體的命令排行 要著重觀察get hgetall
3 觀察慢日誌的異常操作
slowlog get num
4 分析server.log是否有異常
5 記憶體碎片問題
定義1 相關指標 mem_fragmentation_ratio 計算方式 redis向作業系統申請的記憶體/redis資料在記憶體的占用比例 可以這樣理解 相差不要太多兩者.大於或者小於太多都不合適
2 對於記憶體碎片率，一般保持在 1~1.5 之間是最合理的。 如果大於1.5 就代表超過50%的碎片產生,需要清理 如果小於1 代表需要進行擴容記憶體
3 redis 中，最常用的是寫入、修改、刪除資料。這些操作在執行後都會產生 一定程度的記憶體碎片
解決1 重啟redis服務,重新讀取rdb資料檔案
2 redis 中有專門的引數設定用來進行自動清理記憶體碎片：activedefrag yes 適用於版本大於4.0的方式
active-defrag-ignore-bytes 100mb：
碎片達到100mb時，開啟清理。
active-defrag-threshold-lower 10：
當碎片超過 10% 時，開啟清理。
active-defrag-threshold-upper 100：
記憶體碎片超過 100%，盡最大清理。mb
active-defrag-cycle-min 5：
清理記憶體碎片占用 cpu 時間的比例不低於此值，保證清理能正常開展。
active-defrag-cycle-max 75：
清理記憶體碎片占用 cpu 時間的比例不高於此值。一旦超過則停止清理，從而避免在清理時，大量的記憶體拷貝阻塞 redis，導致其它請求延遲。
五 基礎
單執行緒1 多路復用和非阻塞 i/o：redis 使用 i/o 多路復用功能來使用多執行緒監聽多個 socket 連線客戶端，這樣就可以使用乙個執行緒連線來處理多個請求，減少執行緒切換帶來的開銷，同時也避免了 i/o 阻塞操作，從而大大提高了 redis 的效能；
比如當 socket 中有資料時，redis 會通過呼叫先將資料從核心態空間拷貝到使用者態空間，再交給 redis 呼叫，而這個拷貝的過程就是阻塞的，當資料量越大時拷貝所需要的時間就越多，而這些操作都是基於單執行緒完成的。
2 避免上下文切換：因為是單執行緒模型，因此就避免了不必要的上下文切換和多執行緒競爭，這就省去了多執行緒切換帶來的時間和效能上的消耗，而且單執行緒不會導致死鎖問題的發生。
3 記憶體操作而並非硬碟 資料結構簡單
4 多執行緒改進
1 4.0 多執行緒對於大key和清理全量key的非同步操作 利用多執行緒(屬於不常用的後台操作)
2 6.0 多執行緒對於讀寫的多執行緒提供 將 i/o 讀寫變成了多執行緒，而命令的執行依舊是由主線程序列執行的，因此在多執行緒下操作 redis 不會出現執行緒安全的問題
5 總結
1 6.0 處理請求(多執行緒)-> io讀寫(多執行緒)->命令執行(單執行緒)
2 在redis的多執行緒模式下，獲取、解析命令，以及輸出結果著兩個過程，可以配置成多執行緒執行的，因為它畢竟是我們定位到的主要耗時點 但是大部分命令執行都是單執行緒 針對使用者請求
六 補充
1 redis的rdb備份屬於冷檔案 可以實時進行拷貝
2 耗時相關
redis相關耗時總結
1 傳送命令網路傳輸時間(網路穩定性)->命令在redis服務端佇列中等待的時間(佇列等待,因為是序列)，命令執行的時間（redis中的slowlog檢測命令執行時間），結果返回的redis客戶端的時間(結果檢測集的大小)。
\
Redis 基礎篇（一）
今天我們來講一講快取 目前，memcache 和 redis 是網際網路分層架構中，最常用的 key value 快取。那麼如何選擇呢 下面來看一下兩種快取的比較 redis mecache 吞吐量十萬左右 qps 達到幾十萬 qps 資料結構 支援多種資料結構，如雜湊，列表，集合，有序集合這類複雜...
初探Redis 基礎篇
作為向web而生的redis，現已經使用得十分廣泛了。依靠其高效能 簡潔設計等深受開發者們喜歡。對redis從基礎學起，抱著知其然到知其所以然的想法，先學會怎麼用，再去深入了解內部運轉。redis官網 redis英文全稱為remote dictionary server，採用c語言開發的開源，基於記...
效能測試總結 基礎篇
隨著服務群體 服務規模的與日俱增，我們面對的應用場景 業務規則 資料規則也越來越多樣化 複雜化，為了應對這種日益增長的變化以更好的滿足客戶需求，各類新方法 新技術也應運而生，並以此構建了大量的新產品。在這樣的背景下，如何實現專案有效 高效的交付，如何為我們的客戶提供便捷 高效 穩定產品服務？面對這些...