Redis性能优化和监控服务器搭建那些事儿，边做边调试的实践分享

根据个人实践经验和常见技术博客、官方文档的通用知识整合）

我记得有一次,我们线上的一个服务突然变得特别慢，用户老是抱怨页面转圈圈，查来查去，最后发现是Redis的响应时间偶尔会飙升到几百毫秒，平时可都是零点几毫秒的级别，这事儿让我下定决心，得好好把Redis的性能优化和监控给搞明白，不能总等出了问题再救火，今天分享的，就是我这段时间边做边调试的一些实践。

第一部分：Redis性能优化，从一些简单的配置开始

一开始,我以为优化就得搞那些高大深的东西，后来发现，很多问题其实出在基础配置上，首先就是最大内存设置，Redis默认是无限使用内存，这太危险了，服务器内存一旦用光，操作系统就会开始用硬盘做虚拟内存，那个速度慢得没法看，Redis性能会断崖式下跌，第一件事就是在redis.conf配置文件里，把maxmemory这个参数设置好，比如你服务器有8G内存，可以设个6G或7G，给系统和其他程序留点余地。

光设了最大内存还不够,得告诉Redis内存快满的时候怎么办，这就是内存淘汰策略，配置项叫maxmemory-policy，默认是noeviction，意思是内存不够了就报错，不删除数据，这对大多数业务来说不合适，会导致写不进去数据，我常用的策略是allkeys-lru，意思是尝试回收最近最少使用的键，给新数据腾地方，如果你的数据有些很重要不能删，有些可以删，可以用volatile-lru，它只淘汰那些设置了过期时间的键，这个得根据你的业务特点来选。

另一个容易忽略的是持久化策略,Redis有两种：RDB快照和AOF日志，RDB是隔一段时间拍个全量快照，恢复快，但可能会丢几分钟的数据，AOF是记录每一个写操作，数据更安全，但文件会越来越大，重启恢复慢，生产环境我一般两者都开启，用AOF保证数据安全，同时让Redis自动在后台重写AOF文件，让它不至于太大，在配置文件里，把appendonly改成yes，然后调整appendfsync参数，我一般用everysec，每秒同步一次，在性能和数据安全之间取个平衡，如果对性能要求极高，可以设成no，让操作系统决定何时同步，但丢数据的风险会大一点。

第二部分：搭建监控，眼睛要亮起来

优化了配置,不代表就高枕无忧了，你得知道Redis实时在干什么，这就需要监控，我一开始用INFO命令，敲进去能出来一大堆信息，什么内存使用情况、连接数、命中率、持久化状态等等，但这个太临时了，不能看趋势。

后来我就自己搭了一套监控,核心是Prometheus，一个现在很流行的监控系统，得让Redis能暴露指标给Prometheus，Redis本身不直接支持Prometheus的格式，需要用一个叫redis_exporter的小工具，这个工具会去连上你的Redis实例，然后执行INFO命令，把结果转换成Prometheus能识别的格式，并通过一个HTTP端口暴露出来。

部署redis_exporter很简单，下载下来直接运行，告诉它你的Redis地址和端口就行了。./redis_exporter -redis.addr localhost:6379，它默认会在9100端口提供一个/metrics的地址，你用浏览器打开这个地址，就能看到一堆带数字的文本，那就是监控数据。

在Prometheus的配置文件里,添加一个抓取任务，让它每隔一段时间（比如15秒）去拉取redis_exporter暴露的数据，这样，Prometheus就有了Redis的时序数据。

光有数据还不够,得有图表看才直观，我用了Grafana这个可视化工具，Grafana可以连接Prometheus作为数据源，然后就是去Grafana的官网找一个现成的Redis监控仪表盘模板，导入进去，一瞬间，漂亮的图表就出来了：内存使用量曲线、连接数变化、命令执行次数、键的命中率（这个超重要，命中率低说明很多请求没找到数据，可能缓存设的有问题）等等，这样，Redis的健康状况就一目了然了。

第三部分：边做边调试，遇到的实际问题

在搭建和看监控的过程中,还真发现了问题，有一次，Grafana图表上显示网络输入流量突然变得异常高，但业务量并没增加，顺着这个线索查，发现是有一个后台脚本在频繁地执行KEYS *这个命令，这个命令在生产环境是绝对要避免的，因为它会阻塞Redis，遍历所有键，键一多就会导致其他命令卡住，我立刻联系开发同学，把脚本里的KEYS *换成了SCAN，SCAN是非阻塞的，虽然慢点，但不会影响服务，这就是监控带来的好处，能让你在用户感知到问题前就发现异常。

还有一次,监控报警说内存使用率持续快速增长，眼看就要触发淘汰策略了，通过分析图表，发现是某种缓存数据设置了过期时间，但过期时间设得太长了，而且这种数据增长很快，我们调整了缓存策略，对一些不重要的数据缩短了过期时间，并引入了更细粒度的缓存淘汰逻辑，避免了内存被快速打满的风险。

我的体会是,Redis的优化和监控不是一劳永逸的，先打好基础，做好关键配置，然后一定要把监控搭起来，让系统变得可见，要持续观察监控数据，结合业务变化，不断地进行调整和优化，这个过程，就是一个边做边学、边调试边完善的实践循环。