IM后端性能优化实战：从慢SQL、Redis缓存到可观测性

ChitChat这个项目进到后期，我自己在测试环境点了一遍核心功能，说实话心凉了半截。点开一个聊天窗口，历史消息要转两三秒才出来；发图片的时候进度条半天不走；切到会话列表，明显能感觉到列表渲染卡一下。这还只是测试环境，真上了生产，用户体感只会更糟。

于是我把学习笔记里的性能优化、缓存、可观测性这三块内容翻出来，对着ChitChat做了一轮完整的实战改造。整个过程差不多持续了两周，涉及接口链路梳理、慢SQL排查、Redis缓存与本地缓存引入、消息发送接口异步化改造、以及一套轻量可观测性体系的搭建。改造完成后再测，核心接口的P95耗时基本降了一个数量级，服务端也能清楚回答"慢在哪里、为什么慢、改了之后是否变好"这三个问题了。

这篇内容比较适合正在做消息类或IM类后端项目、想系统做一次性能治理的人参考。文章不绕理论，直接按我当时操作的顺序来：先量化问题，再上缓存，再改业务链路，最后补可观测性，结尾附上完整的优化前后对比和复盘。

1. ChitChat到底慢在哪——从体感问题到量化数据的性能摸底

1.1 用户感觉到的"卡"和代码里的"慢"，中间隔着一次数据化过程

做性能优化的第一件事，不是改代码，而是先搞清楚"慢"这个词到底对应着什么数据。用户说"打开聊天记录好慢"，这句话本身没有意义，因为慢可能发生在客户端渲染、网络传输、后端业务逻辑、数据库查询或者第三方依赖上，甚至可能是用户手机低电量导致的CPU降频。

我当时在ChitChat后端做的第一轮动作，是给所有HTTP接口统一加了一层耗时统计埋点，按接口维度统计TP50、TP95、TP99和每分钟调用量。因为ChitChat的访问量级还不算太大，这个埋点只需要在网关或者Spring拦截器里做一个简单的耗时计算并上报到内存队列，再由一个异步线程汇总输出即可。实践下来，用这种方式很快就能把"最慢的十个接口"拉出来，而不是靠猜。

筛选出来的结果其实有些出乎我的意料。最慢的并不是很多人直觉中的图片上传接口，而是历史消息记录、会话列表和消息发送这三个看起来“没什么技术含量”的接口。

到这里基本有了第一个结论：ChitChat的"卡"主要来自读链路和写链路上存在明显的串行等待和数据查询浪费，跟框架本身关系不大。想要让项目快起来，必须先从这个数据表下手。

1.2 慢SQL与索引误区的排查记录

接口耗时数据出来之后，第二步是抓数据库层面的证据。把MySQL慢查询日志打开，阈值设置为1秒，跑了半天，捞出来几十条慢SQL。逐条整理后发现，大部分慢SQL都集中在t_message、t_conversation和t_friend这三张表上。

最有代表性的一个案例是会话列表接口。ChitChat每次拉会话列表，代码逻辑是"先查出当前用户的所有会话ID，再遍历每个会话ID去查对应会话的最后一条消息和未读数"。这个循环在数据库层面就形成了典型的N+1查询——一次页面请求会产生一百多条SQL。其中大部分SQL本身不慢，慢的是它们被重复执行了无数次。网络往返和时间堆积下来，接口响应时间自然被拉高到接近一秒。

慢SQL日志里还有几条很典型的索引失效案例，比如对索引字段使用函数导致索引失效、使用OR条件连接两个不同索引字段、还有字符串字段与数字比较时发生隐式类型转换。这些问题在单独执行时可能只差几十毫秒，但在高QPS场景下，每一层毫秒都会被放大成可见的接口延迟。修索引时我还犯过一个错误，以为只要给WHERE条件涉及的字段加上联合索引就一定生效。实际上，联合索引的字段顺序必须从最左前缀开始，如果查询条件跳过了第一个字段，索引并不能被充分利用。

