(1)【建议】: 可读性和可管理性
以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id
1 trade:order:1
(2)【建议】:简洁性
保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如:
1 user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}
(3)【强制】:不要包含特殊字符
反例:包含空格、换行、单双引号以及其他转义字符
(1)【强制】:拒绝bigkey(防止网卡流量、慢查询)
在Redis中,一个字符串最大512MB,一个二级数据结构(例如hash、list、set、zset)可以存
储大约40亿个(2^32-1)个元素,但实际中如果下面两种情况,我就会认为它是bigkey。
1 set user:1:name tom
2 set user:1:age 19
3 set user:1:favor football
正例:
1 hmset user:1 name tom age 19 favor football
3.【推荐】:控制key的生命周期,redis不是垃圾桶。
建议使用expire设置过期时间(条件允许可以打散过期时间,防止集中过期)。
二、命令使用
1.【推荐】 O(N)命令关注N的数量
例如hgetall、lrange、smembers、zrange、sinter等并非不能使用,但是需要明确N的值。有
遍历的需求可以使用hscan、sscan、zscan代替。
2.【推荐】:禁用命令
禁止线上使用keys、flushall、flushdb等,通过redis的rename机制禁掉命令,或者使用scan的
方式渐进式处理。
3.【推荐】合理使用select
redis的多数据库较弱,使用数字进行区分,很多客户端支持较差,同时多业务用多数据库实际还
是单线程处理,会有干扰。
4.【推荐】使用批量操作提高效率
1 原生命令:例如mget、mset。
2 非原生命令:可以使用pipeline提高效率。
但要注意控制一次批量操作的元素个数(例如500以内,实际也和元素字节数有关)。
注意两者不同:
1 1. 原生是原子操作,pipeline是非原子操作。
2 2. pipeline可以打包不同的命令,原生做不到
3 3. pipeline需要客户端和服务端同时支持。
5.【建议】Redis事务功能较弱,不建议过多使用,可以用lua替代
1.【推荐】
避免多个应用使用一个Redis实例
正例:不相干的业务拆分,公共数据做服务化。
2.【推荐】
使用带有连接池的数据库,可以有效控制连接,同时提高效率,标准使用方式:
1 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
2 jedisPoolConfig.setMaxTotal(5);
3 jedisPoolConfig.setMaxIdle(2);
4 jedisPoolConfig.setTestOnBorrow(true);
5
6 JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.0.60", 6379, 3000, null);
7
8 Jedis jedis = null;
9 try {
10 jedis = jedisPool.getResource();
11 //具体的命令
12 jedis.executeCommand()
13 } catch (Exception e) {
14 logger.error("op key {} error: " + e.getMessage(), key, e);
15 } finally {
16 //注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
17 if (jedis != null)
18 jedis.close();
19 }
连接池参数含义:
优化建议:
1)maxTotal:最大连接数,早期的版本叫maxActive
实际上这个是一个很难回答的问题,考虑的因素比较多:
业务希望Redis并发量
客户端执行命令时间
Redis资源:例如 nodes(例如应用个数) * maxTotal 是不能超过redis的最大连接数
maxclients。
资源开销:例如虽然希望控制空闲连接(连接池此刻可马上使用的连接),但是不希望因
为连接池的频繁释放创建连接造成不必靠开销。
以一个例子说明,假设:
一次命令时间(borrow|return resource + Jedis执行命令(含网络) )的平均耗时约为
1ms,一个连接的QPS大约是1000
业务期望的QPS是50000
那么理论上需要的资源池大小是50000 / 1000 = 50个。但事实上这是个理论值,还要考虑到要
比理论值预留一些资源,通常来讲maxTotal可以比理论值大一些。
但这个值不是越大越好,一方面连接太多占用客户端和服务端资源,另一方面对于Redis这种高
QPS的服务器,一个大命令的阻塞即使设置再大资源池仍然会无济于事。
2)maxIdle和minIdle
maxIdle实际上才是业务需要的最大连接数,maxTotal是为了给出余量,所以maxIdle不要设置
过小,否则会有new Jedis(新连接)开销。
连接池的最佳性能是maxTotal = maxIdle,这样就避免连接池伸缩带来的性能干扰。但是如果
并发量不大或者maxTotal设置过高,会导致不必要的连接资源浪费。一般推荐maxIdle可以设置
为按上面的业务期望QPS计算出来的理论连接数,maxTotal可以再放大一倍。
minIdle(最小空闲连接数),与其说是最小空闲连接数,不如说是"至少需要保持的空闲连接
数",在使用连接的过程中,如果连接数超过了minIdle,那么继续建立连接,如果超过了
maxIdle,当超过的连接执行完业务后会慢慢被移出连接池释放掉。
如果系统启动完马上就会有很多的请求过来,那么可以给redis连接池做预热,比如快速的创建一
些redis连接,执行简单命令,类似ping(),快速的将连接池里的空闲连接提升到minIdle的数
量。
连接池预热示例代码:
1 List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());
2
3 for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
4 Jedis jedis = null;
5 try {
6 jedis = pool.getResource();
7 minIdleJedisList.add(jedis);
8 jedis.ping();
9 } catch (Exception e) {
10 logger.error(e.getMessage(), e);
11 } finally {
12 //注意,这里不能马上close将连接还回连接池,否则最后连接池里只会建立1个连接。。
13 //jedis.close();
14 }
15 }
16 //统一将预热的连接还回连接池
17 for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
18 Jedis jedis = null;
19 try {
20 jedis = minIdleJedisList.get(i);
21 //将连接归还回连接池
22 jedis.close();
23 } catch (Exception e) {
24 logger.error(e.getMessage(), e);
25 } finally {
26 }
27 }
总之,要根据实际系统的QPS和调用redis客户端的规模整体评估每个节点所使用的连接池大小。
3.【建议】
高并发下建议客户端添加熔断功能(例如sentinel、hystrix)
4.【推荐】
设置合理的密码,如有必要可以使用SSL加密访问
5.【建议】
Redis对于过期键有三种清除策略: