redis的key命名规范

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

PRO:USER:UID:18

key不能太长也不能太短,键名越长越占资源，太短可读性太差
【强制】不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符；
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问题。
二、命令使用
1.【推荐】 O(N)命令关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用，但是需要明确N的值。有遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】：禁用命令
禁止线上使用keys、flushall、flushdb等，通过redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。
3.【推荐】合理使用select
redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。
4.【推荐】使用批量操作提高效率

参考博客：https://blog.csdn.net/hudeyong926/article/details/120343766