Redis的key命名规范

一、键值设计
1. key名设计
【建议】: 可读性和可管理性
        1) 建议全部⼤写
        2) key不能太长也不能太短,键名越长越占资源，太短可读性太差
        3) key 单词与单词之间以  ： 分开
【以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id】
 redis使用的时候注意命名空间，一个项目一个命名空间，项目内业务不同命名空间也不同。
一般情况下：
  1) 第一段放置项目名或缩写 如 project
  2) 第二段把表名转换为key前缀 如, user:
  3) 第三段放置用于区分区key的字段,对应mysql中的主键的列名,如userid
  4) 第四段放置主键值,如18,16

PRO:USER:UID:18

【强制】不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符；

2. value设计
(1)【强制】：拒绝bigkey(防止网卡流量、慢查询)
string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。如果是hash ,set,zset ,list 等元素固定一个桶的数量，比如5000，每次存取的时候，先在本地计算field的hash值，模除5000，确定该field落在哪个key上。

newHashKey  =  hashKey + (*hash*(field) % 5000）;   
hset (newHashKey, field, value) ;  
hget(newHashKey, field)

大key数据存⼊Redis，除了带来极大的内存占用外，在并发高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用。虽然Redis支持512MB大小的string，但是假设1mb的string大key，每秒重复写入10次，就会导致写入网络IO达10MB;

(1)读写大key会导致超时严重，网卡流量占满,甚至阻塞服务,更甚者导致宕机风险。

(2)如果删除大key，DEL命令可能阻塞Redis进程数十秒，使得其他请求阻塞，对应用程序和Redis集群可用性造成严重的影响。

非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会不出现在慢查询中

(2)【推荐】：选择适合的数据类型。
例如：实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist，但也要注意节省内存和性能之间的平衡)

3.【推荐】：控制key的生命周期，redis不是垃圾桶。
Redis key一定要设置过期时间。要跟自己的业务场景，需要对key设置合理的过期时间。可以在写入key时，就要追加过期时间；也可以在需要写入另一个key时，删除上一个key。说明：

(1)若不设置的话，这些key会一直占用内存不释放，随着时间的推移会越来越大，直到达到服务器的内存上限，导致服务器宕机等重大事故；

(2)对于key的超时时长设置，可根据业务场景进行评估，设置合理有效期；

(3)某些业务的确需要长期有效，可以判断即将到期时，重新设置有效期，避免引起热点key问题。