Redis分布式缓存性能优化：压测、Pipeline与分片实现QPS成倍提升

1. 先把"成倍提升"这个目标拆开看

聊分布式缓存优化，最怕一上来就报参数、贴配置，改完发现QPS只涨了3%，然后开始怀疑人生。我在实际项目里见过太多次这种情况：团队花了两个星期调优，最后复盘发现，真正拖慢系统的那个点从头到尾没人碰过。所以这篇先不急着上手段，先把"性能"这两个字掰开——到底提升的是什么，能被成倍放大的空间藏在哪一层。

这个系列叫"26讲"，我理解它想做的事情是体系化地把分布式缓存这件事吃透，而"300分钟"大致对应的是五六个小时的集中学习量。这个体量其实挺关键：它意味着内容不能只停留在"把appendfsync改成everysec"这种单点技巧上，而要覆盖从压测方法、协议层、命令层、架构层到运维层的完整链条。因为Redis的性能问题，90%的情况下不是某一个开关的事，而是好几个环节叠加的结果，你单独改一个，效果被其他瓶颈吃掉，自然看不到成倍的变化。

我先把结论放前面：**Redis能够实现成倍性能提升的空间，主要分布在三个地方——网络往返次数、单次请求在服务端消耗的CPU时间、以及单实例被单核锁住之后的横向扩展能力。**这三块对应的是完全不同的优化手段，也对应完全不同的收益量级。网络往返的优化，在批量场景下做到5到10倍很常见；命令层面的优化，做到2到3倍属于正常水平；横向扩展则是线性叠加，理论上加多少实例涨多少吞吐，前提是你把数据分片做对了。

所以这篇文章的组织方式，是按"先测量、再逐层削减"的顺序来的。因为如果不先建立基线，你根本不知道自己现在处于什么水平，也不知道改完之后是真的有效还是运气好。

1.1 一次请求的耗时到底花在哪

想优化，先得知道时间被谁吃了。一次典型的缓存读写，从客户端发起调用到拿到结果，耗时大致可以拆成这么几段：应用侧序列化与对象组装、客户端连接池取连接、数据在网络上往返、服务端读取命令并解析、执行命令、把响应写回缓冲区、客户端反序列化。这里面任何一段占比异常，都会把整体拖下来。

我习惯用一组具体的数字来建立直觉。假设客户端和服务端在同一个机房，网络往返一次大约0.2到0.5毫秒；服务端执行一条简单的GET，纯执行时间通常在几十微秒这个量级；序列化和反序列化，如果用比较重的框架，单次可能就要几十微秒甚至上百微秒。也就是说，在理想的同机房环境下，一条GET的端到端耗时里，真正的"Redis在执行命令"这部分占比可能不到10%，剩下全花在往返、上下文切换、序列化和连接管理上。

这个比例非常关键。它直接解释了为什么很多人调优调不动：他们把注意力全放在服务端配置上，而服务端执行本身只占总耗时的零头，你把这块优化到极致，端到端也就能快个百分之几。反过来，如果你的应用在异地机房，一次往返变成5毫秒，那服务端再快也没意义，瓶颈完全在链路上。

心得：调优之前，先在客户端埋点，把"取连接耗时""网络耗时""服务端耗时分"三项分开统计。很多性能问题一看这个拆解就水落石出了，根本不用继续往下猜。

1.2 吞吐与延迟不是同一件事

这两个指标经常被混着说，但它们的优化方向经常是相反的。延迟关注的是单次请求多快返回，吞吐关注的是单位时间能处理多少请求。Pipeline是个特别典型的例子：它把N条命令打包成一次网络往返，吞吐能涨好几倍，但单条命令的延迟反而会略微上升，因为你要等整批凑齐、要等服务端顺序处理完一批再统一回包。

所以在定优化目标的时候，得先明确业务到底在意哪个。比如一个在线推荐服务，每次请求要读十几个key，它在意的是总延迟能不能压到10毫秒以内，那就该考虑并行化或者批量读；而一个离线报表任务，一晚上要刷几千万条数据，它不在乎单条快不快，只在乎整体跑多久，那Pipeline和批量命令就是首选。

我在项目里见过一个反例：某个团队为了降低延迟，把Pipeline的批量大小从100调到1，结果发现P99延迟确实好看了一点点，但整体QPS掉了70%，后端机器数量被迫翻倍，成本直接爆炸。这就是没分清主次导致的。

1.3 这个系列内容的取舍逻辑

26讲的体量，如果平均分配，每讲大概十几分钟。但从实战角度，各部分的权重应该是不一样的。按我的经验，真正能带来数量级收益的内容，大概集中在这么几块：压测方法论、协议层批量优化、命令与数据结构选型、分片架构。而像持久化参数怎么调、日志格式怎么配这类内容，属于"必须知道但收益有限"的部分，讲清楚就行，不值得花太多时间。

性能调优这件事有个很反直觉的特点：收益最大的往往是最简单的那几招。加个Pipeline、把大key拆开、把连接池调大，这些操作成本极低，但效果立竿见影。而那些看起来很高级的调优手段，比如改内核参数、调内存分配器，收益通常只有个位数百分比，而且还容易引入稳定性风险。所以如果时间有限，优先把简单招数用足。

2. 基线压测：不测就调，等于闭眼开车

我见过的性能优化翻车案例里，有一多半是同一个原因：改之前没测，改之后也没测，全凭感觉。有人跟我说"我加了连接池，肯定快了不少"，我让他跑个数看看，结果发现连接数从8调到50之后，QPS几乎没变——因为他的瓶颈根本不在连接数上，而在单次请求的网络往返次数。

建立基线这件事，说难不难，但细节特别多。压测的目的不是拿到一个漂亮的数字去汇报，而是建立一个可重复、可对比的参照系。你要能在改动前后跑同样的负载，看到同样维度的指标，这样才有判断依据。这就要求压测的环境、数据、命令组合、客户端配置在前后保持一致，否则你测出来的差异可能全是噪音。

2.1 压测工具怎么选

常用的就那么几个，各有各的适用场景。

我一般的做法是分层用：先用自带工具跑一轮，确认服务端和网络没有明显的环境问题；然后用能配置读写比例的通用工具跑第二轮，模拟接近真实的负载；最后如果是核心链路，再写一个贴着业务代码的简易脚本做最终验证。

注意：压测客户端本身也是会打满CPU的。如果你的压测脚本跑在单线程上，很可能测出来的上限是客户端的上限，而不是服务端的上限。压测前先用一个不存在的目标压一轮，看看客户端自己能跑多少QPS，心里有个数。

2.2 压测环境最容易踩的五个坑

第一个坑是在同机压测。客户端和服务端跑同一台机器，互相抢CPU、抢网卡，测出来的数字完全没有参考价值。正常应该至少分两台机器，最好和线上部署形态一致。

第二个坑是连接数开得太小。如果只有几个连接，那么无论服务端多强，吞吐都被连接数卡死。经验上，单实例压测起步用50到100个连接比较合适，具体看单连接能跑多快。

第三个坑是数据规模不对。用100个key压测，数据全在CPU缓存里，跑出来的数字会比真实场景高一截。至少要把key数量铺到几百万，让内存访问的真实开销体现出来。

第四个坑是忽略了持久化。很多人在压测时把持久化关掉，觉得这样测出来的才是"Redis本身的能力"。但如果线上是开着AOF的，那你测出来的数字和线上就是两回事。压测配置必须贴近线上配置。

第五个坑是只跑一次。单次压测的结果受各种因素干扰，至少跑三轮取稳定值，而且要看的是稳态而不是峰值。

2.3 指标怎么读：别只盯着QPS

QPS这个数字最直观，也最容易骗人。一个系统QPS很高，但P99延迟是几百毫秒，那对在线业务来说基本不可用。所以看指标至少要成组看：吞吐、平均延迟、P99延迟、错误率、服务端CPU使用率、网络带宽占用。

这里面我最看重的是P99延迟和服务端CPU使用率的组合。如果服务端CPU已经跑到80%以上，那说明接近饱和了，继续加压只会让延迟飙升；如果CPU只有30%但QPS上不去，那说明瓶颈在别处——可能是连接数不够、可能是网络带宽打满了、也可能是客户端自己成了瓶颈。

还有一个容易被忽略的指标是单核CPU的使用分布。因为核心命令处理是单线程的，如果实例只用了1个核跑满、其他核闲着，那这就明确告诉你：该做分片了。这个信号比任何其他指标都直接。

# 压测期间同步观察服务端状态 redis-cli --stat redis-cli info commandstats redis-cli --latency -h <目标地址>

--stat能看到实时QPS和连接数，info commandstats能看到各命令的调用次数和平均耗时，--latency能采样出延迟分布。三个一起看，基本能定位到瓶颈层级。

3. 网络往返是最容易被忽略的"隐形税"

前面说过，服务端执行一条命令可能只要几十微秒，但一次网络往返要几百微秒。这意味着如果你的业务逻辑是"读一次、判断、再写一次"，那么两次往返的成本远超两次执行的成本。而大多数业务代码恰恰就是这种形态，一层层调用下来，一次页面渲染可能触发几十次缓存访问。

这就是我说"网络往返是隐形税"的原因。它不像CPU打满那么显眼，也不像内存不够那样报错，它就是安安静静地把你的延迟拉高几倍，而且你还很难在监控上直接看到它。

3.1 一次RTT的成本核算

先把账算清楚。同机房内网，一次TCP往返大概是0.1到0.3毫秒，加上客户端连接池取还、编解码、系统调用，实测单条命令的端到端往返通常在0.3到0.8毫秒之间。假设你的接口需要访问缓存20次，串行执行的话，光网络往返就要6到16毫秒。这个数字在要求50毫秒内返回的接口里，已经占掉了相当大的比例。

如果把这20次访问合并成一次批量调用，网络往返从20次降到1次，这部分耗时直接降到零点几毫秒。这是接近20倍的削减，而且几乎不消耗服务端额外的计算资源。这也是为什么我一直认为，批量化和Pipeline是所有优化手段里性价比最高的。

3.2 Pipeline到底能提多少

Pipeline的原理很朴素：客户端把多条命令连续写进socket缓冲区，一次性发出去，服务端顺序处理完后把多个响应连续写回来。全程只需要一次往返，也只需要一次系统调用级别的读写。

实测数据上，同机房环境下，单连接串行执行简单命令大概能跑1万到3万QPS（受往返延迟影响很大），开启Pipeline、批量大小设为100之后，同样的单连接能跑到10万QPS以上。这个提升倍数不是线性的，因为服务端处理能力也有上限，但在网络往返占主导的场景下，5到10倍是很常见的。

不过Pipeline有两个必须注意的点。一是批量大小不能无限大。批量太大，单次请求的响应包会很大，客户端要等整批处理完才能拿到结果，延迟会上升，而且一旦中途出错，重试的粒度也很粗。经验值是50到200之间比较合适，具体看单条命令的响应大小。

二是Pipeline不是事务。它只是把命令打包发出去，中间某条命令失败了，其他命令照样执行，客户端要自己处理部分成功的情况。如果需要原子性，得用事务或者脚本。

# 批量写入示例（伪代码风格，重点看批量切分的思路） BATCH_SIZE = 100 def batch_write(client, pairs): for i in range(0, len(pairs), BATCH_SIZE): chunk = pairs[i:i + BATCH_SIZE] pipe = client.pipeline(transaction=False) for key, value in chunk: pipe.set(key, value, ex=3600) results = pipe.execute() # 逐条检查结果，失败的记录下来单独重试 for idx, ok in enumerate(results): if not ok: failed.append(chunk[idx])

这段代码里有个细节值得说：transaction=False。很多人不知道Pipeline默认可能是带事务包装的（取决于客户端库），如果不需要原子性，明确关掉能省掉一部分开销。

注意：Pipeline在集群模式下会变复杂。因为一次批量里的key可能分布在不同的slot上，客户端需要按slot分组再分别打包。如果直接把所有key塞进一个Pipeline，很多客户端会直接报错。

3.3 连接池参数怎么算

连接池大小是个老生常谈的问题，但真正算清楚的人不多。一个粗略的估算方法是：连接数 = 目标QPS × 单次请求平均耗时（秒）。比如你要跑5万QPS，单次请求端到端耗时1毫秒，那理论上有50个并发就够了。但实际要留余量，一般乘个1.5到2倍，也就是75到100个连接。

这个公式里最容易出错的是"单次请求平均耗时"这个值。很多人拿服务端执行时间来算，算出来的连接数严重偏小。必须用端到端的耗时，包括网络往返和客户端处理时间。

还有个常见误区是连接数越大越好。连接数过多会带来几个问题：服务端要为每个连接维护缓冲区和文件描述符，内存开销上升；上下文切换变多；而且如果连接池里大部分连接都是空闲的，那就是纯粹的浪费。我见过把连接数配到1000的，结果服务端内存里有相当一部分被连接缓冲区吃掉了。

3.4 缓冲区与超时设置

客户端输出缓冲区这块，服务端有个配置控制单个连接能积压多少响应数据。如果客户端读得慢（比如在做大批量读取但处理跟不上），服务端缓冲区会堆积，超过限制后连接会被强制断开。这个现象在压测时不明显，但在生产环境遇到突发流量时很容易触发。

超时设置同理。连接超时和读写超时都要设，而且读写超时要大于P99延迟的几倍。设太短会因为偶发的延迟毛刺导致大量超时重试，反而放大问题；设太长则故障时无法快速失败。

4. 命令与数据结构：把每一次调用的性价比拉满

网络层优化解决的是"调用次数太多"，命令层优化解决的是"单次调用太贵"。这两块是乘数关系，都做好才能拿到成倍的效果。

单次调用太贵的情况比想象中普遍。很多人写代码的时候根本没考虑过命令的时间复杂度，KEYS *、SMEMBERS、HGETALL这些命令在小数据量下毫无感觉，等数据涨起来就变成生产事故。我在一个项目里见过有人用KEYS做前缀查询，测试环境1000个key的时候毫秒级返回，线上涨到200万key之后直接把实例卡死了十几秒。

4.1 慢命令黑名单

先列一份必须警惕的命令清单。

这张表里最值得说的是DEL和UNLINK的区别。删除一个大key，同步释放内存可能要几百毫秒，这期间整个实例是阻塞的。换成UNLINK之后，key从键空间移除是同步的，但内存回收放到后台线程做，主线程不受影响。这个改动成本极低，但能避免很典型的周期性卡顿。

心得：线上环境一定要禁用KEYS类命令。可以通过重命名命令的方式把危险命令改成不可调用的名字（在配置里给命令起个别名或者指向空实现），这样即使代码里写了也执行不了，能在关键时刻救你一命。

4.2 大key与热key的识别与拆解

大key指的是单个key对应的value过大，或者集合类型的元素数量过多。它的危害是多方面的：读写时网络传输量大、删除时阻塞、迁移时卡顿、集群做数据均衡时会被拖慢。

判断标准没有绝对数字，一般可以参考：字符串类型超过10KB、集合类型元素超过5000个，就该警惕了。识别方法可以用自带的扫描命令配合内存占用分析，把每个key的内存占用和元素数量统计出来，排序看头部。

