Redis最佳实践
Redis最佳实践
键值设计
优雅的key设计
Redis的key虽然可以自定义，但最好遵循以下几个最佳实践约定:
- 遵循基本格式：[业务名称]:[数据名]:[id]
- 长度不超过44个字节
- 不包含特殊字符
优点:
- 可读性强
- 避免key冲突
- 方便管理
- 更节省内存: key是string类型，底层编码包含int,embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小
拒绝bigkey
BigKey通常以Key的大小和Key中成员的数量来综合判定，例如:
- Key本身的数据量过大:一个String类型的Key，它的值为5MB
- Key中的成员数过多:一个ZSET类型的Key，它的成员数量为10,000个
- Key中成员的数据量过大:一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value(值）总大小
为100 MB
推荐值:
- 单个key的value小于10KB
- 对于集合类型的key，建议元素数量小于1000
bigkey的危害
- 网络阻塞
对BigKey执行读请求时，少量的QPS就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢 - 数据倾斜
BigKey所在的Redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡 - Redis阻塞
对元素较多的hash、list、zset等做运算会耗时较旧，使主线程被阻塞 - CPU压力
对BigKey的数据序列化和反序列化会导致CPU的使用率飙升，影响Redis实例和本机其它应用
如何发现bigkey
- redis-cli --bigkeys
利用redis-cli提供的–bigkeys参数，可以遍历分析所有key，并返回Key的整体统计信息与每个数据的Top1的big key - scan扫描
自己编程，利用scan扫描Redis中的所有key，利用strlen、hlen等命令判断key的长度（此处不建议使用MEMORY USAGE) - 第三方工具
利用第三方工具，如Redis-Rdb-Tools分析RDB快照文件，全面分析内存使用情况 - 网络监控
自定义工具，监控进出Redis的网络数据，超出预警值时主动告警
批处理优化
单机批处理
原生m命令操作
略
Pipeline批处理
这里使用redisTemplate,jedis也有pipeline操作,不做展示
SessionCallback & RedisCallback ：在同一条连接下执行多个Redis命令。
-
RedisCallback
需要处理底层的转换规则，如果不考虑改写底层，尽量不使用
redisTemplate.execute(new RedisCallback() { @Override public Object doInRedis(RedisConnection redisConnection) throws DataAccessException { redisConnection.set("key1".getBytes(), "value1".getBytes()); redisConnection.hSet("hash1".getBytes(), "field".getBytes(), "test".getBytes()); return null; } }); -
SessionCallback
高级接口,支持事务
redisTemplate.execute(new SessionCallback() { @Override public Object execute(RedisOperations redisOperations) throws DataAccessException { redisOperations.opsForValue().set("key2", "value2"); redisOperations.opsForHash().put("hash2", "field", "test"); return null; } });
集群下的批处理
单机mset和pipeline在集群中出现的问题
如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果Redis是一个集群，那批处理命令的多个key必须落在一个插槽中，否则就会导致执行失败。原因是,redis集群定义了16384个插槽,不同key的slot不同,如果使用传统批处理,批处理中的命令会落在不同的节点,导致批处理失去意义。
解决方案
故解决问题,需要避免服务端计算slot,由客户端计算slot,实现批处理
而springRedisTemplate实现的集群下的批处理操作正是采用并行slot,推荐使用
stringRedisTemplate.opsForValue( ).multiSet() ;
总结
- 批处理应注意一次不要携带过多命令,以免网络阻塞
- Pipeline多个命令之间不具备原子性
- 单机批处理与集群批处理不同,需采取对应的方案
服务器端优化
持久化配置
Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议:
-
用来做缓存的Redis实例尽量不要开启持久化功能
-
建议关闭RDB持久化功能，使用AOF持久化
-
利用脚本定期在slave节点做RDB，实现数据备份
-
设置合理的rewrite阈值，避免频繁的bgrewrite
-
当RDB与AOF都在进行io操作时,或者redis进行了AOF的rewrite,可能引起AOF的io阻塞,导致主线程阻塞,因此应配置no-appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因AOF引起的阻塞
慢查询
在redis执行时耗时超过某个阈值的命令,成为慢查询
慢查询的阈值可以通过配置指定:
- slowlog-log-slower-than:慢查询阈值，单位是微秒。默认是10000，建议1000慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定:
- slowlog-max-len:慢查询日志（本质是一个队列）的长度。默认是128，建议1000
命令及安全配置
为了避免这样的漏洞，这里给出一些建议:
- Redis一定要设置密码
- 禁止线上使用下面命令: keys、flushall、flushdb、config set等命令。可以利用配置文件修改rename-command禁用
- 修改配置文件bind:限制网卡，禁止外网网卡访问
- 开启防火墙
- 不要使用Root账户启动Redis
- 尽量不使用默认的端口
内存安全及配置
- 使用info memory,memory xxx 命令进行redis内存信息的查看
内存缓冲区常见的有三种:
- 复制缓冲区:主从复制的repl_backlog_buf，如果太小可能导致频繁的全量复制，影响性能。通过repl-backlog-
size来设置，默认1mb - AOF缓冲区:AOF刷盘之前的缓存区域，AOF执行rewrite的缓冲区。无法设置容量上限
- 客户端缓冲区:分为输入缓冲区和输出缓冲区，输入缓冲区最大1G且不能设置。输出缓冲区可以设置
集群优化
集群完整性问题
为了保证高可用特性，这里建议将cluster-require-full-coverage配置为false
#当此配置开启时,当集群中有一个插槽不可用(如集群某个节点宕机),那整个集群将不可用
cluster-require-full-coverage yes
集群带宽问题
集群节点之间会不断的互相Ping来确定集群中其它节点的状态。每次Ping携带的信息至少包括:
- 插槽信息
- 集群状态信息
集群中节点越多，集群状态信息数据量也越大，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会非常高。
解决途径
- 避免大集群，集群节点数不要太多，最好少于1000，如果业务庞大，则建立多个集群
- 避免在单个物理机中运行太多Redis实例
- 配置合适的cluster-node-timeout值(定期进行节点间ping的时间)
集群还是主从
集群虽然具备高可用特性，能实现自动故障恢复，但是如果使用不当，也会存在一些问题:
- 集群完整性问题
- 集群带宽问题
- 数据倾斜问题
- 客户端性能问题
- 命令的集群兼容性问题
- lua和事务问题
单体Redis(主从Redis)已经能达到万级别的QPS，并且也具备很强的高可用特性。如果主从能满足业务需求的情况下，尽量不搭建Redis集群
集群模式lua问题补充
在集群下,它会将数据自动分布到不同的节点(虚拟的16384个slot)
它数据的路由分发,是通过计算key,所以只要key一样,则一定会被分到同一个slot
上面的参数keys的个数为1,肯定存储在一个slot里面，
但是如果是多个key且不存在同一个slot里面则会报错，
redis.clients.jedis.exceptions.JedisDataException: ERR 'EVAL' command keys must in same slot**
解决方案:
设置hashtag,在设置key的时候使用{xxxxx}的方式可以将该数据存在用一个slot里面，
但是，注意如果同一个slot里面的数据过多且同时操作查询频繁的数据就会影响到效率问题(数据倾斜)