文章目录
1. 尽量避免BigKey
我们知道Redis使用单线程读写数据,一旦有BigKey
产生,则在对BigKey
读写时很可能造成Redis单线程阻塞,从而影响整个Redis响应。
一般来说BigKey
的情况有两种:
- 键值对中的值很大
比如String类型的时,value的值保存了1M
的数据,针对这种情况建议在业务设计时就要注意,尽量对Key或者Value进行再进行拆分,如果实在避免不了,可以考虑对数据进行压缩后再传输。
除此之外,Key的长度也尽量要短。
- 集合数据很大
除了String,其他集合类型如:Hash、Set、List
等,如果存放的集合元素过多,一旦要取全量数据,则也会存在BigKey
的问题,针对这类问题,解决方式和前面的方式一样,要么进行拆分,要么考虑使用压缩,尽量精简存放的字段(包括字段名、字段类型等)。
2. 禁用部分命令
还是由于Redis单线程读写的原因,所以线上应当禁用一些涉及到全量数据的命令,否则会影响整个Redis响应。
这部分命令包括如下一些:
- Keys
这是一个时间复杂度为O(N)
的命令, N
为Redis数据库中Key的数量。
实际上KEYS的速度是很快的,但如果在一个大的数据库中使用它,则还是会对Redis带来影响,建议使用SCAN
命令来代替Keys
命令,或者使用Set
集合来代替。
- 集合类查全量
同样的,一些查全量集合数据的命令,也可能带来隐患,比如HGETALL、SMEMBERS
等,这些命令的时间复杂度都是取决于集合中Key的元素个数,随着元素个数的增加,响应时间变的越来越慢,同样建议对其进行拆分存储。
- FLUSHDB、FLUSHALL
一个是清空当前数据库中的数据,一个是清空整个Redis实例中的数据,如果数据量很大,则同样会阻塞线程,避免在线上运行时执行,一般可以让运维对这个命令进行重命名,避免客户端调用的隐患。
3. 设置过期时间
理论上所有Key都应该有过期时间,除非有非常明确的业务应用场景,Key设置过期时间主要是为了避免无效的Key还一直占用内存资源,最后触发内存淘汰机制,淘汰了一些相对的热Key数据,甚至直接导致内存不足,服务崩溃。
4. 避免单Redis实例过大
大多数情况下,要尽量避免通过无限增加Redis内存来解决单机内存瓶颈的问题,因为内存越大就意味着在进行RDB快照,主从复制等操作时阻塞时间越长,所以一般建议单机内存最好不要超过8G
,内存不足的情况下应当通过集群部署来解决。
5. 不要把Redis当数据库使用
虽然Redis有RBD+AOF的持久化机制,但这只是Redis自身数据高可靠的保证,最终目的并不是为了让客户端把它当做数据库使用,毕竟内存容量有限,使用Redis最主要的原因还是为了对热数据进行缓存。
6. 避免Key的集中过期
Key的集中过期对于Redis来说并没有什么影响,主要还是在业务上可能会因为大量Key的集中失效,导致在失效那一时刻,如果存在大量访问,则会对数据库带来巨大的压力,所以一般情况下,可以在失效时间上加上毫秒级别的随机数。
7. 避免连续写入
Redis中大部分命令都不支持批量的,比如一次性有1000个String类型的Key需要写入,正常情况下只能一个个写入,每一次写入都要经过从客户端发起命令到服务端执行命令、返回结果的过程,如果这样执行1000次,则会有大量的时间都消耗在了网络上,客户端会非常的慢。
针对这种情况,建议使用Pipeline
功能,这是由客户端提供的API,它可以一次性传一批命令给到服务端,从而减少了客户端与服务端的交互次数,避免了网络消耗的问题,当然批命令在使用时也要注意,批量的命令也不是无上限的,其不能超过缓冲区的大小,还要注意一次传入过多的命令也必然会造成服务端执行时间较长,造成阻塞问题。
8. 关于AOF持久化
非必要时不建议开启AOF,就算开启也不要实时刷盘,建议按照每秒1次来设置
,避免磁盘I/O的消耗给Redis造成不稳定。