拆解思路很直接：按业务维度切分。比如一个用户的关注列表是个大set，可以按关注时间的月份拆成多个key；一个商品的属性是个大hash，可以按属性分组拆成几个小hash。拆的时候要注意保留一个能快速定位到分片的路由规则，不然读的时候要遍历所有分片，反而更慢。

热key是另一个维度的问题：单个key被高频访问，导致这个key所在的实例成为热点。识别上，可以在客户端做本地统计，也可以抓服务端的命令统计采样。解决手段主要有几种：本地缓存（在应用进程内缓存一份，设置短过期时间）、key复制（把一个key复制成多个副本分散到不同实例）、或者读写分离（把读流量分散到多个从节点）。

4.3 数据结构选型带来的数量级差异

这块的差异经常被低估。举个例子：要用缓存记录用户某天的签到状态。做法A是用一个字符串存JSON，每次读出来反序列化、修改、再序列化写回去，单次操作的数据量可能是几百字节到几KB；做法B是用位图，每个用户每天一个bit，一年的数据也就几十字节，判断和修改都是位运算。

两者在数据量上的差距是几十倍到上百倍，在CPU消耗上的差距也很明显（省掉了序列化）。这类优化不涉及任何架构调整，纯靠对数据结构的理解，但收益是实打实的。

常用结构的选择逻辑我整理成下面这张对照：

4.4 用脚本把多次往返压成一次

有些逻辑天然需要"读-判断-写"三步，比如分布式锁的释放、库存扣减、限流计数。如果放到客户端做，就是至少两次往返，而且中间还有并发安全问题。这类场景用服务端脚本执行是最合适的：整个逻辑在服务端一次执行完，只有一次往返，而且天然原子。

不过脚本也有它的代价。脚本执行期间会阻塞其他命令，所以脚本必须短小，绝对不能在里面做循环遍历大集合这类操作。另外脚本的复杂度不好控制，一旦有人写了个O(N)的循环，就变成了隐形的慢命令。

注意：脚本里不要用随机函数或者依赖系统时间，因为主从复制和脚本缓存机制会导致行为不一致。需要随机性的话，把随机参数从客户端传进去。

5. 单线程不等于单核：横向扩展的三种做法

前面所有的优化，都是在榨干单个实例的能力。但单个实例的天花板是明确的：核心命令处理跑在单线程上，一个核跑满就到顶了。这时候无论你怎么优化命令、怎么加Pipeline，QPS都不会再涨。唯一的出路是横向扩展。

先说清楚为什么是单线程。核心原因是为了避免锁竞争和上下文切换的开销，让每条命令的执行路径尽可能短。这个设计在多核普及的今天看起来有点反直觉，但实际效果很好：单实例在简单命令上能跑到十万级QPS，这个数字对绝大多数业务足够了，而简单带来的稳定性和可预测性，价值远超多线程可能带来的额外吞吐。当然，较新的版本在网络IO和部分后台任务上引入了多线程，但命令执行的主链路仍然是单线程的，这个前提没变。

5.1 三种分片方案对比

横向扩展的核心问题是：数据怎么分到多个实例上，客户端怎么知道该找哪个实例。

我的选型经验是：实例数量少于10个、业务相对固定的场景，客户端分片就够了，简单直接；实例数量多、需要频繁扩缩容的场景，用集群模式；如果存量系统改造困难，可以先用代理层过渡。

5.2 扩容时的数据迁移

扩容是分片方案里最麻烦的部分。加了新实例之后，要把一部分数据从老实例迁过去，迁移过程中还要保证业务可读写。

标准的做法是：先做双写或者记录增量变更，然后后台批量搬迁存量数据，搬迁完成后校验，最后切读流量。整个过程要控制在业务低峰期，而且要能随时中止回滚。集群模式下的迁移工具相对成熟，能按槽位粒度搬迁，影响面可控；客户端分片就得自己写迁移脚本，工作量不小。

