目录
[优雅的 key](#优雅的 key)
[拒绝 Bigkey](#拒绝 Bigkey)
[Bigkey 的危害](#Bigkey 的危害)
[如何发现 Bigkey](#如何发现 Bigkey)
[如何删除 Bigkey](#如何删除 Bigkey)
优雅的 key
Redis 的 key 虽然可以自定义，但是最好遵循以下几条约定
-
遵循基本格式：[业务名称]:[数据名]:[id]
-
长度不超过 44 个字节
-
不包含特殊字符
key 是 string 类型，低层编码包含 int embstr 和 raw 三种。embstr 在小于 44 字节使用，采用连续内存空间，内存占用更小
拒绝 Bigkey
Bigkey 通常以 key 的大小和 key 中的成员的数量来决定的，比如一个 key 的大小就占用了 5 M 或者说其内部成员超过一万个等，我们其实更加推荐单个 key 的 val 值小于 10KB ，对于几个类型的 key 我们建议元素的数量小于 1000 个
说了这么多，我们可以使用 memory usage key 来查看一个 key 包括其中的元素的一共占用多少个字节，或者 strlen key 也可以查看一个 key 的字节长度
Bigkey 的危害
-
网络阻塞：对 Bigkey 执行请求时，少量的 QPS 就可能导致带宽使用率占满，导致 Redis 实例，乃至整个物理机变慢
-
数据倾斜：Bigkey 所在的 Redis 实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡
-
Redis 阻塞：对元素较多的 hash , list , zset 等做运算会比较耗时，使得主进程堵塞
-
CPU 压力：对 Bigkey 的数据序列化和反序列化会导致 CPU 的使用率飙升，影响其实例和本机的其他应用
如何发现 Bigkey
-
redis-cli --bigkeys：利用这条命令就可以遍历 redis 内所有的 key 并返回 key 的整体统计信息与每个数据的 Top1 的 big key，但是这个会整个扫描 redis 中所有的 key 这样相对来说还是比较耗时的
-
scan 扫描：自己编码，利用 scan 扫描 redis 中所有的 key ，利用 strlen ，hlen 等命令来查看一个 key 的实际长度，这个命令只会扫描一部分 key ，这个范围由使用者自行定义，一般这个用的相对比较多
-
使用第三方工具：如 Redis-Rdb-Tools 分析 RDB 快照文件，全面分析内存情况
-
网络监控：自定义网络监控，监控进出 Redis 的网络数据，超出预警时主动报警
如何删除 Bigkey
Bigkey 内存占用较多，即便删除这样的 key 也是比较耗时的，这同样也会导致主线程阻塞，引发一系列问题
在 redis 3.0 版本以前，如果是集合类型，都是先遍历 big key 的元素，再逐个删除，最后再删除 key
来到 redis 4.0 及以后官方就提供了异步删除的命令 ：unlink
恰当的数据类型
比如存储一个对象类型的数据，我们推荐三种存储方式
-
json 字符串：实现简单粗暴，缺点：数据耦合吗，不够灵活
-
字段打散：可以灵活访问对象中的任意字段，缺点：占用空间大，没办法做到统一控制
-
hash：低层使用 ziplist ，占用空间小，可以灵活的访问对象中的任意字段，缺点：代码相对复杂
这么对比下来，hash 完美胜出，但是这还不是最优解，下面是 hash 可能还存在的问题
hash 的 entry 数量超过 500 时，会使用哈希表而不是 Ziplist ，这样也会导致内存占用过大的问题，但是我们可以通过 hash-max-ziplist-entries 配置 entry 上限，但是 entry 过多的话还是会导致 bigkey 的问题再次出现
那么如何优化呢？
拆分 string 类型，假如有 hash 类型的 key ，其中有 100 万对 field 和 value ，field 是自增 id，这个 key 存在什么问题？如何优化呢？
有一个方案就是将每一个 hash 再次才分成多个小的 hash ，这样外层的一个 key 就可以掌管多个内部的 key ，也就是相当于掌管里面所有的 hash ，我们只需要对内部的 hash 的做优化就可以了，如果内部 hash 过于庞大的话，再考虑对外部的 hash 做优化就可以基本解决这个问题
-
key 的最佳实践
-
固定格式的 key
-
足够精简，不超过 44 个字节
-
不包含特殊字符
-
-
value 的最佳实践
-
合理拆分数据，拒绝 big key
-
选择适合的数据类型
-
hash 结构的 entry 最好不要超过 1000
-
设置合适的超时时间
-