本地跑Redis性能测试，看看压测结果咋样，顺便调调参数试试

前两天我琢磨着，自己机器上跑的Redis服务，性能到底咋样？光知道它快，但没个具体数，心里不踏实，于是就想着，干脆自己动手压测一下，看看这Redis在我这老伙计电脑上能跑出个什么水平，顺便再捣鼓捣鼓配置参数,看能不能让它再精神点儿。

要压测Redis，首先得有个工具，Redis官方就很贴心地自带了一个叫redis-benchmark的家伙，就在Redis的安装目录下，开箱即用，特别方便，我就不用去折腾那些复杂的第三方工具了，这个工具的基本用法很简单，就是指定个命令，比如SET或者GET，然后它就会哐哐哐地往Redis里塞数据或者取数据，最后告诉你每秒能处理多少个请求（QPS）、延迟是多少这些关键信息。

我先来个最基础的试试水，打开命令行，cd到Redis的src目录下，直接输入命令：./redis-benchmark -q，这个-q参数意思是安静模式，不让它输出每一轮测试的过程，只给我看最终结果，清爽，命令一执行，它就按照默认参数开始折腾了：用50个客户端连接，不停地发请求，测试PING_INLINE、SET、GET这些基本命令。

结果唰一下就出来了，我盯着屏幕看，SET命令的QPS大概在8万5千左右，GET命令更高一点，接近9万，这个数字听起来挺唬人，但我知道这是在最理想的情况下测出来的，没任何干扰，而且它用的数据包很小（默认是3个字节），现实中的业务数据可比这大得多，延迟方面，平均下来在0.5毫秒左右，绝大部分请求都在1毫秒内完成了,确实快得飞起。

光看默认测试不过瘾，我得模拟点更真实的场景，我想看看如果用100个并发连接，专门测试SET和GET命令，数据包大小设为1KB，持续压个30秒，会是什么效果，命令就得复杂点了：./redis-benchmark -q -c 100 -t set,get -d 1024 -n 1000000 --csv，这里-c 100指定100个并发，-t set,get只测试这两个命令，-d 1024把数据大小设为1024字节（1KB），-n 1000000是总请求数设大点，差不多能跑一会儿，最后的--csv是让结果用逗号分隔,方便我后期整理。

跑起来之后，能感觉到风扇开始呼呼转了，结果出来，QPS果然降了不少，SET大概在5万左右，GET在6万上下，这是因为数据包变大了，网络传输和Redis处理都需要更多时间，平均延迟也涨到了2毫秒左右，这个数据就显得真实多了,让我对Redis在处理稍大一点数据时的表现有了底。

测完了默认性能，手痒痒，想试试调参，Redis的配置文件是redis.conf，里面参数一大堆，我决定先挑两个常见的试试水，一个是maxmemory，我机器内存大，之前没设限制，这次我设个1G看看（maxmemory 1gb），另一个是内存淘汰策略maxmemory-policy，默认是noeviction（内存满了就报错，不删数据），我把它改成allkeys-lru，意思是内存不够时,淘汰最近最少使用的键。

改完配置，重启Redis服务，再用同样的参数压测一次，咦？QPS和延迟好像没啥明显变化，想想也是，我压测时数据是来回覆盖的，根本不会把1G内存撑满，所以淘汰策略根本没触发，这次调参算是没看到直接效果，但让我明白了调参得有针对性和场景,不能瞎调。

不死心，我又找了个可能立竿见影的参数：tcp-keepalive，默认是300秒，我把它改成60秒，这个参数是控制TCP连接保活时间的，改短点能更快释放无效连接，但对于压测这种短时间高并发的场景，影响微乎其微,果然再次压测结果还是差不多。

折腾了这一大圈，我算是明白了些门道。redis-benchmark这工具确实简单好用，能快速给我一个性能基线，性能数据和测试条件关系巨大，并发数、数据大小都是关键因素，不能拿一个数字就当真理，调参不是玄学，得结合具体业务场景，像我这样单纯压测，很多参数改了也白改，因为没触及到它的应用条件，真要优化，还得是根据实际应用中出现的问题，比如内存不够了、持久化拖慢速度了，再有针对性地去调整对应参数，这次压测算是打了个底，心里有数了，以后真遇到性能问题,也知道该从哪儿下手琢磨了。