扩容时的分片规则也要提前想好。常见的取模方式在扩容时会导致大量数据重新分布，一致性哈希能缓解这个问题但实现更复杂。如果一开始就预估到未来会扩容，可以在设计时预留足够多的逻辑分片，扩容时只搬迁部分逻辑分片，迁移量就小得多。

5.3 集群下的批量操作陷阱

集群模式下，Pipeline和批量命令都会遇到"key不在同一个槽位"的问题。比如一次批量读10个key，它们可能分散在3个节点上，客户端需要先按节点分组，再分别发批量请求。

这个问题在代码里很容易埋雷：单机环境测试没问题，上了集群就开始报错。所以如果确定要走集群，从开发阶段就要用集群环境测试，别等到上线前才发现一堆多key命令要改。

还有跨槽位的操作，比如求两个集合的交集，如果两个集合不在同一个槽位，就没法直接算。解决方式要么是在业务层保证相关key落在同一个槽位（通过在key里加相同的前缀哈希标签），要么是在应用侧先分别取出再计算（数据量大时不现实）。

6. 持久化、内存与主从：那些会悄悄吃掉性能的配置

前面几层都是主动优化，这一层更多是"防止踩坑"。因为持久化、内存、复制这几块的配置如果不当，会在你毫无察觉的情况下把性能削掉一大截，而且表现往往是间歇性的，特别难排查。

6.1 持久化策略的取舍

持久化的核心矛盾是：数据安全性越高，写入性能越差。两种方式的特性差别挺大。

快照方式是把内存数据整体落盘，落盘时通常会fork一个子进程来做，主进程继续服务。fork本身在数据量大的时候会有明显的耗时，而且子进程写盘期间会产生写时复制，内存占用可能翻倍。所以数据量大的实例做快照，容易出现周期性的延迟毛刺。

日志方式是把每条写命令追加到文件，落盘频率由刷盘策略决定。每次写都刷盘最安全，但性能最差，吞吐可能掉一个数量级；每秒刷盘是折中方案，最多丢一秒数据，性能影响可接受；交给操作系统决定性能最好，但故障时可能丢较多数据。

我的默认建议是：如果业务能接受秒级数据丢失，用每秒刷盘的日志方式，同时定期做快照作为备份。这样兼顾了性能和数据安全。如果完全不能丢数据，那就得在架构上做文章，比如多副本同步写，而不是靠单机的刷盘策略硬扛。

注意：做快照时fork的耗时取决于内存页表大小，数据量越大越慢。如果实例内存很大（比如几十GB），建议把快照时间安排在低峰期，或者用从节点做备份，避免影响主节点。

6.2 内存碎片与淘汰策略

内存碎片这个事，平时不显眼，等到碎片率高了，会出现"明明还有空闲内存，但就是分配不出连续空间"的情况，表现为内存使用率虚高、写入偶发失败。

查看碎片率的方法很简单，看已分配内存和实际使用内存的比值，超过1.5就值得关注了。处理方式有两种：开启自动碎片整理（会消耗一定的CPU，建议在低峰期开），或者做一次主从切换，让新节点从RDB恢复，内存布局会变得紧凑。

淘汰策略的选择也很关键。首先要明确：这个实例的数据是不是允许被淘汰。如果缓存的数据丢了可以重新计算，那就配淘汰策略；如果数据丢了业务就出错，那必须配成不淘汰并做好容量监控，因为一旦内存打满，所有写入都会失败，那是个非常严重的事故。

淘汰策略里，推荐优先考虑基于近似最近最少使用的策略，它在命中率和实现开销之间平衡得比较好。随机淘汰的开销最小但命中率差，不推荐在有明确热点分布的业务里用。

6.3 主从复制的隐性成本

