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的过程中，应该尽量不要使用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 版本才修复。