Redis配置那些事儿，聊聊怎么调才能跑得更快点吧

Redis这个东西,说白了就是个速度超快的“大本子”，我们经常用它来存一些临时数据，比如登录的验证码、网站的会话信息，或者一些热点数据，免得每次都去慢吞吞的查数据库，但你要是完全不管它，就用默认设置，那它可能就跑不出应有的速度，甚至有时候会给你惹麻烦，今天咱们就聊点实在的，怎么通过一些配置上的调整，让Redis这个“快马”跑得更稳、更快。

咱们得说说内存这事儿,Redis把所有数据都放在内存里，所以内存是它最宝贵的资源，默认配置可能不太关心内存满了之后怎么办，但这事儿你必须得管，在配置文件里，有个叫 maxmemory 的参数，你得根据你服务器的实际内存大小给它设个限，比如你机器有8G内存，留给Redis 6G，那就设成 6gb，光设了上限还不行，还得告诉它内存满了之后怎么办，这就是 maxmemory-policy 策略。

（来源：Redis官方文档关于内存管理的章节）这里有几种常见的策略：volatile-lru 是只对那些设置了过期时间的数据进行清理，挑最近最少用的扔掉；allkeys-lru 是不管有没有设过期时间，从所有键里挑最近最少用的扔掉，这个比较常用；如果你的数据非常重要，不允许丢失，那可以用 noeviction 策略，意思是内存一满，任何写操作都会报错，读操作还能用，选哪个策略，得看你的业务场景，是速度优先还是数据绝对不能丢。

持久化是个大学问,Redis虽然快，但因为数据在内存里，一断电就全没了，所以它提供了两种方式把数据写到硬盘上，相当于给数据上了个保险，一种是RDB，可以理解为在某个时间点给内存数据拍个快照；另一种是AOF，是把你所有写操作命令都记录在一个日志文件里。

（来源：Redis持久化机制详解）RDB的优点是恢复大数据集时速度很快，文件也比较紧凑，你可以通过 save 配置项来设置拍快照的条件，save 900 1 表示900秒内至少有1个键被改动就拍一次，但缺点是可能会丢失最后一次快照之后的数据，AOF的优点是数据安全性高，默认是每秒同步一次（appendfsync everysec），最多丢一秒的数据，你可以设成 always（每次写命令都同步，最安全但最慢）或 no（让操作系统决定，最快但可能丢更多数据），缺点是AOF文件会越来越大，恢复起来也慢。

那该怎么选呢？通常的建议是两者都开启，用AOF来保证数据安全，用RDB来做冷备份和快速恢复，你可以通过配置 aof-use-rdb-preamble yes 来开启混合持久化（Redis 4.0以后支持），这样AOF文件里既包含RDB格式的快照，又包含后续的AOF日志，兼顾了恢复速度和数据安全性。

再来聊聊网络和连接方面的优化,Redis是单线程处理命令的，所以它怕的不是复杂的操作，而是大量的慢查询或者连接数太多把线程堵住了。timeout 参数可以设置客户端空闲多少秒后关闭连接，释放资源，比如设成300秒，避免连接数被不用的客户端占满。tcp-keepalive 参数可以定时向客户端发送探测包，检查连接是否还健康，避免因为网络问题导致“僵尸连接”。

对于慢查询,一定要开启慢日志功能，通过 slowlog-log-slower-than 设置一个阈值，比如10000微秒（10毫秒），超过这个时间的命令就会被记录下来，然后通过 slowlog max-len 设置最多记录多少条，定期检查慢日志，你会发现哪些命令是性能瓶颈，比如是不是用了 KEYS * 这种全库扫描的命令，或者是不是某个复杂查询拖慢了整体速度。

还有一些零碎但很实用的点,如果你用的是Linux系统，记得要调整操作系统的内存分配策略，把 vm.overcommit_memory 设为1，这样可以避免Redis在持久化时因为申请内存失败而崩溃。（来源：Redis安装与部署的注意事项）还有，如果Redis实例很大，在重启加载数据时可能会耗时很长，可以尝试开启 activerehashing 让Rehash操作分批次、渐进式地进行，避免服务器长时间卡顿。

调优Redis没有一劳永逸的“万能配置”，关键是要理解每个参数背后的含义，然后结合你自己的业务特点——比如是读多还是写多，数据能容忍丢失多少，对响应时间的要求有多苛刻——来做出最适合你的调整，最好的方法就是先在测试环境里多试试，用 redis-benchmark 工具压测一下，看看效果再上线，希望这些实实在在的点儿，能帮你把Redis这匹快马驯服得更好。