Redis开发规范
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Redis开发规范，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6265字，纯文字阅读大概需要9分钟。
内容图文
文章目录
我基于网络上的资料整理、添加的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开发规范所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。