一，设计Key结构

Redis 的 key 虽然可以自定义，但是最好遵循以下几个最佳实践约定：

• 遵循基本格式：[业务名]:[数据名]:[id]
• value长度不超过44字节
• 不包含特殊字符

例如：登录业务，保存用户信息，key 为：login:user:10

优点：

1. 可读性强
2. 避免key冲突
3. 方便管理
4. 更节省内存空间，key是string类型，底层编码包含int，embstr和raw三种，embstr是key小于44字节使用，他采用连续内存空间，内存占用更小。

二，BigKey问题

2.1 什么是BigKey

BigKye 通常以 Key 的大小和 Key 中成员的数量来判定，例如：

• Key本身的数据量过大：一个String类型的Key他的值为5MB
• Key中的成员数过多：一个ZSET类型的Key，他的成员数量为10000个。
• Key中成员的数据量过大：一个Hash类型的Key，他的成员数量虽然只有1000个，但这些成员的Value值总大小为100MB

推荐值：

• 单个Key的value小于10KB
• 对于集合类型的key，建议元素数量小于1000

查看元素大小：

memory usage keyName
# 返回元素字节数

2.2 BigKey的危害

网络阻塞：对 BigKey 执行读请求，少量的 QPS 就可能导致宽带使用率被占满，导致 Redis 实例，乃至所在物理机变慢。

数据倾斜：BigKey 所在的 Redis 实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡。

Redis 阻塞：对元素较多的 hash，list，zset 等做运算会耗时较久，使主线程被阻塞。

CPU 压力：对 BigKey 的数据序列化和反序列化会导致 cpu 的使用率飙升，影响 Redis 实例和本机其他应用。

2.3 如何发现BigKey

• redis-cli --bigkeys

  利用 redis-cli 提供的 --bigkyes 参数，可以遍历分析所有的 key，并返回 Key 的整体统计信息与每个数据的 Top1 的 big key

• scan扫描

  自己编程，利用 sacn 扫描 redis 中所有 key，利用 strlen，hlen 等命令判断 key 的长度（不建议使用 memory usage）

  scan cursor [Match pattern] [Count count] [Type type]
  

• 第三方工具

  利用第三方工具，例如，Redis-Rdn-Tools分析 RDB 快照文件，全面分析内存使用情况。

• 网络监控

  自定义工具，监控进出 Redis 的网络数据，超出预警值时主动告警。

2.4 如何删除BigKey

BigKey 内存占用较多，即使删除这样的 key 也需要耗费很长时间，导致 Redis 主线程阻塞，引发问题。

• redis3.0 及以下版本

  如果是集合类型的，则遍历 BigKye 的元素，先逐个删除子元素，最后删除 BigKey

• redis4.0 以后

  Redis4.0 后提供了异步删除的命令:unlink

三，数据类型的选择