当前位置：首页 > 问答 > 正文

Redis维护那些事儿，技巧用好了运行才稳，别忽视细节啊

综合参考自知乎专栏“Redis实战精讲”、博客园“高可用架构”以及部分云服务商（如阿里云、腾讯云）的技术实践文档）

Redis这东西,用起来是真爽，速度飞快，但要是觉得搭起来就一劳永逸，那可就大错特错了，它就像一辆高性能跑车，你得定期保养，注意驾驶习惯，不然说不定哪天就在高速上抛锚了，下面就来聊聊那些日常维护中不能忽视的事儿，把技巧用好了，Redis才能稳稳当当地为你服务。

第一件事：内存是命根子，时刻得盯着

Redis的所有数据都放在内存里,内存满了可是最要命的故障，你不能等到报警响了才手忙脚乱。

别让内存悄悄撑爆： 一定要设置最大内存限制（maxmemory），不然，Redis会一直吃内存，直到把服务器拖垮，这个值不能设成和物理内存一样大，得给操作系统和其他程序留点余地。
过期策略要选对： 设置了maxmemory之后，还得告诉Redis内存满了之后怎么办，这就是淘汰策略（maxmemory-policy），常用的有volatile-lru（从设置了过期时间的键中，淘汰最近最少使用的）和allkeys-lru（从所有键中淘汰最近最少使用的），如果你不清楚哪些键重要，用allkeys-lru通常比较稳妥，千万别用noeviction（不淘汰，直接报错），除非你的业务能接受写请求失败。
警惕“内存碎片”： 数据频繁修改、删除后，内存会留下很多“小空洞”，这就是内存碎片，碎片率太高（比如info memory命令查出的mem_fragmentation_ratio远大于1.5）会导致实际可用内存变小，即使看起来还有空间，也可能因为找不到一块连续的空间而写入失败，定期重启Redis实例是解决高碎片最直接（但有点粗暴）的办法，或者尝试使用MEMORY PURGE命令（如果支持的话）。

第二件事：持久化不是开了就行，得看看有没有生效

Redis虽然快,但数据在内存里，一断电就没了，所以得靠持久化把数据存到硬盘上，主要有两种方式：RDB和AOF。

RDB（快照）： 相当于在某个时间点给数据拍张完整的照片，恢复起来快，但可能会丢失最后一次快照之后的数据，关键技巧是：别在高峰期做快照！尤其是用save命令触发同步保存，会导致Redis阻塞，线上服务会卡住，建议用bgsave命令在后台异步执行。
AOF（日志）： 把每一个写命令都记录下来，数据安全性高，最多丢失一秒的数据（如果配置为appendfsync everysec），但AOF文件会越来越大，重启恢复速度慢，一定要开启AOF重写机制！Redis会自动在后台把陈旧的、无效的命令清理掉，生成一个更小的AOF文件，相当于给日志“瘦身”，要检查重写是否在正常运行。
最保险的组合拳： 很多线上系统会同时开启RDB和AOF，用RDB做冷备份，恢复速度快；用AOF保证数据完整性，这样即使AOF文件出问题了，至少还有个RDB备份可以兜底。

第三件事：别让慢查询拖垮整个服务

Redis是单线程的,意味着同一时间只能干一件事，如果一个命令执行得太慢（比如keys *，或者对一个大集合做操作），后面的所有命令都得等着，这就是“慢查询”的可怕之处。

一定要设置慢查询日志： 通过slowlog-log-slower-than参数（单位微秒，比如10000表示10毫秒）来定义什么是“慢”，一旦有命令超过这个阈值，就会被记录到慢查询日志里，可以通过slowlog get命令查看。
定期分析慢日志： 看看是哪些命令慢，为什么慢，是不是用了keys？是不是某个集合的元素太多了？找到根源，优化业务代码，比如用scan代替keys，把大集合拆小。

第四件事：网络和安全，细节决定成败

连接数别超限： Redis有最大连接数限制（maxclients），如果客户端使用完连接不关闭，会导致连接泄露，最终新的请求无法连接，要监控连接数变化，确保客户端使用了连接池并且配置合理。
密码不能省： 千万别把Redis直接暴露在公网上还不设密码（requirepass），这等于把大门敞开，数据分分钟被删光或者被挖矿，设置一个强密码是最基本的安全措施。
警惕大Key和热Key： “大Key”是指一个key对应的value非常大（比如一个list里有百万个元素），操作它非常耗时，会阻塞其他请求。“热Key”是指某个key被频繁访问，可能会打爆单台Redis服务器的性能上限，这需要从业务设计上避免，比如把大Key拆解，对热Key做本地缓存或者做读写分离。

第五件事：监控和报警，你的眼睛和耳朵

人不能24小时盯着Redis,所以必须有一套监控系统。