前言
在当今互联网项目中，几乎80%的的项目都有使用redis。但在其应用过程中，总是或多或少遇到过一些问题。比如：
- redis内存为什么会增长这么快？
- redis为什么读取操作越来越慢？
- 怎么样降低redis故障的频率？
- redis的运维需要注意些什么？
- redis部署时，如何做好资源使用的规划？
- 对redis的监控应该要注意哪些指标？
特别是当你的应用对redis非常依赖的前提下，那么这些问题就显得尤为突出。
那么这个时候，这时候需要对redis的使用有一份最佳实践文档来助你轻松管理redis。下面就将以7个维度，全面解析redis的最佳使用及优化：
【内存、性能、高可靠、日常运维、资源控制、redis监控及安全】
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
- 视频教程：https://doc.iocoder.cn/video/
最佳实战
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等其它重要指标给监控起来。监控是保证一个系统提前发现问题的有力保证，避免了要出现问题才来手忙脚乱的处理问题。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
- 项目地址：https://github.com/YunaiV/yudao-cloud
- 视频教程：https://doc.iocoder.cn/video/
结尾
总结以上所述，我们看到Redis作为一种高性能的内存数据存储系统，提供了许多强大的功能和灵活的用法。通过遵循最佳实践，我们可以确保Redis的性能、稳定性和可靠性。在设计和实施Redis解决方案时，我们需要充分了解其特性和限制，并考虑到数据安全性、持久性、扩展性和维护性等方面。
通过合理的配置、监控和优化，我们可以充分发挥Redis的优势，为企业和应用程序提供高效、可靠的数据存储和处理服务。最后，我们也要不断学习和探索新的Redis技术和最佳实践，以适应不断变化的应用需求和技术环境。
