业务节点将缓存 or 持久化数据写入Redis之后，在多数DBA or DBA DevOps的工作场景中，不可避免的要涉及Redis缓存分析，其主要包含大Key和热key的分析。
基于redis-cli的bigkeys分析
redis-cli -h ${HowUger_redis_addr} -p ${HowUger_redis_port} -a ${HowUger_redis_auth} --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).
[00.00%] Biggest zset found so far 'testzset' with 129 members
[00.00%] Biggest hash found so far 'h2' with 513 fields
[00.00%] Biggest set found so far 'si1' with 5 members
[00.00%] Biggest hash found so far 'h4' with 514 fields
[00.00%] Biggest string found so far 'key' with 9 bytes
-------- summary -------
Sampled 9 keys in the keyspace!
Total key length in bytes is 27 (avg len 3.00)
Biggest string found 'key' has 9 bytes
Biggest set found 'si1' has 5 members
Biggest hash found 'h4' has 514 fields
Biggest zset found 'testzset' has 129 members
1 strings with 9 bytes (11.11% of keys, avg size 9.00)
0 lists with 0 items (00.00% of keys, avg size 0.00)
2 sets with 8 members (22.22% of keys, avg size 4.00)
4 hashs with 1541 fields (44.44% of keys, avg size 385.25)
2 zsets with 132 members (22.22% of keys, avg size 66.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
简单总结下：
- Bigkeys实际是使用
scan方式对Redis中所有key进行扫描统计，因此无需担心其对Redis造成阻塞。 - Bigkeys主要应用于统计以
string为主要存储类型的key分析场景。 - Bigkeys对于list,set,zset和hash等其他Redis数据类型的统计是以元素个数作为衡量标准的，可以说对于非string类型key的统计bigkeys的结论是模糊且没有意义的。
基于debug object key的序列化分析
HowUger_redis:orz> hmset myhash k1 v1 k2 v2 k3 v3
OK
HowUger_redis:orz> debug object myhash
Value at:0x7f005c6920a0 refcount:1 encoding:ziplist serializedlength:36 lru:3341677 lru_seconds_idle:2
debug object key基本输出说明如下：
- Value at：key的内存地址
- refcount：引用次数
- encoding：编码类型
- serializedlength：序列化长度
- lru_seconds_idle：空闲时间
官方不建议在客户端使用debug object key命令，原话是这样婶儿滴：
DEBUG OBJECT is a debugging command that should not be used by clients.
说几个问题：
- serializedlength是key序列化后的长度，并不是key在内存中的真正长度。就像一个数组在json_encode后的长度与其在内存中的真正长度并不相同。
- serializedlength会对string做一些可能的压缩。如果有些string的压缩比特别高，那么在比较时就会出事情
- 计算serializedlength的代价相对高，少尝试，慎用别开玩笑。（多数云供应商的DCS服务会直接禁用客户端调用debug object命令哦）
基于rdbtools的rdb文件分析
rdb -c memory /tmp/HowUger_redis_dump.rdb
database,type,key,size_in_bytes,encoding,num_elements,len_largest_element,expiry
0,hash,data:index_flow_yingshi,10492,hashtable,1,8992,2019-01-14T08:20:10.236000
0,hash,data:index_movie,22068,hashtable,7,2896,2019-01-14T07:29:19.685000
0,string,block:index_module_novel,8296,string,7694,7694,2019-01-13T00:27:46.128000
0,string,block:index_bottom_baike_aikan,8296,string,7632,7632,2019-01-14T02:27:11.850000
0,string,block:index_bottom_tools,5224,string,4549,4549,2019-01-13T01:02:09.171000
0,string,block:index_module_travel,7272,string,6408,6408,2019-01-13T00:43:39.478000
...
总结说明：
- python2.4以上版本
- git仓
- 基于离线数据rdb文件
- 包含但不仅限于rdb，还有redis-memory-for-key，RdbParser等待
- 加分依赖包python-lzf
- rdb文件分析、生成json或csv格式报告、单key内存分析、rdb解析器等等，更多具体功能看git吧。
- 通过分析rdb文件中的key及value，反算出该kv在内存中的大小。计算时考虑了数据类型的影响，key本身长度的影响，内存分配等多种因素。虽然得出的大小不是真实值，但用于key大小的统计已经是完全足够了。
