请求折叠的魔术：数据库总耗时降低了25%？本文聚焦 WebSocket 服务中一条高耗时 SQL，其平均耗时 2ms 却

一、诡异的 SQL 现象：2ms 的 SQL 竟占 27% 耗时

上周在排查 WebSocket 服务性能时，发现一条 "平平无奇" 的 SQL 堪称数据库杀手：

UPDATE client SET last_time=? WHERE id=?

监控数据让我惊掉下巴：

平均执行耗时仅 1.95ms
却占据了数据库总耗时的 27%
每秒执行次数高达 721 次！

高峰期 10 点到 22 点，峰值甚至达到 750 次 / 秒。这意味着什么？假设数据库连接池最大连接数 100，这条 SQL 就可能占用 7 个连接，直接导致其他业务卡顿。

二、追查真凶：Netty里的 "定时炸弹"

第一反应是 WebSocket 心跳机制在搞鬼，查看 Netty ChannelPipeline 配置：

查看该心跳处理器，心跳处理器中没有做任何DB交互可以，排除心跳处理器

如果是在非心跳处理器的场景，仍然这么频繁的更新状态，那么最大可能有2个场景： 1、在Netty写场景的时候，设置了出站处理器，在每次出站的时候更新了设备最后在线时间

2、在Netty读场景的时候，设置了入站处理器，在每次收到读事件都去更新设备最后在线时间

从场景上分析，场景2的可能性比较大。

分析Netty ChannelPipeline，发现除了MyWebSocketFrameHandler，其他的处理器都是Netty原生

而MyWebSocketFrameHandler又是一个入站处理器，所以基本定位是在MyWebSocketFrameHandler内部更新了设备的最后在线时间

在MyWebSocketFrameHandler内部将心跳帧去做了设备更新操作

结论：

1、在每一次ws的文本帧消息，打印结果推送的时候，都会去更新状态

2、即使是心跳帧，也会在MyWebSocketFrameHandler更新设备状态

真相是：每次收到 WebSocket 消息，无论是否是心跳帧，都会执行一次 DB 更新

三、确定优化方案

3.1 优化思路

从代码上看，在业务量比较小的时候，这种方式去更新db是很难暴露问题的，因为是根据id更新单条SQL执行只要2ms。当业务量增加后，设备变多，每次心条都更新设备在线时间，对db的压力就逐渐增加了。

一般来说项目通常会达到性能的瓶颈。这些瓶颈总结起来，大概有两种，读瓶颈，和写瓶颈

而当前场景是写瓶颈，写瓶颈的处理方式通用的例如异步、打散、合并

高频、多次、散点的场景可以考虑使用请求折叠（合并）

请求折叠思路很常见，例如：

TCP网络协议-Nagle算法

Kafka中也见过类似的优化-在发送消息的时候并不是一条条的发送的，而是会把多条消息合并成一个批次Batch 进行处理发送

请求折叠主要是2个维度合并：

大小
时间

Kafka中这2个配置分别对应batch.size、linger.ms，达到任意一个条件都开始执行

3.2 方案调研

一、redis

更新数据存redis、定期任务合并刷库

xxl-job任务为秒级，以任务间隔设置为5s为例

按峰值750TPS，每次请求记录id和时间，单json大小约等于50字符，5s可产生3750个json对象。redis key所占大小约为200kb左右，所以可以按照每个品牌一个key隔离。

优点：不需要额外引入新的依赖

缺点：只能从时间维度控制频率，随着业务增长，每个批次处理的数据量不可控，导致job执行间隔不可控

二、Hystrix

Hystrix自带请求折叠组件---「hystrix Request Collapsing」

            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
                <version>${spring-cloud-starter-netflix-hystrix.verson}</version>
            </dependency>