这一轮排查让我得到一个很深的体会：性能优化里至少70%的问题出在数据库IO上，真正需要改Java业务代码的比例反而不高。所以遇到慢接口，先别急着加缓存，先把SQL和索引查一遍，往往收益更快。

1.3 应用服务自身的水位：JVM与线程池

数据库排查完，我再回头看了应用服务自身的水位。ChitChat用的是Java技术栈，如果JVM频繁Full GC，接口再快也会被卡住。当时我在本地压测时观察GC日志，发现Young GC的触发频率很高，原因很直接：每次拉取历史消息时，代码会把整页的Message对象做深拷贝，再转成JSON字符串塞给前端，导致大量中间对象进入新生代。

线程池的问题更隐蔽。ChitChat里有一个专门处理消息推送的线程池，初始配置是核心线程数4、最大线程数8、队列容量10000。问题在于队列容量设置太大，当推送任务短时间爆发时，线程池不会及时扩容，而是把所有任务都塞进队列排队。从调用方的角度看，消息已经"发出去"了，实际上一直堵在队列里没被推送出去。要发现这层问题，光看接口耗时是不够的，必须配合线程池活跃线程数、队列积压量这些指标一起看。

我把线程池的队列容量调小到500，最大线程数提高到16，并设置了合理的拒绝策略和告警。这个改动单独看起来不大，但消除了消息推送在高峰期的隐性排队排队时间。

到这一步，性能摸排才算真正结束。总结一下这轮的要点：用户体感快慢、数据库慢SQL、JVM内存表现、线程池积压，四个维度缺一不可。有了这些数据，才能进入缓存方案的设计。

2. 两级缓存落地方案：把重复查询挡在数据库外面的核心手段

2.1 缓存选型的判断标准：不是所有数据都应该进Redis

做缓存之前，我先过了一遍ChitChat的数据访问特点，确认哪些数据适合缓存，哪些数据不应该碰缓存。适合进缓存的数据有三个特征：读取频率高、写入频率低、允许秒级甚至更长的一致性延迟。

按这个标准，我把ChitChat的数据分成了几类。第一类是用户基础资料和好友关系，除了更新资料时会发生变更，其余时间基本只读，缓存收益非常大。第二类是会话摘要和最近一条消息摘要，读取频率高，变更频率中等，适合缓存但要做好更新策略。第三类是未读数这类数据，虽然访问量大，但对实时性和准确性要求极高，不能长时间放在Redis里，更适合用短TTL加数据库回源的方式处理。

那些完全不建议缓存的数据也有共性：比如强事务性数据、强一致要求的数据、或者每次读取都必须基于最新值做判断的数据。缓存不是万能药，把一个需要严格实时判断的数据塞进Redis，等于给自己埋了一个逻辑漏洞。

2.2 Redis缓存落地：穿透、击穿、雪崩的应对细节

缓存方案的第一版，我采用了标准Cache Aside模式：读请求先查Redis，命中就直接返回；没有命中则回源数据库，再回填Redis。这个模式本身很简单，真正麻烦的是缓存穿透、缓存击穿和缓存雪崩这三类风险。

缓存穿透指的是查询一个数据库中根本不存在的ID，导致每次请求都绕过缓存直接打到数据库。ChitChat被恶意遍历用户ID时就会出现这种情况。解决穿透的常用手段有两个：一个是把空结果也缓存起来，设置较短的过期时间，比如60秒；另一个是在缓存前面加布隆过滤器，直接拦截不存在的key。考虑到ChitChat的数据规模不大，我直接选了空值缓存方案，简单有效，代码量也少。

缓存击穿是另一个高发问题。某个热点key在同一时刻过期，这时候大量请求同时穿透到数据库，数据库可能直接被压垮。比如某条热门群消息被大量用户同时拉取时，缓存过期瞬间就会触发这个场景。我的处理方式是加互斥锁，让同一个key同时只有一个请求能回源数据库，其他请求先等待一小段时间再重新查询缓存。

