redis big key分析及shell删除（redis的删除命令）

目前coids 8个master节点8个slave节点，把两台机器600G的内存吃完了，有点夸张。业务上的人只管用，并没有过多关注redis的健康状况，经过分析后发现有很多的垃圾数据。

1、153上 节点6379 - 6386上每个几点大约有1300 - 1400W个key。

?

也可以通过redis desktop manager 连接单节点来查看。

?

可以看到这些key的数量是动态变化的。是因为有的key设定了过期时间代表它已经过期了，关于设定了expire的key何时释放空间？这篇文章中 内存溢出控制策略 有详细阐述。

2、查找big key，redis 提供了一个bigkeys的命令。

得到的结果不一定准确，是因为其统计key的数据规模并不是占用内存最大的key。

bigkeys的原理，非常简单，通过scan命令遍历，各种不同数据结构的key，分别通过不同的命令得到最大的key：

• 如果是string结构，通过strlen判断；
• 如果是list结构，通过llen判断；
• 如果是hash结构，通过hlen判断；
• 如果是set结构，通过scard判断；
• 如果是sorted set结构，通过zcard判断。

redis-cli  -p 6380 --bigkeys

[root@P1QMSPL2RTM01 ~]# redis-cli  -p 6380 --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
......
-------- summary -------

Sampled 13788262 keys in the keyspace!
Total key length in bytes is 376277646 (avg len 27.29)

Biggest string found 'RPT_20200327044033141' has 15102 bytes
Biggest   list found 'opehis:A196E06WBE' has 1058 items
Biggest   hash found 'HMS:ERROR:HMS_ERROR2' has 2393 fields
Biggest   zset found 'history:L6400' has 4736943 members

12788812 strings with 367806347 bytes (92.75% of keys, avg size 28.76)
915321 lists with 8590020 items (06.64% of keys, avg size 9.38)
0 sets with 0 members (00.00% of keys, avg size 0.00)
4397 hashs with 30777 fields (00.03% of keys, avg size 7.00)
79732 zsets with 98114217 members (00.58% of keys, avg size 1230.55)

#!/bin/bash
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6379 -i 0.1 --bigkeys >/home/scripts/6379_153.log
#sleep 40m
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6380 -i 0.1 --bigkeys >/home/scripts/6380_153.log
#sleep 40m
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6381 -i 0.1 --bigkeys >/home/scripts/6381_153.log
#sleep 40m
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6382 -i 0.1 --bigkeys >/home/scripts/6382_153.log
#sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6383 -i 0.1 --bigkeys >/home/scripts/6383_153.log
sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6384 -i 0.1 --bigkeys >/home/scripts/6384_153.log
sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6385 -i 0.1 --bigkeys >/home/scripts/6385_153.log
sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6386 -i 0.1 --bigkeys >/home/scripts/6386_153.log

事实上并不用在master上做这个操作，因为master和slave上的数据是同步的，在master上执行此命令可能会严重阻塞client的写命令，尽管使用了-i 0.1 这个参数。

尽管是统计某个key的数据规模，但是看到这些数据有点夸张，有的key竟然还是19年6月的甚至更早，history:L6400 竟然能有470W个value，而这仅仅是一个站点的数据。

事实上，是有一只删除redis 旧key的程序，可是通过分析其逻辑是典型的顾头不顾尾。那当务之急就是为何释放redis的内存，因为redis服务器的内存使用率一直高达99%。

删除当然是找数据最多的，这个key是 zset类型。用了几个小时学习了sorted set的基本使用方法。

删除的逻辑大致是：遍历站点list，拼凑history:ope这个key，然后用zremrangebyscore删除，score根据实际业务来决定。

删除脚本如下

#!/bin/bash
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli  -p 6379 -i 0.1 --bigkeys >/home/scripts/6379_153.log
#redis-cli -p 6385 zscan history:L7100 0  match '*:*:*:*:*:**M' count 10000 >history_ope.log
#redis-cli -p 6385 zrangebyscore history:L7100 -inf +inf WITHSCORES > history_L7100.log
#sleep 5s

#2017-01-01 00:00:00 ->
#fromTime='1483200000'
#2018-12-31 23:59:59 ->
#toTime='1546271999'

#2018-12-31 23:59:59 ->
fromTime='1546271999'
#2019/08/31 23:59:59 
toTime='1567267199'

logname='del_19_1-8.log'
bkname='del_19_1-8.bk'

TIME=$(date '+%Y%m%d%H%M%S')
count=0
#path='/home/scripts/test/opeList.txt'
path='/home/scripts/test/delete/opeList.txt'
while read -r ope
 do
#for ope in $(cat ${path})  //在执行删除的时候遇到过效能问题，例如删除result:glass这个key的时候每次读取5-7W行数据然后进行后面的逻辑发现需要2300s,如果减少数据量到2W速度能到100s，这个差距由点大，用for循环每次读一行比从while缓存中读快吗?  改天测试一下
#do
var1=$(/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 19000 zrangebyscore history:${ope} $fromTime $toTime|wc -l)

# zcard 统计数量可考虑使用该命令计算
#count=$($[count] + $[var1])
count=`expr $count + $var1`
#echo $var1

