【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大量数据过时重拉等等，这里就不继续展开