java复制public String getMessageWithMutex(String key) {
    String cache = redis.get(key);
    if (cache != null) {
        return cache;
    }

    String lockKey = "lock:" + key;
    Boolean locked = redis.setIfAbsent(lockKey, "1", Duration.ofSeconds(3));
    if (locked != null && locked) {
        try {
            cache = loadMessageFromDb(key);
            redis.set(key, cache, Duration.ofMinutes(10));
            return cache;
        } finally {
            redis.delete(lockKey);
        }
    }

    // 拿不到锁的请求先短暂休眠，然后重新走缓存
    Thread.sleep(50);
    return getMessageWithMutex(key);
}

缓存雪崩的处理相对宏观。如果大量key采用同一个过期时间，即使分散在不同业务中，同一时刻集体失效也会造成数据库压力尖峰。我给所有缓存过期时间都加了一个随机偏移量，比如基础5分钟，实际过期时间在5分钟到7分钟之间随机，把失效压力均匀摊开。同时在Redis部署上保持主从加哨兵的高可用结构，避免Redis节点挂了导致所有请求全量落到数据库。

2.3 本地缓存Caffeine：为什么需要进程内这一层

Redis缓存上线后，ChitChat的数据库压力确实下降了不少，但接口延迟并没有如我预期那样大幅下降。细看之后发现问题出在Redis本身的网络开销上。每次缓存查询都是一次网络RTT，在本地环境大约0.5ms到1ms，跨机房环境下可能到2ms以上。对单个请求来说这些毫秒不可怕，可ChitChat一个页面请求往往要查很多缓存key，积少成多，延迟又上去了。

这就是我引入本地缓存Caffeine的原因。所谓本地缓存，就是把热点数据直接放进应用进程的内存里，查询时跳过Redis网络调用。对当前用户频繁访问的会话摘要和用户资料来说，本地缓存可以把数据读取耗时从毫秒级降到微秒级。

我当时给Caffeine的配置如下：

java复制Cache<String, UserProfile> localUserCache = Caffeine.newBuilder()
        .maximumSize(5000)
        .expireAfterWrite(Duration.ofMinutes(5))
        .recordStats()
        .build();

配置好之后，访问顺序调整为本地缓存优先，未命中再走Redis，Redis未命中才回源数据库。实测下来，Caffeine对当前登录用户热点数据的命中率大概在70%左右，这70%的请求完全不需要经过网络，接口毛耗时降得非常明显。

2.4 缓存一致性：Cache Aside之外的删除策略细节

加了缓存之后，最让人头疼的问题就从"性能"转移到了"一致性"。尤其是用户修改头像、昵称这样的场景，如果缓存更新不及时，用户会看到旧数据。

我当时采用的策略是Cache Aside模式加延迟双删。所谓延迟双删，逻辑是：更新数据库前先删除缓存，更新数据库后再开一个延迟任务，等几百毫秒后再次删除缓存。这样做的目的是应对主从复制延迟场景——如果更新完数据库，从库还没来得及同步新数据，刚好有请求回源读到了旧数据并回填缓存，第一次删除缓存就会失效，延迟任务会来一次兜底删除。

java复制public void updateUserProfile(UserProfile profile) {
    String key = "user:info:" + profile.getUserId();
    redis.delete(key);
    userDao.updateProfile(profile);
    // 延迟双删：等主从复制延迟过后再次删除
    executor.schedule(() -> redis.delete(key), 500, TimeUnit.MILLISECONDS);
}

关于缓存和数据库的一致性，行业内没有任何方案能做到百分之百强一致，我们能做的只是把不一致的时间窗口压缩到业务可以接受的范围。ChitChat的用户资料允许几秒内的延迟可见，所以这套策略足够了。如果是余额、库存这种强一致数据，只能说别用缓存，或者至少要选择分布式锁配合事务消息这类更重的方案。

3. 代码与架构提速：消息链路中看不见的等待时间

3.1 发消息接口的串行等待改造

缓存把读链路的数据重复查询问题解决了，但ChitChat最核心的发送消息接口，延迟还是没达到预期。我打开发送消息接口的代码，一步一步梳理执行链路，很快就发现了问题所在。

