【redis】忽然流量增大，不定時掛死排障記錄

問題1：忽然發現一臺redis老是有很大流量，下面是iftop的截圖

能夠發現服務器拖取redis的流量很是大，並且持續一段時間的觀察發現，多個業務均在不斷向redis拖數據。

 

問題2：分析redis日誌，發現下面日誌信息

分析：能夠看到，基本每分鐘都會有觸發aof的10000更改策略保存大概100-180M的數據。

          那麼能夠先假設，致使上面流量高的那部分數據有多是這部分100多M的數據

 

問題點預判斷：

1. 生產代碼存在定時任務，不斷拉取redis數據到本地tomcat
2. redis的key存在同時失效時間，致使大量數據重作
3. redis存在某個或多個key值比較大，並且生產代碼可能需頻繁讀取改key

 

---

如今開始藉助工具來分析問題

首先redis自帶的實時操做monitor工具，收集當前的記錄，方便後面分析，最好在故障發生時記錄，發個記錄10到20分鐘就能夠，執行的方式以下:

 

 ./redis-cli  -a 123456  monitor  > redis.op

 

執行後的結果相似:

1505804924.216244 [3 192.168.3.106:10869] "GET" "httpMonitorOpen"
1505804924.218571 [3 192.168.3.94:19622] "HINCRBY" "INTERFACE_CALL_STATISTICS" "findNewVersion" "1"
1505804924.225301 [3 192.168.2.75:26934] "HINCRBY" "INTERFACE_CALL_STATISTICS" "findNewVersion" "1"
1505804924.228036 [3 192.168.2.75:26934] "HINCRBY" "INTERFACE_CALL_STATISTICS" "getAdvertising" "1"
1505804924.232041 [3 192.168.2.72:15504] "HINCRBY" "INTERFACE_CALL_STATISTICS" "findNewVersion" "1"
1505804924.233962 [0 192.168.2.59:21545] "SELECT" "3"

 

 這是保留現場，方便後面分析

 

---

 

藉助很是優秀的redis工具 rdbtools  。rdbtools支持更具redis的dump文件分析庫內容，支持將dump文件導出成json，也能夠直接執行命令查詢，指定key操做等

#安裝
$]pip install rdbtools

#導出成json，方便後面查看key內容
$]rdb --command json /var/redis/6379/dump.rdb  > dump.json

#生成數據庫信息統計
 $]rdb -c memory /var/redis/6379/dump.rdb --bytes 128 -f memory.csv
database,type,key,size_in_bytes,encoding,num_elements,len_largest_element
0,list,lizards,241,quicklist,5,19
0,list,user_list,190,quicklist,3,7
2,hash,baloon,138,ziplist,3,11
2,list,armadillo,231,quicklist,5,20
2,hash,aroma,129,ziplist,3,11

 

如今咱們已經有reids的如今操做記錄文件redis.op, redis庫的json文件dump.json, redis的統計文件 memory.csv。基本須要收集的信息就是這些，如今能夠開始來着手定位問題

1 查看是否存在較大的key，記住上面的格式

#排下序
awk -F',' '{print $4,$2,$3,$1}' memory.csv |sort -nk 1  > memory.sort

#查看最大的10個值
tail -n 10 memory.sort


#這裏應爲隱私緣由，我替換掉實際的key值，用test_key的方式替換
6160772 hash test_key1 3
6567948 hash test_key2 3
6618436 hash test_key3 3
7509356 hash test_key4 3
8638724 hash test_key5 3
8663844 hash test_key5 3
8834628 hash test_key6 3
9548508 hash test_key7 3
12023460 hash test_key8 3
59678852 hash test_key9 3

這裏看到一個居然有一個key是僅60M，還有一個12M,其它的也有很多是1M-9M，那高流量極可能是這個業務不斷從redis拖改key值致使，試試搜索下剛剛的monitor保存的現場，果真有發現

1 $]  grep test_key9  redis.key
2 1505789777.260422 [3 192.168.2.75:20441] "HSET" "test_key9" "00000000-346b-21fe-ffff-ffff8e4beed7_20175619105616" "android"
3 1505789795.531559 [3 192.168.2.77:39985] "HGETALL" "test_key9"
4 1505789796.009790 [3 192.168.3.94:15590] "HGETALL" "test_key9"
5 1505789796.988040 [3 192.168.3.95:11666] "HGETALL" "test_key9"
6 1505789797.433473 [3 192.168.3.94:15590] "HSET" "test_key9" "ffffffff-884b-f441-f220-e1c8337f5b3c_20175619105635" "android"
7 1505789798.086985 [3 192.168.3.95:11666] "HSET" "test_key9" "ffffffff-c886-7e4b-ffff-ffffec4a4ecc_20175619105636" "android"
8 1505789798.216923 [3 192.168.2.77:39985] "HSET" "test_key9" "00000000-048f-fa93-b50c-95a5184dbf49_20175619105635" "android"
.......

這裏僅能夠看到業務相關機器不斷對改值進行HGETALL操做，這個真心是要麼一個60M的文件，業務的每一個機器，每次操做都須要來HGETALL一次，這樣不高流量纔怪，若是再加上某個固定時段須要對redis數據進行大量更新操做，好吧，真是撒由那拉了。

 

---

 

分析到這裏，其實問題基本就定位到了，剩下就是開發進行代碼的修改工做。固然，若是redis不是該緣由致使的，那可能還須要進行繼續分析，好比某個定時任務會致使redis大量數據過時重拉等等，這裏就不繼續展開