总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 码农闲谈AI 「码农闲谈AI」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

前言

在当今互联网项目中，几乎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的过程中，应该尽量不要使用SORT、SINTERSTORE、SINTER等这些聚合的命令。

03 多使用批量命令

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

使用 MGET/MSET 替代 GET/SET，HMGET/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技术和最佳实践，以适应不断变化的应用需求和技术环境。

文章目录
  1. 1. 前言
  2. 2. 最佳实战
    1. 2.1. redis怎么使用内存更优
      1. 2.1.1. 01 key的长度必须
      2. 2.1.2. 02 注意bigkey的存储
      3. 2.1.3. 03 根据业务选择合适redis数据类型存储
      4. 2.1.4. 04 不要把redis当数据库使用
    2. 2.2. 如何最大的发挥redis的性能优势
      1. 2.2.1. 01 千说万说还是bigkey
      2. 2.2.2. 02 复杂度过高命令不使用
      3. 2.2.3. 03 多使用批量命令
      4. 2.2.4. 04 key过期时间设置不要太集中
      5. 2.2.5. 05 合理的使用redis线程池
      6. 2.2.6. 06 使用读写分离或者集群
        1. 2.2.6.1. 哨兵模式：
        2. 2.2.6.2. 集群模式：
      7. 2.2.7. 07 AOF不开启或开启为每秒刷盘
      8. 2.2.8. 08 redis的部署方式
    3. 2.3. redis的可靠性
      1. 2.3.1. 01 按业务部署
      2. 2.3.2. 02 集群或者哨兵部署
      3. 2.3.3. 03 主从复制参数要合理配置
    4. 2.4. redis运维要注意什么
      1. 2.4.1. 01 系统运行期间禁止执行keys、flushdb、flushall命令
      2. 2.4.2. 02 从库必须设置slave-read-only
      3. 2.4.3. 03 设置耗时命令记录
      4. 2.4.4. 04 maxmemory调整时，注意主库从库顺序
    5. 2.5. redis安全问题
    6. 2.6. redis的监控
  3. 3. 结尾