Redis配置那些事儿，聊聊性能能不能再提升点

说到Redis配置,很多人觉得就是把安装包解压，然后直接redis-server就完事儿了，这确实能跑起来，但要是想让Redis在你的服务器上真正跑得飞快，像跑车上了赛道而不是像拖拉机走在乡间小路，那就得花点心思在配置上了，性能这东西，绝对不是靠默认设置就能达到最佳的，它跟你家的Wi-Fi一样，需要根据你房子的结构和设备数量来调一调信道和位置。

咱们得聊聊Redis把数据存到磁盘这个事儿,也就是所谓的持久化，这是影响性能和数据安全最关键的配置之一，Redis主要有两种方式：RDB和AOF。

RDB就像是给数据库拍一张快照，在某个时间点，把内存里所有的数据整个打包成一个文件（dump.rdb），这个操作是由子进程来完成的，所以理论上不会阻塞主进程处理客户端的请求，性能影响相对较小，如果数据量特别大，创建子进程和写磁盘的瞬间，还是可能会引起短暂的停顿，它的缺点是可能会丢失最后一次快照之后的数据，配置里save 900 1这种参数，意思就是900秒内至少有1个key发生变化，就触发一次快照，你可以根据你对数据丢失的容忍度来调整，比如改成save 300 10，就是5分钟内有10个变化就存一次，这样数据更安全点，但写磁盘会频繁一些。

AOF则像是记日记，它会把每一个写命令都记录下来，追加到一个文件里，这样即使服务器宕机，重启后把日记重新执行一遍，数据就恢复了，AOF的数据安全性高很多，最多丢失一秒的数据（如果配置为appendfsync everysec），但代价就是，这个文件会不断变大，而且写操作的频率非常高，对磁盘IO的压力比RDB大，Redis提供了一个AOF重写机制，可以压缩这个日志文件，但这个重写过程本身也是比较耗资源的。

怎么选？根据资料（比如Redis官方文档和许多实践博客都提到），如果你对数据安全要求极高，不能容忍任何数据丢失，可以同时开启RDB和AOF，如果追求极致的性能，能容忍几分钟的数据丢失，可以只用RDB，如果是个折中的方案，可以只用AOF，并设置appendfsync everysec，这就是一个典型的性能与安全性的权衡。

内存管理也是个重头戏,Redis是内存数据库，内存用完了可就麻烦了，默认情况下，内存满了之后，再写入新数据就会报错，这显然不是我们想要的，所以你得配置一个“驱逐策略”，就是当内存不够时，决定扔掉哪些旧数据来腾地方。

配置项是maxmemory-policy，这里有几种常见的策略，

• allkeys-lru：从所有key中，挑最近最少使用的那个淘汰掉，这是比较通用和推荐的一种。
• volatile-lru：只从设置了过期时间的key里淘汰。
• allkeys-random：随机淘汰。
• noeviction：不淘汰，直接报错（默认值）。

根据资料（像阿里云、腾讯云的技术文章都建议），在生产环境，一定要设置maxmemory并且选择一个合适的驱逐策略，比如allkeys-lru，避免内存撑爆导致服务不可用，这直接决定了你的Redis在压力下的行为是优雅降级还是直接崩溃。

然后说说网络相关的配置。tcp-keepalive这个参数，默认是300秒，它的作用是检测死连接，如果设置得太小，可能会误杀一些空闲连接；如果设置得太大，可能一个客户端异常掉线了，服务器端还要等很久才能发现，这个连接资源就一直被占着，保持默认或适当调小一点都可以。

还有一个容易被忽略但很重要的参数是timeout，它表示客户端空闲多少秒后服务器就关闭连接，默认是0，意思是不自动关闭，如果你的客户端很多，且连接管理不善，会有大量闲置的“僵尸连接”占用着文件描述符资源，设置一个合理的超时时间，比如300秒（5分钟），可以帮助自动清理这些连接，释放资源。

聊聊一些“隐藏”的优化点，如果Redis跑在Linux上，可以调整操作系统的内核参数，有一个叫vm.overcommit_memory的参数，最好设置为1，这是为啥呢？因为如果这个值是0，当Redis做RDB持久化，需要fork子进程的时候，如果系统内存紧张，fork可能会失败，设置成1可以避免这个问题，这个技巧在很多运维经验分享里都被重点强调。

如果Redis实例占用内存很大（比如几十个GB），fork子进程可能会因为需要复制父进程的内存页表而变得很慢，导致服务停顿，这时，可以考虑使用物理机而不是虚拟机，因为虚拟机的内存管理开销更大，或者，如果条件允许，将主从复制和持久化任务放在从库上执行，减轻主库的压力。

Redis的性能提升不是一个开关就能解决的,它是一个系统工程，你需要像老中医一样，根据你的业务特点（是读多写少还是写多读少？数据量多大？对数据一致性要求多高？），结合监控数据（慢查询日志、内存使用率、命令耗时等），对你的“药方”——也就是配置文件，进行持续的观察和调整，从持久化策略到内存驱逐，从网络连接到操作系统，每一个环节都可能成为瓶颈，也都有优化的空间，多看看官方文档和社区里大家的实践经验（这些都可以作为参考来源），动手试一试，才能让你的Redis真正健步如飞。