Redis Bigkey - 技术栈

[优雅的 key](#优雅的 key)

[拒绝 Bigkey](#拒绝 Bigkey)

[Bigkey 的危害](#Bigkey 的危害)

[如何发现 Bigkey](#如何发现 Bigkey)

[如何删除 Bigkey](#如何删除 Bigkey)

Redis 的 key 虽然可以自定义，但是最好遵循以下几条约定

key 是 string 类型，低层编码包含 int embstr 和 raw 三种。embstr 在小于 44 字节使用，采用连续内存空间，内存占用更小

Bigkey 通常以 key 的大小和 key 中的成员的数量来决定的，比如一个 key 的大小就占用了 5 M 或者说其内部成员超过一万个等，我们其实更加推荐单个 key 的 val 值小于 10KB ，对于几个类型的 key 我们建议元素的数量小于 1000 个

说了这么多，我们可以使用 memory usage key 来查看一个 key 包括其中的元素的一共占用多少个字节，或者 strlen key 也可以查看一个 key 的字节长度

Bigkey 的危害

如何发现 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

比如存储一个对象类型的数据，我们推荐三种存储方式

这么对比下来，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
- 设置合适的超时时间