【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保存的现场，果然有发现

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

这里仅可以看到业务相关机器不断对改值进行HGETALL操作，这个真心是要么一个60M的文件，业务的每个机器，每次操作都需要来HGETALL一次，这样不高流量才怪，如果再加上某个固定时段需要对redis数据进行大量更新操作，好吧，真是撒由那拉了。

---

分析到这里，其实问题基本就定位到了，剩下就是开发进行代码的修改工作。当然，如果redis不是该原因导致的，那可能还需要进行继续分析，比如某个定时任务会导致redis大量数据过期重拉等等，这里就不继续展开