ChitChat发送一条消息，后端要做四件事：鉴权校验、内容安全过滤、消息写入数据库、推送给在线接收方。这四件事原版代码是严格按照顺序同步执行的，每一步都在等待上一步完成。问题在于，鉴权和内容过滤依赖的是第三方HTTP接口，一次调用至少要几百毫秒；推送更是要遍历接收方的所有在线连接去发送数据。四条串行链路叠加，单次发送的耗时自然居高不下。

但仔细看一下依赖关系：鉴权、内容过滤之间并没有先后依赖；消息写入数据库后，推送的实时性要求可以放宽一些，用户发出消息得到的结果应该尽快返回，推送放到后台异步执行完全可行。基于这个分析，我把接口改造成了两个阶段：第一阶段并行执行鉴权和内容过滤，全部通过后写入消息表并立即返回；第二阶段由消息队列异步接收写入结果，再执行推送动作。

java复制CompletableFuture<Void> authFuture = CompletableFuture.runAsync(() -> authService.check(currentUser), executor);
CompletableFuture<Void> auditFuture = CompletableFuture.runAsync(() -> auditService.filter(content), executor);

CompletableFuture.allOf(authFuture, auditFuture).join();

这里有一个细节很关键。使用CompletableFuture确实能达到并行效果，但必须使用独立的线程池。不要用默认的ForkJoinPool.commonPool()，因为它的线程数受CPU核数限制，而且会被其他无关异步任务共用。我自己测试时踩过这个坑，并行改完后反而出现了线程饥饿导致的超时，换成独立线程池后问题消失。

改造完成后，ChitChat发送消息接口的单次耗时从原来的860ms降到260ms左右。用户体验上，消息发出后立刻就会显示在聊天界面里，再配合WebSocket异步推送，整体体感已经接近"秒达"。

3.2 N+1查询的根治与数据冗余设计

会话列表接口的N+1问题，如果只在SQL层面调优会非常痛苦。我当时的做法不是一遍遍优化那一百多条SQL，而是直接从代码逻辑层面消除N+1。

原来的逻辑是，查到会话ID列表后遍历查询最后一条消息和未读数。改造后的逻辑是：一次性查出所有会话ID后，用一条SQL把多个会话的最后一条消息全部查出来。具体实现可以用子查询配合JOIN，也可以先查message表，按会话ID分组取主键最大的那一条。

sql复制SELECT m.*
FROM t_message m
JOIN (
    SELECT conversation_id, MAX(id) AS max_id
    FROM t_message
    WHERE conversation_id IN (...)
    GROUP BY conversation_id
) t ON m.id = t.max_id

同样的优化思路也应用到好友资料展示上。原来每个好友都要查一次用户表，改成用IN条件批量查询后，一次网络往返就能拿到全部所需数据。对于批量查询的结果，我还在代码里建立了内存Map，避免后续业务逻辑重复到数据库取数。

这种改造背后是一个更底层的设计思想：面向接口返回结构设计数据访问，而不是面向单条数据设计。后端接口返回的是一个聚合视图，数据访问层就应该按聚合视图批量取数据，把N次小查询合并成一次大查询。

至于未读数这种高频变更的数据，我顺势做了数据冗余。在会话表里直接维护一个total_unread字段，每次发消息或已读上报时原子更新这个字段，读取时直接从会话行拿值，完全不需要做COUNT聚合。这个字段的变更会带来轻微的写放大，但对读多写少的聊天场景来说是划算的。

3.3 容易被忽略的小优化：序列化、压缩与连接复用

大问题解决之后，我又花了一个下午处理那些看起来很小、积累起来却很惊人的优化点。

第一是JSON序列化。ChitChat的历史消息接口会把整个消息对象序列化成JSON字符串返回给前端。原型阶段为了方便，直接把所有字段都序列化出去，一条消息有十几个字段，其中很多前端根本用不到。在大批量拉取历史消息时，多余字段的序列化时间和网络传输时间会被放大几十倍。后来我在接口层增加了字段裁剪，只返回客户端渲染需要的几个核心字段，同时把JSON库从Jackson换成了性能更好的专用序列化方案，消息体和推送内容都做了一次字段级别的瘦身。

