前言
在业务中,会经常使用 redis 作为后端缓存、存储。如果结构规划不合理、命令使用不规范,会造成系 统性能达到瓶颈、活动高峰系统可用性下降,也会增大运维难度。这里总结了一些使用规范,希望能从 源头上避免上述问题的出现。
存储选型
Redis是一个单进程、基于内存、弱事务(单个命令可以保证原子性,多命令无法保证)的NoSql存储系 统,适用于高QPS、低延迟、弱持久化的场景,适宜用作缓存。
从经验出发: 在qps>5000、容量<50G、存储高频数据时考虑redis;在qps<1000、存储大量低频数 据、需要事务时考虑Mysql。
使用场景
前提声明:
- 严禁在redis中存储需要持久化的数据;
- 只缓存热点数据
- 高并发场景下,热点数据缓存
高并发场景下,合理的使用缓存不仅能够提升网站访问速度,还能降低后端数据库的压力。
- 排行榜类场景
关系型数据库在排行榜类场景的查询速度普遍偏慢,借助Redis提供的list和sorted sets结构能实现各种复杂的排行榜应用。
- 限时业务的运用
利用expire命令可以运用在限时优惠活动信息、订单库存过期、手机验证码等业务场景。
- 计数器
Redis天然支持计数功能而且计数的性能也非常好,在高并发场景下优于传统的关系型数据库,常运用于商品的浏览数、视频的播放数、限制调用等。
- 社交网络
点赞、踩、关注/被关注、共同好友等是社交网站的基本功能,社交网站的访问量通常来说比较大,而且传统的关系数据库类型不适合存储这种类型的数据,Redis提供的哈希、集合等数据结构能很方便的的实现这些功能。
- 分布式锁
在高并发场景中,利用数据库锁来控制资源的并发访问,性能不理想,可以利用Redis的setnx功能来编写分布式的锁。
一 键值设计
1. key名设计
- 【建议】: 可读性和可管理性
以业务名(或数据库名)为前缀(防止key冲突),必须使用冒号分隔,便于RDM查看,比如应用名称:租户号:DD_CODE。
APPKEY:TENANT_CODE:DD_CODE
- 【建议】:简洁性
保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如:
user:{uid}:friends:messages:{mid}简化为u:{uid}:fr:m:{mid}。
- 【强制】:长度50个字符以内,不要包含空格、换行,引号和一些转义字符
反例:包含空格、换行、单双引号以及其他转义字符
- 【强制】: 控制key的总数量
redis实例包含的键个数建议控制在 1 千万内,单实例的键个数过大,可能导致过期键的回收不及时。
2. value设计
- 【强制】:拒绝bigkey(防止网卡流量、慢查询)
string类型控制在10KB以内,hash、list、set、zset元素个数不要超过5000。 反例:一个包含200万个元素的list。 非字符串的bigkey,不要使用del删除,使用hscan、sscan、zscan方式渐进式删除,同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期,会触发del操作,造成阻塞,而且该操作不会不出现在慢查询中(latency可查)),查找方法和删除方法
- 【推荐】:选择适合的数据类型。
例如:实体类型(要合理控制和使用数据结构内存编码优化配置,例如ziplist,但也要注意节省内存和性能之间的平衡) 反例:
set user:1:name tom
set user:1:age 19
set user:1:favor football
正例:
hmset user:1 name tom age 19 favor football
- 【强制】:控制key生命周期,redis不是垃圾站
建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期),不过期的数据重点关注idletime。 如果业务强制需求不过期,请说明具体原因。
二 命令使用
1.【推荐】 O(N)命令关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有
遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】:禁用命令
禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan
的方式渐进式处理。
3.【推荐】避免使用select ,使用登录上去默认的db0
redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还是单线程处理,会有干扰。 哨兵模式中不建议使用多db,毕竟集群模式已经不能使用多db。
4.【推荐】使用批量操作提高效率
- 原生命令是原子操作,pipeline是非原子操作
- pipeline可以打包不同的命令,原生不支持
- pipeline需要客户端和服务端同时支持
- 原生命令:如mget、mset。
- 非原生命令:可以使用pipeline提高效率。
- 但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)。
5.【建议】Redis事务功能较弱,不建议过多使用
Redis事务功能不支持回滚,cluster 要求事务操作的key必须在一个slot上面。
6.【建议】Redis集群版本在使用Lua上有特殊要求
- 所有key都应该由 KEYS 数组来传递,redis.call/pcall 里面调用的redis命令,key的位置,必须是KEYS array, 否则直接返回error,
-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array
- 所有key,必须在1个slot上,否则直接返回error, “-ERR eval/evalsha command keys must in same slot”
7.【建议】必要情况下使用Monitor命令时,要注意不要长时间使用,造成缓冲区溢出,尽而内存抖动
三 客户端使用
1.【推荐】
使用带有连接池的数据库,可以有效控制连接,同时提高效率,标准使用方式:
//执行命令如下:
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();
}
2.【建议】
高并发下建议客户端添加熔断功能(例如netflix hystrix)
3.【推荐】
设置合理的密码,如有必要可以使用SSL加密访问
4.【建议】
设置合理的密码,如有必要可以使用SSL加密访问
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只响应读操作。
四 合理使用
1. 【推荐】冷热数据分离,不要将所有数据全部都放到Redis中
虽然Redis支持持久化,但是Redis的数据存储全部都是在内存中的,成本昂贵。建议根据业务只将高频热数据存储到Redis中【QPS大于5000】,对于低频冷数据可以使用MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式,不仅节省内存成本,而且数据量小在操作时速度更快、效率更高!
2. 【推荐】不同的业务数据要分开存储
不要将不相关的业务数据都放到一个Redis实例中,建议新业务申请新的单独实例。因为Redis为单线程处理,独立存储会减少不同业务相互操作的影响,提高请求响应速度;同时也避免单个实例内存数据量膨胀过大,在出现异常情况时可以更快恢复服务!
3. 【推荐】存储的Key一定要设置超时时间
如果应用将Redis定位为缓存Cache使用,对于存放的Key一定要设置超时时间!因为若不设置,这些Key会一直占用内存不释放,造成极大的浪费,而且随着时间的推移会导致内存占用越来越大,直到达到服务器内存上限!另外Key的超时长短要根据业务综合评估,而不是越长越好!
4. 【推荐】对于必须要存储的大文本数据一定要压缩后存储
对于大文本【超过500字节】写入到Redis时,一定要压缩后存储!大文本数据存入Redis,除了带来极大的内存占用外,在访问量高时,很容易就会将网卡流量占满,进而造成整个服务器上的所有服务不可用,并引发雪崩效应,造成各个系统瘫痪!
5. 【强制】线上Redis禁止使用Keys正则匹配操作
Redis是单线程处理,在线上KEY数量较多时,操作效率极低【时间复杂度为O(N)】,该命令一旦执行会严重阻塞线上其它命令的正常请求,而且在高QPS情况下会直接造成Redis服务崩溃!如果有类似需求,请使用scan命令代替!
6. 【推荐】谨慎全量操作Hash、Set等集合结构
在使用HASH结构存储对象属性时,开始只有有限的十几个field,往往使用HGETALL获取所有成员,效率也很高,但是随着业务发展,会将field扩张到上百个甚至几百个,此时还使用HGETALL会出现效率急剧下降、网卡频繁打满等问题【时间复杂度O(N)】,此时建议根据业务拆分为多个Hash结构;或者如果大部分都是获取所有属性的操作,可以将所有属性序列化为一个STRING类型存储!同样在使用SMEMBERS操作SET结构类型时也是相同的情况!
7. 【建议】根据业务场景合理使用不同的数据结构类型
目前Redis支持的数据库结构类型较多:字符串(String),哈希(Hash),列表(List),集合(Set),有序集合(Sorted Set), Bitmap, HyperLogLog和地理空间索引(geospatial)等,需要根据业务场景选择合适的类型,常见的如:String可以用作普通的K-V、计数类;Hash可以用作对象如商品、经纪人等,包含较多属性的信息;List可以用作消息队列、粉丝/关注列表等;Set可以用于推荐;Sorted Set可以用于排行榜等!
五 相关工具
1.【推荐】:数据同步
redis间数据同步可以使用:redis-port
2.【推荐】:big key搜索
对于Redis主从版本可以通过scan命令进行扫描,对于集群版本提供了ISCAN命令进行扫描,命令规则 如下, 其中节点个数node可以通过info命令来获取到:
3.【推荐】:热点key寻找(内部实现使用monitor,所以建议短时间使用,生产环境一般不建议使用)
六 附录:删除bigkey
1. 下面操作可以使用pipeline加速。
2. redis 4.0已经支持key的异步删除,建议使用。
1. Hash删除: hscan + hdel
public void delBigHash (String host,int port, String password, String
bigHashKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
ScanParams scanParams = new ScanParams().count(100);
String cursor = "0";
do {
ScanResult> scanResult = jedis.hscan(bigHashKey,
cursor, scanParams);
List> entryList = scanResult.getResult();
if (entryList != null && !entryList.isEmpty()) {
for (Entry entry : entryList) {
jedis.hdel(bigHashKey, entry.getKey());
}
}
cursor = scanResult.getStringCursor();
} while (!"0".equals(cursor));
//删除bigkey
jedis.del(bigHashKey);
}
2. List删除: ltrim
public void delBigList(String host, int port, String password, String
bigListKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
long llen = jedis.llen(bigListKey);
int counter = 0;
int left = 100;
while (counter < llen) {
//每次从左侧截掉100个
jedis.ltrim(bigListKey, left, llen);
counter += left;
}
//最终删除key
jedis.del(bigListKey);
}
3. Set删除: sscan + srem
public void delBigSet(String host, int port, String password, String bigSetKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
ScanParams scanParams = new ScanParams().count(100);
String cursor = "0";
do {
ScanResult scanResult = jedis.sscan(bigSetKey, cursor,
scanParams);
List memberList = scanResult.getResult();
if (memberList != null && !memberList.isEmpty()) {
for (String member : memberList) {
jedis.srem(bigSetKey, member);
}
}
cursor = scanResult.getStringCursor();
} while (!"0".equals(cursor));
//删除bigkey
jedis.del(bigSetKey);
}
4. SortedSet删除: zscan + zrem
public void delBigZset(String host, int port, String password, String
bigZsetKey) {
Jedis jedis = new Jedis(host, port);
if (password != null && !"".equals(password)) {
jedis.auth(password);
}
ScanParams scanParams = new ScanParams().count(100);
String cursor = "0";
do {
ScanResult scanResult = jedis.zscan(bigZsetKey, cursor,
scanParams);
List tupleList = scanResult.getResult();
if (tupleList != null && !tupleList.isEmpty()) {
for (Tuple tuple : tupleList) {
jedis.zrem(bigZsetKey, tuple.getElement());
}
}
cursor = scanResult.getStringCursor();
} while (!"0".equals(cursor));
//删除bigkey
jedis.del(bigZsetKey);
}
参考《Redis阿里云规范》总结整理
本文由博客一文多发平台 OpenWrite 发布!