Redis最佳实践:系统性能提升了10倍,真香!

戳上方蓝字“Java面试题精选”关注!

前言

在当今互联网项目中,几乎80%的的项目都有使用Redis。但在其应用过程中,总是或多或少遇到过一些问题。比如:

  • redis内存为什么会增长这么快?
  • redis为什么读取操作越来越慢?
  • 怎么样降低redis故障的频率?
  • redis的运维需要注意些什么?
  • redis部署时,如何做好资源使用的规划?
  • 对redis的监控应该要注意哪些指标?

特别是当你的应用对redis非常依赖的前提下,那么这些问题就显得尤为突出。

那么这个时候,这时候需要对redis的使用有一份最佳实践文档来助你轻松管理redis。下面就将以7个维度,全面解析redis的最佳使用及优化:

【内存、性能、高可靠、日常运维、资源控制、redis监控及安全】

最佳实战

redis怎么使用内存更优

我们大家都知道,redis性能如此强大的原因为基于内存的单线程操作,所以对于数据的读写都是非常之快的。但从资源层面来说,服务器的内存资源代价还是比磁盘要大得多的。一个项目中比较少使用redis的时候,你也可能不太会注意它的内存状态。但随着业务量的增大,redis里存储的数据可能就会成倍的增长。如果没有提前规划好redis的内存使用,想必肯定会出现不可预测的问题。那么我们如何来优化redis的内存使用呢?

01  key的长度必须

前面说了redis是基于内存的数据存储系统,因此key和其数据都会占用内存空间。当redis key比较多且长度较长时,会占用更多的内存空间,当内存增加时,还可能触发内存淘汰策略或导致redis内存的耗尽,影响系统的稳定性及性能。因此,在使用redis的过程中,应尽量控制key的长度。可在代码的redis key常量中注明key的业务。但在redis时可以以简写的方式进行保存。如:user_info_properties 可以简写为:u_i_prop等等。

02 注意bigkey的存储

在控制了key的长度后,redis value的大小也同样要注意使用。单个key不要存储太多的数据,否则也会导致redis内存极速的增大。并且在程序中读取bigkey时,还会产生性能问题,读取频繁的情况下,甚至会导致整个系统的崩溃。因此,为了避免产生bigkey,在使用redis的过程中String类型value值尽量控制在10kb以内,其它几个集合类型value值,尽量控制在5000以下。

03 根据业务选择合适redis数据类型存储

redis数据存储相对于mongo,memcache等其它nosql数据库来说,提供了丰富的数据存储类型,主要有:String、List、Set、Hash、Sorted Set五大数据类型。这几大数据类型主要可以存储的数据有:

  • String类型: 以key-value的形式存储,是二进制安全的,可以存储包括数字、字符、图片和序列化后的对象等数据。

  • Hash类型: 其值本身是键值对的形式,以key-field-value的形式存储,可以理解为一个小的key-value存储,方便进行数据的存储和读取。

  • List类型: Redis采用的是双端链表实现的,可以用来存储多个值,实现队列和栈的数据结构。

  • Set类型: 可以用来实现去重等功能,Set类型中的元素是无序的,且不重复。

  • Sorted Set类型: 具有类似Set类型的去重功能,但是可以根据分值进行排序。

04 不要把redis当数据库使用

redis的数据是存储在内存中的,这就意味着,在使用redis时资源是有限制的。你不能把它当作是数据使用,什么数据都往里面塞。这样redis坑定是扛不住的。

一般建议是只需要把经常使用的【热数据】且量小的数据热加载到缓存中,然后其它数据按需进行加载,避免一次性全部加载到redis。并且在使用redis存储数据时,你还必须得为key设置必要的过期时间。否则没用的数据也一直留在redis中,只会占着茅坑不拉屎,白白的浪费了资源(redis过期时间设置也是需要有针对性的设置,否则可能会造成缓存雪崩及击穿问题)。

如何最大的发挥redis的性能优势

每个系统使用redis的目的,无一例外就是看中redis的快(也就是高性能),有数据表面,一个单机版的redis,就可以达到10万的QPS,性能如此之高,我想如果不是因为高可用问题,我想一个单机版的redis就可以满足绝大部分项目使用了吧!那么如何发挥出redis真正的高性能状态避免出现操作延迟的情况下发生呢?

01 千说万说还是bigkey

bigkey的出现除了前面说的占用内存的问题外,其对性能的影响也是一大问题。众所周知,redis的请求是以单线程模式请求,当你写入或者读取或者删除一个bigkey时,会在redis的内存分配上消耗巨大的时间。