/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 19000 zremrangebyscore history:${ope} $fromTime $toTime

sleep 1s


echo "$TIME /usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 19000 zremrangebyscore history:${ope} $fromTime $toTime " >> /home/scripts/test/delete/$bkname

echo "$TIME ope: $ope,delQty: $var1 " >> /home/scripts/test/delete/$logname
#test
#redis-cli -p 6385 zscan history:${ope} 0  match '*:*:*:*:*:**M' count 1000 > history_6383_${ope}.log
#done
done < opeList.txt
echo "totalQty: $count" >> /home/scripts/test/delete/$logname

删除数据量统计

这总算是解了燃眉之急，至少redis能撑2-5天。毕竟不是长久之计。

内存使用一个脚本估算出来的：

精确评估 history:ope 的大小

概述：在测试环境，将history:ope zadd 10000笔， 打印前后的内存变化，同时根据模型计算，比较两者的差距。
Shell 脚本如下

#!/bin/sh
key="history:A3850"
old_memory=`/usr/local/bin/redis-cli -h 0 -p 6380 info|grep used_memory:|awk -F: '{printf "%d", $2}'`
echo "before test, memory used: $old_memory"
#for((i=100; i<900; i++))
#do
for((j=1483200000; j<1483210000; j++))
do
/usr/local/bin/redis-cli -h 0 -p 6380 zadd $key $j AOIH0200:AOIH0200:A3850E495A1:A1495A1ANK1:A183A00VN01:$j:M > /dev/null
done
sleep 0.5
#done
new_memory=`/usr/local/bin/redis-cli -h 0 -p 6380 info|grep used_memory:|awk -F: '{printf "%d", $2}'`
echo "after test, memory used: $new_memory"
let difference=new_memory-old_memory
echo "difference is: $difference"

[root@gptest01 redis]# ./evaluateHisOpeMem.sh 
before test, memory used: 415131248
after test, memory used: 417395400
difference is: 2264152

一个key的写入10000笔数据，需要占用2.16MB
故4000W的value规模可以释放8.5GB的数据

前期用模型估算出来的大小为7G左右。

Value 长度 67byte
共7段
平均每段 = (8 + 8 + 11 + 11 + 11 + 10 + 1)/7 = 8.58byte≈9byte

?

参考：

https://www.jianshu.com/p/5c5dc0d7d776
http://doc.redisfans.com/index.html

3、利用rdb tool来讲dump导出写入mysql 通过下sql 的方式查redis数据。

rdb -c memory -l 5 dump.rdb

找出前5大key。

[root@P1QMSPL2RTM01 redis]# rdb -c memory -l 5 dump.rdb 
database,type,key,size_in_bytes,encoding,num_elements,len_largest_element,expiry
WARNING: python-lzf package NOT detected. Parsing dump file will be very slow unless you install it. To install, run the following command:

pip install python-lzf

后来运维人员装好了rdb tool，经过分析原来result:glassId才是终极大boss。

至此，才算真正意义上找到了”bigkeys”，这才是占用reids最大的内存了。

在处理这次事故中，发现目前架构是主从读写分离的架构，在重放slave的aof文件时发生了瞬时读取不到key的情况，着实让人操心。关于此请参照我写的另外一篇。

-------------update 2020年4月26日08:44:45 -----------------------

还有一点是非常奇怪的现象：

旧的数据清理完了之后发现一个奇怪的现象，6385节点的内存交其他节点多10GB，这是很奇怪的，通过codis-proxy写入key时会根据冗余校验算法分配到每一个slot上，理论上来说数据倾斜不会这么严重。

?

对该节点重新做了bgsave ，分析dump之后，发现更奇怪的事情， 某些过期数据残存在6385上，透过proxy竟然访问不到，这是为何呢？？？

[root@P1PL2RTM01 redis]# redis-cli -p 19000 zrange result:A18BR04NAY 0 -1
(empty list or set)
You have new mail in /var/spool/mail/root
[root@P1PL2RTM01 redis]# redis-cli -p 6385 zrange result:A18BR04NAY 0 -1
1) "{\"actualEqptId\":\"MSPU0200\",\"defectCnt\":0,\"glassId\":\"A18BR04NAY\",\"ifPreProcess\":true,\"ooc\":false,\"oos\":false,\"panelCnt\":8,\"processEndTime\":1543355980,\"ruleSeqId\":3277}"
2) "{\"actualEqptId\":\"MSPU0200\",\"defectCnt\":2,\"glassId\":\"A18BR04NAY\",\"ifPreProcess\":true,\"ooc\":false,\"oos\":false,\"panelCnt\":8,\"processEndTime\":1543355980,\"ruleSeqId\":3298}"

针对目前的怪现象：

codisproxy把某个key写在哪个slot了？这些信息会记录在zk吗？client现在想读刚才写入的数据 应该从哪个slot读呢？

是不是可以从这几个方面入手呢？

更详尽的内容请参考：

https://redis.io/topics/rediscli#scanning-for-big-keys

源代码分析

https://blog.csdn.net/aoerqileng/article/details/86687499

?