阅读本文大约需要 16 分钟。
大家好，这里是 Java后端。
这篇文章我想和你聊一聊 Redis 的最佳实践。
你的项目或许已经使用 Redis 很长时间了，但在使用过程中，你可能还会或多或少地遇到以下问题：
我的 Redis 内存为什么增长这么快？
为什么我的 Redis 操作延迟变大了？
如何降低 Redis 故障发生的频率？
日常运维 Redis 需要注意什么？
部署 Redis 时，如何做好资源规划？
Redis 监控重点要关注哪些指标？
尤其是当你的项目越来越依赖 Redis 时，这些问题就变得尤为重要。
此时，你迫切需要一份「最佳实践指南」。
这篇文章，我将从以下七个维度，带你「全面」分析 Redis 的最佳实践优化：
内存
性能
高可靠
日常运维
资源规划
监控
安全
在文章的最后，我还会给你一个完整的最佳实践清单，不管你是业务开发人员，还是 DBA 运维人员，这个清单将会帮助你更加「优雅」地用好 Redis。
这篇文章干货很多，希望你可以耐心读完。
首先，我们来看一下 Redis 内存方面的优化。
众所周知，Redis 的性能之所以如此之高，原因就在于它的数据都存储在「内存」中，所以访问 Redis 中的数据速度极快。
但从资源利用率层面来说，机器的内存资源相比于磁盘，还是比较昂贵的。
当你的业务应用在 Redis 中存储数据很少时，你可能并不太关心内存资源的使用情况。但随着业务的发展，你的业务存储在 Redis 中的数据就会越来越多。
如果没有提前制定好内存优化策略，那么等业务开始增长时，Redis 占用的内存也会开始膨胀。
所以，提前制定合理的内存优化策略，对于资源利用率的提升是很有必要的。
那在使用 Redis 时，怎样做才能更节省内存呢？这里我给你总结了 6 点建议，我们依次来看：
1) 控制 key 的长度
最简单直接的内存优化，就是控制 key 的长度。
在开发业务时，你需要提前预估整个 Redis 中写入 key 的数量，如果 key 数量达到了百万级别，那么，过长的 key 名也会占用过多的内存空间。
所以，你需要保证 key 在简单、清晰的前提下，尽可能把 key 定义得短一些。
例如，原有的 key 为 user:book:123，则可以优化为 u:bk:123。
这样一来，你的 Redis 就可以节省大量的内存，这个方案对内存的优化非常直接和高效。
2) 避免存储 bigkey
除了控制 key 的长度之外，你同样需要关注 value 的大小，如果大量存储 bigkey，也会导致 Redis 内存增长过快。
除此之外，客户端在读写 bigkey 时，还有产生性能问题（下文会具体详述）。
所以，你要避免在 Redis 中存储 bigkey，我给你的建议是：
String：大小控制在 10KB 以下
List/Hash/Set/ZSet：元素数量控制在 1 万以下
3) 选择合适的数据类型
Redis 提供了丰富的数据类型，这些数据类型在实现上，也对内存使用做了优化。具体来说就是，一种数据类型对应多种数据结构来实现：
例如，String、Set 在存储 int 数据时，会采用整数编码存储。Hash、ZSet 在元素数量比较少时（可配置），会采用压缩列表（ziplist）存储，在存储比较多的数据时，才会转换为哈希表和跳表。
作者这么设计的原因，就是为了进一步节约内存资源。
那么你在存储数据时，就可以利用这些特性来优化 Redis 的内存。这里我给你的建议如下：
String、Set：尽可能存储 int 类型数据
Hash、ZSet：存储的元素数量控制在转换阈值之下，以压缩列表存储，节约内存
4) 把 Redis 当作缓存使用
Redis 数据存储在内存中，这也意味着其资源是有限的。你在使用 Redis 时，要把它当做缓存来使用，而不是数据库。
所以，你的应用写入到 Redis 中的数据，尽可能地都设置「过期时间」。
业务应用在 Redis 中查不到数据时，再从后端数据库中加载到 Redis 中。
采用这种方案，可以让 Redis 中只保留经常访问的「热数据」，内存利用率也会比较高。
5) 实例设置 maxmemory 淘汰策略
虽然你的 Redis key 都设置了过期时间，但如果你的业务应用写入量很大，并且过期时间设置得比较久，那么短期间内 Redis 的内存依旧会快速增长。
如果不控制 Redis 的内存上限，也会导致使用过多的内存资源。
对于这种场景，你需要提前预估业务数据量，然后给这个实例设置 maxmemory 控制实例的内存上限，这样可以避免 Redis 的内存持续膨胀。
配置了 maxmemory，此时你还要设置数据淘汰策略，而淘汰策略如何选择，你需要结合你的业务特点来决定：
volatile-lru / allkeys-lru：优先保留最近访问过的数据
volatile-lfu / allkeys-lfu：优先保留访问次数最频繁的数据（4.0 版本支持）
volatile-ttl ：优先淘汰即将过期的数据
volatile-random / allkeys-random：随机淘汰数据
6) 数据压缩后写入 Redis
以上方案基本涵盖了 Redis 内存优化的各个方面。
如果你还想进一步优化 Redis 内存，你还可以在业务应用中先将数据压缩，再写入到 Redis 中（例如采用 snappy、gzip 等压缩算法）。
当然，压缩存储的数据，客户端在读取时还需要解压缩，在这期间会消耗更多 CPU 资源，你需要根据实际情况进行权衡。
以上就是「节省内存资源」方面的实践优化，是不是都比较简单？
下面我们来看「性能」方面的优化。
如何持续发挥 Redis 的高性能？当你的系统决定引入 Redis 时，想必看中它最关键的一点就是：性能。
我们知道，一个单机版 Redis 就可以达到 10W QPS，这么高的性能，也意味着如果在使用过程中发生延迟情况，就会与我们的预期不符。
所以，在使用 Redis 时，如何持续发挥它的高性能，避免操作延迟的情况发生，也是我们的关注焦点。
在这方面，我给你总结了 13 条建议：
1) 避免存储 bigkey
存储 bigkey 除了前面讲到的使用过多内存之外，对 Redis 性能也会有很大影响。
由于 Redis 处理请求是单线程的，当你的应用在写入一个 bigkey 时，更多时间将消耗在「内存分配」上，这时操作延迟就会增加。同样地，删除一个 bigkey 在「释放内存」时，也会发生耗时。
而且，当你在读取这个 bigkey 时，也会在「网络数据传输」上花费更多时间，此时后面待执行的请求就会发生排队，Redis 性能下降。