如此,你单次操作redis的耗时就回升高,从而堵塞redis的所有请求,导致redis的性能下降。如果该bigkey同时又是个热key的话,那不好意思,你的整个系统可能因此就会崩溃从而宕机。如此,就会出现后果不可预料的生产事故!所以,系统里应该不要出现bigkey的情况,如果数据实在太多,可以根据业务,对key进行拆分保存。

02 复杂度过高命令不使用

redis在执行复杂度过高的命令时,会消耗很多的CPU资源,那么基于redis是单线程这个模型,其它请求的线程只能等待,此时就也会发生延迟的情况。从而导致类似bigkey的情况发生。所以,在使用redis的过程中,应该尽量不要使用SORTSINTERSTORESINTER等这些聚合的命令。

03 多使用批量命令

如果你在程序中有这个业务,一次性要处理很多个key的情况。那么批量命令处理就是你的最佳选择。批量命令相对于一个个的执行来说,可以显著的减少客户端服务端的IO请求次数以达到提高性能的要求。如:

使用 MGET/MSET 替代 GET/SETHMGET/HMSET 替代 HGET/HSET

使用Pipeline管道,一次发送多个命令到redis

04 key过期时间设置不要太集中

在前面有提到过,在业务中使用redis,都必须为大部分的key设置一个过期时间,以达到节省内存的目的。但在为key设置过期时间时,要尽量避免每个key的过期时间不要太集中。如果某一时间存在大量key过期的情况,redis在清理这些key时,也会出现线程风暴出现大量被阻塞的线程。亦或是出现缓存雪崩的情况,大量请求因此而打到数据库,从而造成数据的瞬间压力飙升,导致一系列的性能问题。

05 合理的使用redis线程池

在使用redis的时,通常是使用池化技术进行redis的请求。但使用池化技术时,应当合理的设置线程池的参数配置,长时间不操作redis应当及时释放,根据CPU核数合理设置最大连接数等等。

06 使用读写分离或者集群

在文章开头有讲到,redis单机QPS支撑达到了10万。但此种部署方法达不到高可用。redis如果因为某些原因挂了,那么就会直接导致整个系统的崩溃,这是不可接受的。那么如何把redis的性能得到提升的同时从而实现高可用呢?那么你可以把redis进行哨兵模式或者集群模式部署。两种方式各有优缺点,你可以按需选择。

哨兵模式:

优点:

  • 高可靠性:如果一个节点失效,哨兵将自动选举出一个新的主节点并将应用程序重定向到它,无需手动操作。

  • 简单:相对于其他Redis集群构建方式,哨兵模式需要配置的参数较少,容易上手。

缺点:

  • 性能瓶颈:每个Redis节点都需要有一个哨兵节点,会影响Redis性能。

  • 数据分片:哨兵集群不支持数据的分片,可能导致一些节点存储的数据较多,出现性能瓶颈。

集群模式:

优点:

  • 数据被分成多个片段存储,减少了数据在单个节点上的存储,分摊了负载。

  • 高扩展性:Redis节点在Redis分区模式中可以直接添加或删除,而无需停机。

缺点:

  • 复杂度:分区集群较为复杂,因为它需要大量的Redis节点来存储分区数据,并且这些节点需要进行相当复杂的协调和同步以保持一致性。

  • 节点故障的自动恢复:虽然Redis分区已经支持自动故障恢复,但是仍然有可能发生数据损坏或无法恢复的情况

07 AOF不开启或开启为每秒刷盘

对于能忍受数据丢失的业务系统来说,我想肯定是不开启AOF为好,这样可以不用同步数据到磁盘,减少开销提升性能。如果却要开启,那么建议你最好是配置appendfsync everysec,把同步放后台线程执行,从而降低写磁盘对redis性能的影响.

08 redis的部署方式

redis持久化数据时,使用的是创建子线程的方式进行。创建子线程会使用操作系统的fork,这个操作会比较耗时。虚拟环境下的fork操作会比物理机部署慢很多。所以redis也尽量不要部署到虚拟环境或者容器中,部署在物理机上redis性能也会得到极大的提升。

redis的可靠性

前面有提到,保证redis的高可用是一件很重要的事。防止redis因不可控因素导致的宕机事件导致的系统宕机。所以有必要对redis做一些可靠性的处理。

01 按业务部署

不同模块部署不同redis,比如:用户相关业务,订单相关业务,物流相关业务等。不同的业务我每个给它部署一个redis。这样就算某个redis挂了,也只是影响其中一部分业务,而不会影响到其它。但这种部署资源虽得到了隔离,但成本是会上升的。

02 集群或者哨兵部署

前面有讲解到了,给redis进行集群或者哨兵部署。是redis高可用的两种方式。两种方式都能保证redis的高可用。一个节点挂了,不影响redis的使用。

03 主从复制参数要合理配置

