阿里云的redis规范( 三 ) _redis

建议在节点本机执行，这样可以减少网络开销。

如果没有从节点，可以使用--i参数，例如(--i 0.1 代表100毫秒执行一次)

--bigkeys只能计算每种数据结构的top1，如果有些数据结构非常多的bigkey，也搞不定，毕竟不是自己写的东西嘛

debug object

再来看一个场景：
你好，麻烦帮我查一下Redis里大于10KB的所有key
您好，帮忙查一下Redis中长度大于5000的hash key
是不是发现用--bigkeys不行了（当然如果改源码也不是太难），但有没有更快捷的方法，Redis提供了debug object ${key}命令获取键值的相关信息：
127.0.0.1:6379> hlen big:hash(integer) 5000000127.0.0.1:6379> debug object big:hashValue at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625559 lru_seconds_idle:2(1.08s)其中serializedlength表示key对应的value序列化之后的字节数，当然如果是字符串类型，完全看可以执行strlen，例如：
127.0.0.1:6379> strlen key(integer) 947394这样你就可以用scan + debug object的方式遍历Redis所有的键值，找到你需要阈值的数据了。
但是在使用debug object时候一定要注意以下几点：
(1) debug object bigkey本身可能就会比较慢，它本身就会存在阻塞Redis的可能
(2) 建议在从节点执行
(3) 建议在节点本地执行
(4) 如果不关系具体字节数，完全可以使用scan + strlen|hlen|llen|scard|zcard替代，他们都是o(1)
3 memory usage
上面的debug object可能会比较危险、而且不太准确（序列化后的长度），有没有更准确的呢？Redis 4.0开始提供memory usage命令可以计算每个键值的字节数（自身、以及相关指针开销，具体的细节后面有文章会分析），例如下面是一次执行结果：
127.0.0.1:6379> memory usage big:hash(integer) 318663444下面我们来对比就可以看出来，当前系统就一个key，总内存消耗是400MB左右，memory usage相比debug object还是要精确一些的。
127.0.0.1:6379> dbsize(integer) 1127.0.0.1:6379> hlen big:hash(integer) 5000000#约300MB127.0.0.1:6379> memory usage big:hash(integer) 318663444#约85MB127.0.0.1:6379> debug object big:hashValue at:0x7fda95b0cb20 refcount:1 encoding:hashtable serializedlength:87777785 lru:9625814 lru_seconds_idle:9(1.06s)127.0.0.1:6379> info memory# Memoryused_memory_human:402.16M如果你使用Redis 4.0+，你就可以用scan + memory usage(pipeline)了，而且很好的一点是,memory不会执行很慢，当然依然是建议从节点 + 本地。
4.客户端
上面三种方式都有一个问题，就是马后炮，如果想很实时的找到bigkey，一方面你可以试试修改Redis源码，还有一种方式就是可以修改客户端，以jedis为例，可以在关键的出入口加上对应的检测机制，例如以Jedis的获取结果为例子：
protected Object readProtocolWithCheckingBroken() { Object o = null; try {o = Protocol.read(inputStream);return o; }catch(JedisConnectionException exc) {UsefulDataCollector.collectException(exc, getHostPort(), System.currentTimeMillis());broken = true;throw exc; }finally {if(o != null) {if(o instanceof byte[]) {byte[] bytes = (byte[]) o;if (bytes.length > threshold) {// 做很多事情，例如用ELK完成收集和展示}}} }}5.监控报警
bigkey的大操作，通常会引起客户端输入或者输出缓冲区的异常，Redis提供了info clients里面包含的客户端输入缓冲区的字节数以及输出缓冲区的队列长度，可以重点关注下：
127.0.0.1:6379> info clientsclient_longest_output_list:xxxxxclient_biggest_input_buf:xxxxx如果想知道具体的客户端，可以使用client list命令来查找
redis-cli client listid=3 addr=127.0.0.1:58500 fd=8 name= age=3978 idle=25 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=26263554 events=r cmd=hgetall6.改源码
这个其实也是能做的，但是各方面成本比较高，对于一般公司来说不适用。
我个人的最佳实践就是：
(1) Redis端与客户端相结合：--bigkeys临时用、scan长期做排除隐患（尽可能本地化）、客户端实时监控。
(2) 监控报警要跟上
(3) debug object尽量少用
(4) 所有数据平台化
(5) 要和开发同学强调bigkey的危害
五、如何删除
如果发现了bigkey，而且确认是垃圾是不是直接del就可以了，来看一组数据：