Redis开发规范

我基于网络上的资料整理、添加的Redis开发规范。欢迎交流指导：）
转载请注明出处

一、键值设计

1.key名设计

【强制】以英文字母开头，命名中只能出现小写字母、数字、英文点号.和英文半角冒号:

【强制】不该使用含义不清的key以及特别长的key名

【强制】禁止使用Redis保留字命名key

【强制】命名规范：业务模块名:业务逻辑含义:其他

1)业务模块名：具体的功能模块
2)业务逻辑含义段：
【强制】不同业务逻辑含义使用英文半角冒号(:)分割，
【强制】同一业务逻辑含义段的单词之间使用英文半角点号 (.)分割，用来表示一个完整的语义

示例： user:basic.info:1 注：1是用户id

【推荐】简洁性

保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如：

user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}

2.value设计

【强制】拒绝bigkey

string类型控制在10KB以内，hash、list、set、zset元素个数不要超5000。以防止网卡流量、慢查询。反例：一个包含200万个元素的list。非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题（例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞。）

【强制】禁止在Redis中存储敏感的明文数据

【推荐】选择适合的数据类型

例如：
反例：

set user:1:name tom
set user:1:age 19
set user:1:favor football

正例：

hmset user:1 name tom age 19 favor football

3.【强制】关于过期时间

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代替。

【强制】严禁对 zset 的不设范围操作

zrange、zrangebyscore等多个操作 zset 的函数，严禁使用 zrange myzset 0 -1 等这种不设置范围的操作。请指定范围，如zrange myzset 0 100。如不确定长度，可使用 zcard 判断长度。

【强制】严禁对大数据量 key 使用 hgetall

hgetall会取出相关 HASH 的所有数据，如果数据条数过大，同样会引起阻塞，请确保业务可控。如不确定长度，可使用hlen先判断长度。

2.【强制】禁用命令

禁止线上使用keys、flushall、flushdb等，通过Redis的rename机制禁掉命令，或者使用scan的方式渐进式处理。

反例：使用keys 正则匹配操作查找某个key

3.【推荐】使用批量操作提高效率

原生命令：例如mget、mset。
非原生命令：可以使用pipeline提高效率。

但要注意控制一次批量操作的元素个数（例如500以内，实际也和元素字节数有关）。
注意两者不同：

1. 原生是原子操作，pipeline是非原子操作。
2. pipeline可以打包不同的命令，原生做不到
3. pipeline需要客户端和服务端同时支持。

注意：Redis-Cluster架构下如需使用pipeline，需要客户端的支持（比如开源的jedis没有提供集群模式下pipeline接口的实现，需要自己改造封装）

4.【推荐】Redis事务功能较弱，不推荐过多使用

Redis的事务功能较弱（不支持回滚），而且集群版本要求一次事务操作的key必须在一个slot上（可以使用hashtag功能解决）

5.【慎用】关于hashtag功能

hashtag功能可让相关key落位在同一个slot，集中在同一节点，不大推荐使用。
如果确实需要用，需控制同一hashtag的数量。

6.【推荐】根据业务场景选择数据类型

目前Redis支持的数据库结构类型较多：字符串(String)，哈希(Hash)，列表(List)，集合(Set)，有序集合(Sorted Set)， Bitmap， HyperLogLog和地理空间索引(geospatial)等，需要根据业务场景选择合适的类型。
在不能确定其它复杂数据结构⼀定优于String类型时，避免使用Redis的复杂数据结构。 每种数据结构都有相应的使⽤场景，String类型是Redis中最简单的数据类型，推荐使用String类型。 但是考虑到具体的业务场景，综合评估性能、存储网络等方面之后使用适当的数据结构。 需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、简单数据类类型等；Hash可以用作对象如用户等，包含较多属性的信息；List可以用作息队列、关注列表等；Set可以用于推荐；Sorted Set可以用于排行等。

三、客户端使用

1.【推荐】避免多个应用使用一个Redis实例

正例：不相干的业务拆分，公共数据做服务化。

2.【推荐】使用连接池

使用带有连接池的数据库，可以有效控制连接，同时提高效率，标准使用方式：

执行命令如下：
Jedis jedis = null;
try {
  jedis = jedisPool.getResource();
  //具体的命令
  jedis.executeCommand()
} catch (Exception e) {
  logger.error("op key {} error: " + e.getMessage()， key， e);
} finally {
  //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
  if (jedis != null) 
    jedis.close();
}

3.【推荐】高流量时做好熔断

高并发下推荐客户端添加熔断功能（例如netflix hystrix）

4.【强制】auth访问

Redis集群应设置密码访问

5.【推荐】内存策略

根据自身业务类型，选好maxmemory-policy（最大内存淘汰策略），设置好过期时间。
默认策略是volatile-lru，即超过最大内存后，在过期键中使用lru算法进行key的剔除，保证不过期数据不被删除，但是可能会出现OOM问题。
其它策略如下：

• allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
• allkeys-random：随机删除所有键，直到腾出足够空间为止。
• volatile-random：随机删除过期键，直到腾出足够空间为止。
• volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。
• noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。

6.【推荐】注意key的过期时间设置

在某些业务高峰期（如运营活动时的线上报名），key值过期时间设置过短或者过于集中容易造成缓存穿透，导致大量请求直接打到 MySql数据库。

7.【慎用】将Redis做为消息队列

如没有非常特殊的需求，严禁将Redis 当作消息队列使用。Redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。

四、参考文献

阿里云Redis开发规范
技术分享：Redis规范