Redis的key命名规范

一、键值设计
1. key名设计
【建议】: 可读性和可管理性
        1) 建议全部⼤写
        2) key不能太长也不能太短,键名越长越占资源,太短可读性太差
        3) key 单词与单词之间以  : 分开
【以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id】
Redis的key命名规范_第1张图片 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问题。

你可能感兴趣的:(Redis,数据库,mysql,redis)