問題1：突然發現一台redis總是有很大流量，下面是iftop的截圖
可以發現服務器拖取redis的流量非常大，而且持續一段時間的觀察發現，多個業務均在不斷向redis拖數據。
問題2：分析redis日志，發現下面日志信息
分析：可以看到，基本每分鍾都會有觸發aof的10000更改策略保存大概100-180M的數據。
那么可以先假設，導致上面流量高的那部分數據有可能是這部分100多M的數據
問題點預判斷：
- 生產代碼存在定時任務，不斷拉取redis數據到本地tomcat
- redis的key存在同時失效時間，導致大量數據重做
- 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大量數據過期重拉等等，這里就不繼續展開