这篇文章我想和你聊一聊 Redis 的最佳实践。你的项目或许已经使用 Redis 很长时间了但在使用过程中你可能还会或多或少地遇到以下问题我的 Redis 内存为什么增长这么快为什么我的 Redis 操作延迟变大了如何降低 Redis 故障发生的频率日常运维 Redis 需要注意什么部署 Redis 时如何做好资源规划Redis 监控重点要关注哪些指标尤其是当你的项目越来越依赖 Redis 时这些问题就变得尤为重要。此时你迫切需要一份「最佳实践指南」。这篇文章我将从以下七个维度带你「全面」分析 Redis 的最佳实践优化内存性能高可靠日常运维资源规划监控安全在文章的最后我还会给你一个完整的最佳实践清单不管你是业务开发人员还是 DBA 运维人员这个清单将会帮助你更加「优雅」地用好 Redis。这篇文章干货很多希望你可以耐心读完。如何使用 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 性能下降。所以你的业务应用尽量不要存储 bigkey避免操作延迟发生。如果你确实有存储 bigkey 的需求你可以把 bigkey 拆分为多个小 key 存储。2) 开启 lazy-free 机制如果你无法避免存储 bigkey那么我建议你开启 Redis 的 lazy-free 机制。4.0版本支持当开启这个机制后Redis 在删除一个 bigkey 时释放内存的耗时操作将会放到后台线程中去执行这样可以在最大程度上避免对主线程的影响。3) 不使用复杂度过高的命令Redis 是单线程模型处理请求除了操作 bigkey 会导致后面请求发生排队之外在执行复杂度过高的命令时也会发生这种情况。因为执行复杂度过高的命令会消耗更多的 CPU 资源主线程中的其它请求只能等待这时也会发生排队延迟。所以你需要避免执行例如 SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 等聚合类命令。对于这种聚合类操作我建议你把它放到客户端来执行不要让 Redis 承担太多的计算工作。4) 执行 O(N) 命令时关注 N 的大小规避使用复杂度过高的命令就可以高枕无忧了么答案是否定的。当你在执行 O(N) 命令时同样需要注意 N 的大小。如果一次性查询过多的数据也会在网络传输过程中耗时过长操作延迟变大。所以对于容器类型List/Hash/Set/ZSet在元素数量未知的情况下一定不要无脑执行 LRANGE key 0 -1 / HGETALL / SMEMBERS / ZRANGE key 0 -1。在查询数据时你要遵循以下原则先查询数据元素的数量LLEN/HLEN/SCARD/ZCARD元素数量较少可一次性查询全量数据元素数量非常多分批查询数据LRANGE/HASCAN/SSCAN/ZSCAN5) 关注 DEL 时间复杂度你没看错在删除一个 key 时如果姿势不对也有可能影响到 Redis 性能。删除一个 key我们通常使用的是 DEL 命令回想一下你觉得 DEL 的时间复杂度是多少O(1) 其实不一定。当你删除的是一个 String 类型 key 时时间复杂度确实是 O(1)。但当你要删除的 key 是 List/Hash/Set/ZSet 类型它的复杂度其实为 O(N)N 代表元素个数。也就是说删除一个 key其元素数量越多执行 DEL 也就越慢原因在于删除大量元素时需要依次回收每个元素的内存元素越多花费的时间也就越久而且这个过程默认是在主线程中执行的这势必会阻塞主线程产生性能问题。那删除这种元素比较多的 key如何处理呢我给你的建议是分批删除List类型执行多次 LPOP/RPOP直到所有元素都删除完成Hash/Set/ZSet类型先执行 HSCAN/SSCAN/SCAN 查询元素再执行 HDEL/SREM/ZREM 依次删除每个元素没想到吧一个小小的删除操作稍微不小心也有可能引发性能问题你在操作时需要格外注意。6) 批量命令代替单个命令当你需要一次性操作多个 key 时你应该使用批量命令来处理。批量操作相比于多次单个操作的优势在于可以显著减少客户端、服务端的来回网络 IO 次数。所以我给你的建议是String / Hash 使用 MGET/MSET 替代 GET/SETHMGET/HMSET 替代 HGET/HSET其它数据类型使用 Pipeline打包一次性发送多个命令到服务端执行7) 避免集中过期 keyRedis 清理过期 key 是采用定时 懒惰的方式来做的而且这个过程都是在主线程中执行。如果你的业务存在大量 key 集中过期的情况那么 Redis 在清理过期 key 时也会有阻塞主线程的风险。想要避免这种情况发生你可以在设置过期时间时增加一个随机时间把这些 key 的过期时间打散从而降低集中过期对主线程的影响。8) 使用长连接操作 Redis合理配置连接池你的业务应该使用长连接操作 Redis避免短连接。当使用短连接操作 Redis 时每次都需要经过 TCP 三次握手、四次挥手这个过程也会增加操作耗时。同时你的客户端应该使用连接池的方式访问 Redis并设置合理的参数长时间不操作 Redis 时需及时释放连接资源。9) 只使用 db0尽管 Redis 提供了 16 个 db但我只建议你使用 db0。为什么呢我总结了以下 3 点原因在一个连接上操作多个 db 数据时每次都需要先执行 SELECT这会给 Redis 带来额外的压力使用多个 db 的目的是按不同业务线存储数据那为何不拆分多个实例存储呢拆分多个实例部署多个业务线不会互相影响还能提高 Redis 的访问性能Redis Cluster 只支持 db0如果后期你想要迁移到 Redis Cluster迁移成本高10) 使用读写分离 分片集群如果你的业务读请求量很大那么可以采用部署多个从库的方式实现读写分离让 Redis 的从库分担读压力进而提升性能。如果你的业务写请求量很大单个 Redis 实例已无法支撑这么大的写流量那么此时你需要使用分片集群分担写压力。11) 不开启 AOF 或 AOF 配置为每秒刷盘如果对于丢失数据不敏感的业务我建议你不开启 AOF避免 AOF 写磁盘拖慢 Redis 的性能。如果确实需要开启 AOF那么我建议你配置为 appendfsync everysec把数据持久化的刷盘操作放到后台线程中去执行尽量降低 Redis 写磁盘对性能的影响。12) 使用物理机部署 RedisRedis 在做数据持久化时采用创建子进程的方式进行。而创建子进程会调用操作系统的 fork 系统调用这个系统调用的执行耗时与系统环境有关。虚拟机环境执行 fork 的耗时要比物理机慢得多所以你的 Redis 应该尽可能部署在物理机上。13) 关闭操作系统内存大页机制Linux 操作系统提供了内存大页机制其特点在于每次应用程序向操作系统申请内存时申请单位由之前的 4KB 变为了 2MB。这会导致什么问题呢当 Redis 在做数据持久化时会先 fork 一个子进程此时主进程和子进程共享相同的内存地址空间。当主进程需要修改现有数据时会采用写时复制Copy On Write的方式进行操作在这个过程中需要重新申请内存。如果申请内存单位变为了 2MB那么势必会增加内存申请的耗时如果此时主进程有大量写操作需要修改原有的数据那么在此期间操作延迟就会变大。所以为了避免出现这种问题你需要在操作系统上关闭内存大页机制。好了以上这些就是 Redis 「高性能」方面的实践优化。如果你非常关心 Redis 的性能问题可以结合这些方面针对性优化。我们再来看 Redis 「可靠性」如何保证。如何保证 Redis 的可靠性这里我想提醒你的是保证 Redis 可靠性其实并不难但难的是如何做到「持续稳定」。下面我会从「资源隔离」、「多副本」、「故障恢复」这三大维度带你分析保障 Redis 可靠性的最佳实践。1) 按业务线部署实例提升可靠性的第一步就是「资源隔离」。你最好按不同的业务线来部署 Redis 实例这样当其中一个实例发生故障时不会影响到其它业务。这种资源隔离的方案实施成本是最低的但成效却是非常大的。2) 部署主从集群如果你只使用单机版 Redis那么就会存在机器宕机服务不可用的风险。所以你需要部署「多副本」实例即主从集群这样当主库宕机后依旧有从库可以使用避免了数据丢失的风险也降低了服务不可用的时间。在部署主从集群时你还需要注意主从库需要分布在不同机器上避免交叉部署。这么做的原因在于通常情况下Redis 的主库会承担所有的读写流量所以我们一定要优先保证主库的稳定性即使从库机器异常也不要对主库造成影响。而且有时我们需要对 Redis 做日常维护例如数据定时备份等操作这时你就可以只在从库上进行这只会消耗从库机器的资源也避免了对主库的影响。3) 合理配置主从复制参数在部署主从集群时如果参数配置不合理也有可能导致主从复制发生问题主从复制中断从库发起全量复制主库性能受到影响在这方面我给你的建议有以下 2 点设置合理的 repl-backlog 参数过小的 repl-backlog 在写流量比较大的场景下主从复制中断会引发全量复制数据的风险设置合理的 slave client-output-buffer-limit当从库复制发生问题时过小的 buffer 会导致从库缓冲区溢出从而导致复制中断4) 部署哨兵集群实现故障自动切换只部署了主从节点但故障发生时是无法自动切换的所以你还需要部署哨兵集群实现故障的「自动切换」。而且多个哨兵节点需要分布在不同机器上实例为奇数个防止哨兵选举失败影响切换时间。以上这些就是保障 Redis「高可靠」实践优化你应该也发现了这些都是部署和运维层的优化。除此之外你可能还会对 Redis 做一些「日常运维」工作这时你要注意哪些问题呢日常运维 Redis 需要注意什么如果你是 DBA 运维人员在平时运维 Redis 时也需要注意以下 6 个方面。1) 禁止使用 KEYS/FLUSHALL/FLUSHDB 命令执行这些命令会长时间阻塞 Redis 主线程危害极大所以你必须禁止使用它。如果确实想使用这些命令我给你的建议是SCAN 替换 KEYS4.0版本可使用 FLUSHALL/FLUSHDB ASYNC清空数据的操作放在后台线程执行2) 扫描线上实例时设置休眠时间不管你是使用 SCAN 扫描线上实例还是对实例做 bigkey 统计分析我建议你在扫描时一定记得设置休眠时间。防止在扫描过程中实例 OPS 过高对 Redis 产生性能抖动。3) 慎用 MONITOR 命令有时在排查 Redis 问题时你会使用 MONITOR 查看 Redis 正在执行的命令。但如果你的 Redis OPS 比较高那么在执行 MONITOR 会导致 Redis 输出缓冲区的内存持续增长这会严重消耗 Redis 的内存资源甚至会导致实例内存超过 maxmemory引发数据淘汰这种情况你需要格外注意。所以你在执行 MONITOR 命令时一定要谨慎尽量少用。4) 从库必须设置为 slave-read-only你的从库必须设置为 slave-read-only 状态避免从库写入数据导致主从数据不一致。除此之外从库如果是非 read-only 状态如果你使用的是 4.0 以下的 Redis它存在这样的 Bug从库写入了有过期时间的数据不会做定时清理和释放内存。这会造成从库的内存泄露这个问题直到 4.0 版本才修复你在配置从库时需要格外注意。5) 合理配置 timeout 和 tcp-keepalive 参数如果因为网络原因导致你的大量客户端连接与 Redis 意外中断恰好你的 Redis 配置的 maxclients 参数比较小此时有可能导致客户端无法与服务端建立新的连接服务端认为超过了 maxclients。造成这个问题原因在于客户端与服务端每建立一个连接Redis 都会给这个客户端分配了一个 client fd。当客户端与服务端网络发生问题时服务端并不会立即释放这个 client fd。什么时候释放呢Redis 内部有一个定时任务会定时检测所有 client 的空闲时间是否超过配置的 timeout 值。如果 Redis 没有开启 tcp-keepalive 的话服务端直到配置的 timeout 时间后才会清理释放这个 client fd。在没有清理之前如果还有大量新连接进来就有可能导致 Redis 服务端内部持有的 client fd 超过了 maxclients这时新连接就会被拒绝。针对这种情况我给你的优化建议是不要配置过高的 timeout让服务端尽快把无效的 client fd 清理掉Redis 开启 tcp-keepalive这样服务端会定时给客户端发送 TCP 心跳包检测连接连通性当网络异常时可以尽快清理僵尸 client fd6) 调整 maxmemory 时注意主从库的调整顺序Redis 5.0 以下版本存在这样一个问题从库内存如果超过了 maxmemory也会触发数据淘汰。在某些场景下从库是可能优先主库达到 maxmemory 的例如在从库执行 MONITOR 命令输出缓冲区占用大量内存那么此时从库开始淘汰数据主从库就会产生不一致。要想避免此问题在调整 maxmemory 时一定要注意主从库的修改顺序调大 maxmemory先修改从库再修改主库调小 maxmemory先修改主库再修改从库直到 Redis 5.0Redis 才增加了一个配置 replica-ignore-maxmemory默认从库超过 maxmemory 不会淘汰数据才解决了此问题。好了以上这些就是「日常运维」Redis 需要注意的你可以对各个配置项查漏补缺看有哪些是需要优化的。接下来我们来看一下保障 Redis「安全」都需要注意哪些问题。Redis 安全如何保证无论如何在互联网时代安全问题一定是我们需要随时警戒的。你可能听说过 Redis 被注入可执行脚本然后拿到机器 root 权限的安全问题都是因为在部署 Redis 时没有把安全风险注意起来。针对这方面我给你的建议是不要把 Redis 部署在公网可访问的服务器上部署时不使用默认端口 6379以普通用户启动 Redis 进程禁止 root 用户启动限制 Redis 配置文件的目录访问权限推荐开启密码认证禁用/重命名危险命令KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL只要你把这些做到位基本上就可以保证 Redis 的安全风险在可控范围内。至此我们分析了 Redis 在内存、性能、可靠性、日常运维方面的最佳实践优化。除了以上这些你还需要做到提前「预防」。如何预防 Redis 问题要想提前预防 Redis 问题你需要做好以下两个方面合理的资源规划完善的监控预警先来说资源规划。在部署 Redis 时如果你可以提前做好资源规划可以避免很多因为资源不足产生的问题。这方面我给你的建议有以下 3 点保证机器有足够的 CPU、内存、带宽、磁盘资源提前做好容量规划主库机器预留一半内存资源防止主从机器网络故障引发大面积全量同步导致主库机器内存不足的问题单个实例内存建议控制在 10G 以下大实例在主从全量同步、RDB 备份时有阻塞风险再来看监控如何做。监控预警是提高稳定性的重要环节完善的监控预警可以把问题提前暴露出来这样我们才可以快速反应把问题最小化。这方面我给你的建议是做好机器 CPU、内存、带宽、磁盘监控资源不足时及时报警任意资源不足都会影响 Redis 性能设置合理的 slowlog 阈值并对其进行监控slowlog 过多及时报警监控组件采集 Redis INFO 信息时采用长连接避免频繁的短连接做好实例运行时监控重点关注 expired_keys、evicted_keys、latest_fork_usec 指标这些指标短时突增可能会有阻塞风险总结好了总结一下这篇文章我带你全面分析了 Redis 最佳实践的优化路径其中包括内存资源、高性能、高可靠、日常运维、资源规划、监控、安全 7 个维度。这里我画成了思维导图方便你在实践时做参考。我还把这些实践优化按照「业务开发」和「运维」两个维度进一步做了划分。并且以「强制」、「推荐」、「参考」3 个级别做了标注这样你在实践优化时就会更明确哪些该做哪些需要结合实际的业务场景进一步分析。这些级别的实施规则如下强制需严格遵守否则危害极大推荐推荐遵守可提升性能、降低内存、便于运维参考根据业务特点参考实施如果你是业务开发人员你需要了解 Redis 的运行机制例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等使用合理的命令并结合业务场景进行优化。如果你是 DBA 运维人员你需要在资源规划、运维、监控、安全层面做到位做到未雨绸缪。后记如果你能耐心地读到这里应该对如何「用好」Redis 有了新的认识。这篇文章我们主要讲的是 Redis 最佳实践对于「最佳实践」这个话题我想再和你多聊几句。如果你面对的不是 Redis而是其它中间件例如 MySQL、Kafka你在使用这些组件时会有什么优化思路吗你也可以沿用这篇文章的这几个维度来分析性能可靠性资源运维监控安全你可以思考一下MySQL 和 Kafka 在这几个维度需要注意哪些问题。另外从学习技能的角度来讲我们在软件开发过程中要尽可能地去思考和探索「最佳实践」的方式。因为只有这样我们才会不断督促自己去思考对自己提出更高的要求做到持续进步。