redis集群部署时,参数如果配置不合理,也是会发生问题的:

  • 主从复制中断
  • 从库发起全量复制,主库性能受到影响

合理的 repl-backlog 参数:过小的 repl-backlog 在写流量比较大的场景下,主从复制中断会引发全量复制数据的风险

合理的 slave client-output-buffer-limit:从库复制发生问题时,过小的 buffer 会导致从库缓冲区溢出,从而导致复制中断

redis运维要注意什么

如果你是一名运维人员,那么你也需要注意些redis运维方面的问题

01 系统运行期间禁止执行keys、flushdb、flushall命令

keys命令是模糊搜索命令,是一个极其耗性能的命令。如果在系统运行期间或者高峰时间段执行此命令,极易引起线程的阻塞,从而出现问题。flushdb跟flushall就不说了,直接清空所有。虽说业务可能做了redis读不到就去读redis这些处理。当你可想而知执行了这个命令的后果。

02 从库必须设置slave-read-only

从库必须设置为 slave-read-only 状态,如果不设置,那么可能会导致从库写入数据,从而导致主库从库数据的不一致。除了这个外,从库如果是非slave-read-only 状态,如果你使用的是 4.0 以下的 Redis,它存在这样的 Bug:从库写入了有过期时间的数据,不会做定时清理和释放内存。这会造成从库的内存泄露!这个问题直到 4.0 版本才修复。

03 设置耗时命令记录

记录耗时命令,有助于当redis出现性能问题时,排查耗时命令,好针对性去优化。

  • slowlog-log-slower-than:用于设置记录耗时超过指定微秒数的命令。默认值为10000微秒,即10毫秒。

  • slowlog-max-len:用于限制记录的条数。默认值为128条。

可以通过配置文件的slowlog-log-slower-than参数设置这一限制,要注意单位是微秒(1 000 000 微秒相当于1秒),默认值是10 000。耗时命令日志存储在内存中,可以通过配置文件的 slowlog-max-len 参数来限制记录的条数。

04 maxmemory调整时,注意主库从库顺序

在Redis 5.0 以下版本:从库内存如果超过了 maxmemory,也会触发数据淘汰。在某些场景下,从库是可能优先主库达到 maxmemory 的,那么此时从库开始淘汰数据,主从库就会产生不一致。要想避免此问题,在调整 maxmemory 时,一定要注意主从库的修改顺序:

  • 调大 maxmemory:先修改从库,再修改主库
  • 调小 maxmemory:先修改主库,再修改从库

直到 Redis 5.0,Redis 才增加了一个配置 replica-ignore-maxmemory,默认从库超过 maxmemory 不会淘汰数据,才解决了此问题。

redis安全问题

在当下互联网爆炸的时代,安全问题时无时无刻存在的。DDOS攻击,SQL注入攻击等等。其实redis也是可以被注入脚本进行攻击的。运维在部署或者运维redis时也要注意安全方面的问题。如:

  • Redis 不要部署在公网可访问的服务器
  • 6379默认端口不要使用
  • 把redis部署在普通用户而非root下
  • 限制 Redis 配置文件的目录访问权限
  • 推荐开启密码认证
  • 禁用/重命名危险命令(KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL

redis的监控

针对redis的监控有很多种,如:Prometheus+grafana。监控的指标除了有基本的redis服务内存、磁盘、CPU这几项外。还必须得把redis连接数、slowlog等其它重要指标给监控起来。监控是保证一个系统提前发现问题的有力保证,避免了要出现问题才来手忙脚乱的处理问题。

结尾

总结以上所述,我们看到Redis作为一种高性能的内存数据存储系统,提供了许多强大的功能和灵活的用法。通过遵循最佳实践,我们可以确保Redis的性能、稳定性和可靠性。在设计和实施Redis解决方案时,我们需要充分了解其特性和限制,并考虑到数据安全性、持久性、扩展性和维护性等方面。

通过合理的配置、监控和优化,我们可以充分发挥Redis的优势,为企业和应用程序提供高效、可靠的数据存储和处理服务。最后,我们也要不断学习和探索新的Redis技术和最佳实践,以适应不断变化的应用需求和技术环境。

来源:码农闲谈AI
后端专属技术群

构建高质量的技术交流社群,欢迎从事编程开发、技术招聘HR进群,也欢迎大家分享自己公司的内推信息,相互帮助,一起进步!

文明发言,以交流技术职位内推行业探讨为主

广告人士勿入,切勿轻信私聊,防止被骗

Redis最佳实践:系统性能提升了10倍,真香!

加我好友,拉你进群

原文始发于微信公众号(Java面试题精选):Redis最佳实践:系统性能提升了10倍,真香!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由半码博客整理,本文链接:https://www.bmabk.com/index.php/post/255339.html

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
半码博客——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!