第二是消息体压缩。ChitChat支持发送长文本和图片Base64数据，这类内容体积较大。在通过Redis和MQ传输时，如果不做压缩，不仅占用带宽，还会拖慢序列化和反序列化的速度。我引入了zstd压缩，超过1KB的消息体先压缩再传输。实测在文本消息场景下，压缩率能达到30%到60%，耗时增量几乎可以忽略。

第三是连接复用。ChitChat的原始代码里，有部分HTTP调用在方法内部新建了HttpClient，没有使用连接池。每次请求都要重新建立TCP连接，还要经历TLS握手，白白浪费了几十毫秒。改造后统一使用连接池复用，设置合理的最大连接数和空闲存活时间。数据库连接池和Redis连接池的参数同样值得检查，最大连接数如果设置过小，高并发时请求就会排队等待获取连接，这层排队时间在压测报告中不容易看出来，但用户体感非常明显。

4. 日志、指标、链路一把抓：可观测性怎么搭才真正有用

4.1 统一日志Fields：让一次请求能被完整串起来

做完性能优化之后，我一直在思考一个问题：现在项目快了，但如果以后再次变慢，或者生产环境出问题，靠什么快速定位？如果还是像之前那样翻日志基本靠搜关键字，ChitChat在性能上省下来的时间，迟早会在排障效率上还回去。

ChitChat原来的日志基本是各写各的，有的输出到控制台，有的写到文件，格式不统一。出问题的时候想根据一个用户ID查出他的完整请求路径，几乎不可能做到。这次我统一了全项目的日志格式，以JSON形式输出，并强制要求每一条日志都带上traceId、userId、接口路径和耗时字段。traceId的生成和传递放在独立拦截器里，入口生成后放入MDC，所有下游日志自动带上这个ID。

java复制MDC.put("traceId", traceId);
MDC.put("userId", userId);
try {
    // 业务代码
} finally {
    MDC.remove("traceId");
    MDC.remove("userId");
}

配合ELK或类似日志收集平台，输入traceId就能搜索出一次请求在ChitChat内部经过的所有日志记录。这个能力在排查线上偶发超时问题时极其重要，没有统一traceId之前，一次报错要跨好几个服务翻日志，有traceId之后分钟级就能定位到具体环节。

4.2 指标大盘：把性能数据和业务指标放到一张面板上

日志解决了"某一次请求发生了什么"的问题，指标则解决"系统当前整体状态如何"的问题。ChitChat的监控大盘上，我固定展示的指标有这么几类：接口维度QPS和TP50/TP95/TP99耗时、Redis缓存命中率、Redis慢命令数量、消息队列积压量、数据库活跃连接数和慢SQL数量、JVM的GC耗时和堆内存使用率，以及线程池的活跃线程数和队列大小。

这些指标里最有参考价值的是TP99而不是平均值。平均值很容易被少数慢请求拉高，让人对系统整体健康状况产生误判。比如某接口平均耗时200ms，看起来很健康，但TP99可能已经超过1500ms，说明有1%的用户正在经历明显卡顿。规定告警时不下发平均耗时，一律看分位数。

缓存命中率也是一个需要长期盯着的指标。我当时加了Caffeine的recordStats()，配合Redis的INFO命令，把两级缓存的命中率都上报到大盘上。如果某一天命中率突然从85%跌到60%，大概率是缓存过期时间设置出了问题，或者业务侧出现了新的查询模式，缓存还没有覆盖到。

4.3 链路追踪：一次发送请求在多个服务节点间的完整路径

ChitChat虽然目前还是单体应用为主，但消息发送链路已经涉及应用服务、Redis、MQ、定时任务和WebSocket推送服务等多个节点。这种情况下，单靠日志和指标还不够，最好能引入分布式链路追踪。

