Redis速度到底快不快？性能测试带你真切感受下Redis的极速表现

前段时间我在网上看技术文章的时候,正好看到一篇挺有意思的测评，标题大概是“Redis性能极限压测：百万QPS真的不是吹的”，这篇文章的作者呢，他不是干讲理论，而是实实在在地搭了个环境来测试Redis到底能跑多快，我看了之后觉得挺有收获，就想着结合他的测试方法和结果，跟大家聊聊Redis的这个“快”到底是个什么概念。

咱们得知道Redis为啥被大家认为快,那篇文章里提到，核心原因就像大家常说的，一是因为它是纯内存操作，数据都放在服务器的内存里，读写内存的速度可比读写硬盘快太多了，根本不是一个数量级的，二是因为它是单线程的，避免了多线程之间频繁切换和竞争资源带来的开销，虽然最新版本的Redis也引入了一些多线程的东西来处理网络IO，但最核心的命令执行还是单线程，这样结构简单，效率极高。

那篇文章的作者搭建了一个相对简单的测试环境,他用了一台配置还不错的云服务器作为Redis服务器，具体是几核几G内存我记不太清了，但肯定不是那种顶配的，他又用了另一台同数据中心的服务器作为测试客户端，用来模拟大量的并发请求，他选用了redis-benchmark这个工具，这是Redis官方自带的性能测试工具，用起来很方便。

测试开始了,他先从一个最简单的场景入手：执行SET和GET命令，也就是存数据和取数据，他设置了不同的并发连接数，比如50个、100个、200个，然后看每秒能处理多少个请求，也就是我们常说的QPS，结果非常惊人，即使在100个并发连接的情况下，GET命令的QPS轻松超过了8万，SET命令也达到了7万5以上，这个数字是啥概念呢？文章里打了个比方，这就好比一秒钟内能处理完一个小型网站所有用户同时点击产生的好几拨请求高峰，而且还绰绰有余。

他又测试了更复杂一点的操作,比如同时设置多个键值对的MSET命令，这个命令的QPS更是吓人，直接冲到了20万以上，这是因为网络往返的次数减少了，一次通信能完成多个操作，效率自然更高，这时候，作者发现了一个关键点：网络延迟开始成为瓶颈，也就是说，Redis本身处理命令的速度快得惊人，但命令从客户端发到服务器，结果再从服务器返回给客户端，这个网络传输过程花费的时间，在整个请求响应时间里占了大头，他为了验证这一点，尝试在本地环回地址（就是127.0.0.1）上测试，排除了物理网络的影响，结果QPS直接飙升到了好几十万，甚至接近百万的级别，这充分说明，在理想网络条件下，Redis的性能潜力巨大。

作者也做了一些不那么“理想”的测试，他测试了操作一个包含几千个元素的List数据结构，进行弹出操作，这时候QPS就下降到了几万的水平，这是因为处理的单个数据变大了，CPU需要计算的时间变长了，他还提到了如果开启数据持久化功能，比如RDB快照或者AOF日志，在触发持久化的瞬间，性能是会受到明显影响的，因为Redis需要fork出子进程来写硬盘，但这属于用性能换数据安全，是必要的权衡。

看完整篇测试文章,我最深的感受是：Redis的快，是一种“纯粹”的快，它的设计哲学就是把内存的速度优势发挥到极致，同时通过单线程模型避免内部损耗，它的性能瓶颈往往不在它自己身上，而是在网络带宽、延迟，以及客户端处理数据的能力上，对于我们日常开发来说，这意味着两件事：第一，在需要极致速度的场景，比如缓存、秒杀、实时排行榜等，Redis是绝对的王牌选择，第二，要想真正发挥出Redis的实力，必须保证它部署在一个网络环境良好的服务器上，并且客户端也要足够高效，别拖后腿。

那次性能测试让我真切地感受到,Redis“天下武功，唯快不破”的称号确实是名不虚传，它不是一种理论上的快，而是一种在严谨测试下能被反复验证的、实实在在的极速表现。