主从架构看起来是纯粹的读扩展，实际上有几个隐性成本。一是复制本身要占带宽，全量同步时要传输整个数据集，增量同步时要持续传写命令，如果主节点写入量大，复制流量会相当可观。二是从节点也要执行所有写命令，所以从节点的CPU压力不比主节点小多少。三是全量同步时的fork开销，和快照一样，数据量大的时候会有明显卡顿。

还有个细节：从节点默认会对外提供服务，但如果复制延迟大，读到的可能是旧数据。对一致性敏感的读请求，要么强制走主节点，要么在应用层校验版本号。

7. 排障实录：几个真实场景的定位过程

理论讲完了，说几个我印象比较深的排查过程。这些案例的共性在于：表面现象和真实原因往往隔了好几层，顺着直觉走经常走偏。

7.1 常见问题速查表

这张表建议贴在排查手册里。实际遇到问题时，先按现象对号入座，能省掉大量摸索时间。

7.2 一次P99毛刺的排查路径

印象最深的一次，是某业务的缓存P99延迟每隔一段时间就飙到几百毫秒，但平均值完全正常，CPU和内存看着也都很平稳。这种情况最难查，因为监控面板上什么都看不出来。

排查路径是这样的：第一步先确认毛刺的周期性，发现大概每5分钟一次，非常规律。这种规律性通常指向后台任务。第二步去看服务端日志，果然在对应时间点有快照生成的记录。第三步验证假设：把快照关掉观察一段时间，毛刺消失了，确认就是这个原因。

但事情没完，因为快照不能一直关着。于是继续往下挖：为什么一次快照会造成几百毫秒的阻塞？查下来是数据量涨到了二十多GB，fork的页表复制耗时确实到了百毫秒级别，再加上写时复制导致的内存压力，进一步放大了影响。

最终的解决分了几个层面：把快照改成在从节点做，主节点不做持久化；把一个特别大的集合类key拆成了多个小key，减少单次写时复制的内存页数量；同时把快照时间调整到业务低峰。三板斧下去，毛刺基本消失了。

这个案例给我的教训是：周期性出现的性能问题，第一反应就该去看后台任务的时间表。快照、碎片整理、日志切割、定时任务，这些都是嫌疑对象。

7.3 我在实际调优中总结的几条经验

第一条：先改最少的东西，再改最多的东西。很多人一上来就大改架构，结果出了问题根本无法定位是哪一处引起的。正确的做法是一次只改一个变量，测完再改下一个。这个过程慢，但是可靠。

第二条：不要把监控指标当成结论。CPU高不代表计算密集，也可能是上下文切换多；QPS低不代表服务端慢，也可能是客户端发不出来。指标只是线索，要顺着线索往下验证。

第三条：优化要有明确的目标数字。比如"把P99从80毫秒降到20毫秒"，有了目标才知道什么时候可以停。没有目标的优化会变成无止境的折腾，最后收益越来越小，风险越来越大。

第四条：大部分性能问题不需要调参。把批量做好、把大key拆掉、把慢命令换掉、把连接池配对，这四件事做好，能解决八成以上的场景。那些内核参数调优、内存分配器替换之类的操作，收益通常只有个位数百分比，而且容易引入稳定性问题，除非前面四件事都做完了还差一口气，否则不建议碰。

第五条，也是最实在的一条：压测环境和线上环境越像，结论越可信。我在一个项目里花了三天时间的调优成果，上线后完全没体现出来，最后发现是压测环境的数据量只有线上的百分之一，测出来的瓶颈根本不是一个东西。后来把压测环境的数据规模、机器规格、网络拓扑全对齐之后，压测结论的参考价值立刻就不一样了。这件事让我养成了一个习惯：任何优化结论，都要在接近线上的环境里复验一遍再下判断，哪怕多花两天时间，也比上线后回滚强。

性能这件事没有银弹，能做的就是一层层把浪费掉的时间找回来，把该并行的并行掉，把该拆的拆开。每找到一处浪费，就离那个"成倍"近一点。