Redis配置和版本那些事儿，得知道的要点和常见坑解析

说到Redis，配置和版本是绕不开的两个话题，搞不好就会踩坑，这些东西不用说得太专业，就聊聊实际中咱们得知道些什么，以及怎么避开那些常见的“雷区”。

第一部分：版本选择，不是越新越好

很多人有个误区，觉得软件版本越新越好，功能越强，bug越少，但对Redis来说，真不是这样，尤其是在生产环境,稳定压倒一切。

根据Redis官方文档和社区的一般建议，你应该选择长期支持版本，什么是长期支持版本？就是版本号中间那个数字是偶数的，6.2、6.0、5.0，这些版本经过了更长时间的测试和打磨，社区支持周期也长，发现的重大问题基本都有修复，而奇数版本，像 7.1、6.3 这些，属于开发分支，虽然包含了最新特性，但可能不够稳定,更适合测试环境尝鲜。

《Redis实战》这本书里也提到，升级版本前，一定要在测试环境充分验证你的应用是否兼容，从 5.0 升级到 6.0，虽然主版本号没变，但可能某些命令的返回值格式或者配置项的行为发生了细微变化，你的应用程序如果没有考虑到，就可能出错。别急着追新，选个稳定的LTS版本，然后阅读官方的Release Notes（版本发布说明），了解变更点,这才是稳妥的做法。

第二部分：内存配置，核心中的核心

Redis是内存数据库，所以内存配置是重中之重，第一个关键配置是 maxmemory，它决定了Redis实例最多能用多少内存，这个必须设置，不能让它无限制地用下去，否则你的服务器内存被撑爆，会导致整个服务器宕机,那问题就大了。

设定了最大内存之后，还得告诉Redis当内存用满时该怎么办，这就是 maxmemory-policy 策略，常见的坑就是用了默认策略 noeviction，这个策略的意思是“不淘汰”，当内存满了，所有试图写入的命令都会报错，对于很多需要持续写入的场景，这简直是灾难,会造成服务不可用。

你得根据业务特点选策略，如果你能接受淘汰一些旧数据，allkeys-lru（淘汰最近最少使用的任意键）或 volatile-lru（只淘汰设置了过期时间的键中最近最少使用的）可能更合适，这个选择很重要，一旦选错，可能把重要的热点数据给淘汰了，导致缓存击穿，直接压垮后端的数据库，很多运维经验分享中都强调，一定要在压力测试中模拟内存打满的情况,观察淘汰策略是否符合预期。

第三部分：持久化配置，数据安全的生命线

Redis的数据在内存里，断电就没了，所以要把数据存到硬盘上，这个过程叫持久化，Redis主要有两种方式：RDB和AOF。

RDB 像是给内存数据拍个快照，文件小，恢复快，但坑在于，如果在你两次快照之间服务器宕机，那么这期间的数据就丢失了，配置 save 900 1 表示900秒内至少有1个键被改动就拍快照，这个频率需要权衡：频率太高伤磁盘IO,频率太低丢数据多。

AOF 像是写日志，把每个写命令都记录下来，数据安全性高，最多丢一秒的数据（如果配置为 appendfsync everysec），但坑是AOF文件会越来越大，恢复起来慢，而且如果突然断电，AOF文件可能会损坏，这时候就需要用到Redis自带的 redis-check-aof 工具来修复,但这个修复过程并不总是完美的。

最保险的方式是同时开启RDB和AOF，这样既可以利用RDB快速恢复，又能利用AOF保证更高的数据安全性,这也是很多线上环境的标配做法。

第四部分：网络和安全配置，别让后院起火

早期Redis为了追求极致性能，默认是没有密码的，而且默认只监听127.0.0.1，这是个巨大的安全漏洞,意味着任何能连接到你这台服务器的人都可以随意访问你的Redis数据。

requirepass 配置项一定要设置一个强密码。bind 配置项要谨慎，如果不确定，最好就绑定内网IP，不要直接绑定公网IP，在云服务上，还要结合安全组策略来限制访问源，因为Redis设计之初并非为暴露在公网环境下，如果暴露且无认证，极易被黑客入侵用来挖矿或删库,这种案例在网络上比比皆是。

第五部分：其他常见小坑

1. keys 命令的陷阱：keys * 这个命令会遍历所有键，在生产环境数据量大的时候，执行它会直接导致Redis暂时卡死，所有其他命令都要等着，应该用 scan 命令来替代,它不会阻塞服务。
2. 内存碎片化：Redis用久了，内存会碎片化，明明有空闲内存，但就是无法分配，需要关注 info memory 命令输出中的 mem_fragmentation_ratio（内存碎片率），如果过高（比如持续大于1.5），可能需要重启实例或者尝试使用Redis 4.0以上版本的 memory purge 命令（不保证有效）来清理。
3. 超时设置：timeout 配置项表示客户端空闲多少秒后断开连接，默认是0，即不断开，如果客户端很多，可能会产生大量闲置连接，占用文件描述符资源，设置一个合理的超时时间（比如300秒）是很好的习惯。

玩转Redis配置和版本，关键在于理解你的业务场景：对数据丢失的容忍度、对性能的要求、对安全性的考量，然后结合官方文档和社区的最佳实践，去做有针对性的配置和测试，而不是一味地用默认配置或追求最新版本，这样才能让Redis真正稳定、高效地为你服务。