我采用的是OpenTelemetry配合开源追踪系统的方式。在应用里引入Agent后，它会自动为每个请求生成traceId和span，并记录每个环节的耗时。当一次消息发送变慢时，追踪系统可以直接展示：鉴权耗时多少、消息入库耗时多少、MQ投递耗时多少、推送服务消费耗时多少。哪一段慢，一眼就能看到。

实践中我发现，链路追踪真正的价值不是上线后看拓扑图，而是每次发布新功能或更改依赖后，能快速对比前后版本在同一节点上的耗时差异。这相当于给每一个微服务节点的性能表现都装上了一个温度计。温度计本身不治病，但没有温度计你根本不知道病在哪。

4.4 接入层的可观测性也不要忽略

最后补一个容易漏掉的点。ChitChat以前的性能排查都集中在服务端，但用户抱怨"聊天记录打开慢"时，还有可能卡在客户端渲染上，或者卡在弱网环境的请求发送上。所以后来我在客户端接入层也加了一层简易埋点，记录从用户点击进入聊天窗口到首页内容渲染完成的时间，以及这个时间段内请求发出的时间和响应返回的时间。这样能区分出时间消耗在网络上还是服务端。

移动端弱网环境的优化更依赖这个埋点。比如之前发现某些用户所在网络环境下，TCP连接建立超时严重，后来通过调整客户端的连接超时时间、增加请求超时重试策略，把弱网场景下的请求失败率降了不少。这一类工作量不大，但用户体感改善非常直接。

5. 优化后的数据对比与踩坑复盘

5.1 量化结果：优化前后各项指标的变化

整个优化轮次做完，我在相同测试环境、相近压测流量下重新跑了一遍ChitChat核心链路，对比数据如下：

坦白说，数据变化幅度比我预想的更大。主要原因是初版ChitChat在代码层面确实存在太多"顺手写一下"的地方，缓存没有任何设计，SQL查询也是怎么写都能跑就不管性能。这个优化幅度放在一个已经很注意细节的成熟项目上是不可能达到的，但恰好反映了大多数原型阶段项目的优化空间。

5.2 复盘：哪些优化值得做，哪些优化其实得不偿失

复盘整个优化过程，我觉得最值得投入的优化按收益排序是：先解决N+1和索引失效问题，再引入Redis缓存，再做消息链路的异步化，最后考虑本地缓存和序列化字段裁剪。这个顺序也是投入产出比从高到低的排序。

有一点我想特别提醒：不要在一开始就疯狂引入缓存和消息队列。如果连数据库索引和业务代码里的循环查询都没处理好，缓存只是把问题向后推了一步，甚至会掩盖问题的真实面貌。比如N+1问题不解决，业务量上来后即使加了缓存，缓存过期瞬间的穿透流量依然会把数据库打垮。

至于得不偿失的优化，我自己的体会是：不要为了优化而优化。有些代码看似有重复查询，但实际上调用频率极低，一天只触发几次，给这种代码加缓存并没有意义，反而增加了维护成本和缓存一致性风险。我做优化时有一个原则：没有数据支撑的优化不做。任何一个改动之前，都要先记录当前基线数据，改完之后再对比效果。效果不明显的改动，果断回滚。

5.3 给后续项目的一个小建议：可观测性建设前移

如果把这次优化推倒重来，我会把可观测性建设放在更早的阶段，而不是等项目已经明显变慢之后才想起来搭。当时ChitChat前期的性能问题没有被及时发现，就是因为缺少基础的监控大盘，直到测试环境的卡顿已经肉眼可见时，才知道要开始优化。

好的实践其实是把监控埋点当成业务代码的一部分，跟着需求一起上线。早一点看到指标数据，就能早一点发现性能劣化的趋势，而不是在用户已经抱怨之后再做一次紧急事故排查。性能优化不是一次性的活动，它是一个需要持续反馈和调整的过程。只有可观测性指标在手，团队才能在每一次迭代中都清楚地知道，这次改动让ChitChat是变快了还是变慢了。