Redis的TPS到底啥意思，性能咋影响，简单聊聊Redis吞吐量那些事

说到Redis的TPS，咱们先把它拆开看，TPS就是“每秒处理的事务数”（来源：计算机科学常用性能指标术语），你可以把它想象成Redis这个小伙计在一秒钟内能麻利地干完多少件活，这个“活”呢，在Redis这里，通常指的就是一次完整的命令操作，比如你发一个SET key value存数据，或者发一个GET key取数据，这就算一个“事务”。

TPS高低直接反映了Redis干活的速度快慢，是衡量它性能的一个核心指标，TPS越高，说明Redis越“猛”，单位时间内能服务的请求就越多,咱们的应用响应自然就越快。

是哪些家伙在影响Redis的TPS，或者说吞吐量（吞吐量就是个更宽泛的词，基本可以理解为TPS代表的处理能力）呢？这事儿得从里到外、从硬到软好几个方面说。

最底层的：硬件基础。 这就好比车的发动机排量。

1. CPU：Redis是单线程模型的（指其核心的网络请求处理和键值操作，新版本在某些操作上有多线程优化，但核心模型仍是如此，来源：Redis官方文档关于单线程的说明），它非常吃CPU的主频，主频越高，CPU处理单个指令的速度就越快，TPS自然容易上去，虽然它是单线程，但如果你在同一个机器上跑多个Redis实例,那多核CPU就能派上用场了。
2. 内存：内存的速度和容量是关键，内存速度越快，Redis读写数据延迟就越低，容量不够就更麻烦了，如果数据量太大，触发了Redis的淘汰机制或者直接写Swap到硬盘，那性能会断崖式下跌,TPS就别想了。
3. 网络：Redis的性能瓶颈很多时候不在它自己，而在网络，如果网络带宽不够，或者延迟很高，客户端请求堵在路上了，Redis本事再大也使不出来，通常Redis都和应用程序部署在同一个机房或者内网里,减少网络开销。

Redis自身的配置和使用姿势。 这就好比开车技术。

1. 持久化方式：Redis为了数据不丢，需要把数据存盘，主要两种方式：RDB（快照）和AOF（记录每一条写命令）。
   • RDB：像拍照片，定期全量备份，在备份那一刻，可能会占用较多资源，可能短暂影响TPS,但恢复数据快。
   • AOF：像写日记，每次写操作都记录，数据更安全，但写盘更频繁，如果配置为每次写都同步（appendfsync always），性能损耗最大，TPS会显著降低；如果配置为每秒同步一次（appendfsync everysec），则是平衡了安全和性能的常用选择,错误的选择会直接拖垮TPS。
2. 数据结构和命令复杂度：你用什么样的命令很重要，像GET、SET这种简单命令，TPS可以非常高，但如果你动不动就来一个KEYS *（列出所有键，复杂度O(n)）这种耗时操作，它会阻塞住整个Redis，期间所有请求都得等着，TPS瞬间跌到谷底，所以要用扫描类命令代替KEYS，用批量操作（MSET，Pipeline）减少网络往返次数,这都是提升吞吐量的好习惯。
3. 数据大小：你存的一个Value是1KB还是100KB，差别巨大，网络传输、序列化/反序列化的开销都不同，Value太大，单个命令处理时间变长,整体TPS就会下降。

客户端的用法。

1. Pipeline（管道）：这是个神器，普通模式是发一个命令，等一个回复，再发下一个，Pipeline相当于把一堆命令打包成一个包裹发过去，然后一次性收一堆回复，极大减少了网络往返时间，对TPS提升效果立竿见影,尤其是在网络延迟高的情况下。
2. 连接池：避免频繁地创建和关闭连接到Redis，用好连接池复用连接,也能减少不必要的开销。

说说实际能达到多少。 这个没定数，完全取决于上面说的这些因素，在普通的单机服务器上，处理简单的GET/SET命令，达到每秒十万甚至几十万的TPS都是很常见的（来源：多种Redis性能基准测试报告），但如果配置不当、命令复杂、数据量大,可能几千TPS都费劲。

聊Redis的吞吐量那些事，其实就是围绕TPS这个指标，看硬件给它的舞台有多大，配置和命令有没有给它拖后腿，以及客户端会不会高效地驱动它，把它伺候好了,它就能成为你系统里最快的那个部件。