早间推送高峰接口响应慢，优化顺序的核心思路是：先定位瓶颈、再改代码配置、后动架构扩容，不要一上来就加机器，那是最后的手段。
推送业务有个特点：早高峰集中、瞬时流量大、失败容忍度低，用户手机在 7 点到 9 点之间密集唤醒，接口要是卡个两三秒，用户直接划掉通知，业务指标立刻下滑，我见过不少团队，一遇到推送高峰接口响应慢，第一反应就是扩容，结果机器加上去了，P99 该超时还是超时，原因很简单，瓶颈根本不在机器够不够。
早间推送接口响应慢怎么优化：先定位拥堵点，再决定怎么治
优化顺序的第一步永远是看数据,不是猜，早间推送高峰接口响应慢，你得先搞清楚慢在哪一段，是整个网关慢，还是某个下游接口慢，还是数据库慢。
- 打开链路追踪系统,按时间筛选早间 7 点到 9 点，看接口的 P99、P95 耗时曲线。
- 看错误率和超时时间,确认是偶发超时还是持续高延迟。
- 看 JVM 的 GC 日志，确认有没有频繁 Full GC。
- 看 CPU、内存、磁盘 IO 的利用率，先排除硬件层面的异常。
很多团队跳过这一步,直接去调线程池、改代码，结果优化了个寂寞，定位瓶颈要落到具体的调用链路上，比如你用 SkyWalking 或 Zipkin，能看到每一步的耗时分布，哪个环节耗时从 50ms 涨到 800ms，一目了然。
另一个容易被忽略的动作是查慢查询日志,早间推送高峰伴随大量用户查询，数据库的慢 SQL 如果没治理过，接口响应慢几乎是必然的，打开 MySQL 的慢查询日志，按耗时排序，看前几个 SQL 是不是全表扫描、没有命中索引，这一条，很多情况下就能找到根因。
行业共识认为,80% 的接口性能问题集中在数据库和缓存层，而不是应用代码本身，所以定位阶段，数据库必须先查。
推送高峰接口性能优化步骤：按顺序清理代码、线程池和连接池
定位完成之后,进入真正的优化阶段，推送高峰接口性能优化步骤，我建议按下面的顺序来，每一步做完都压测验证，别一口气全改完。
第一动：检查线程池配置
推送接口一般会单独配置线程池,避免阻塞 Tomcat 的工作线程，很多团队把核心线程数设得很大，这反而是个坑，线程太多导致上下文切换开销飙升，CPU 全部花在切换上，真正干活的时间反而少了。
- 核心线程数：建议按 CPU 核数的 2 倍到 4 倍设置，具体看业务是 IO 密集型还是 CPU 密集型。
- 队列容量：推送高峰瞬时流量大，队列太短会导致拒绝策略触发太早；队列太长则拉高响应时延，因为任务全在排队。
- 拒绝策略：推送场景建议用 CallerRunsPolicy，让提交任务的线程自己去执行，避免直接丢弃消息。
调整完线程池,立即压测，用 Gatling 或 wrk 模拟早间推送的流量模型，看吞吐量和 P99 变化。
第二动：检查数据库连接池
推送高峰接口响应慢,数据库连接池打满也是常见触发点，HikariCP 默认最大连接数 10，这个配置在早间高峰根本不够用。
不过要提醒一点,别盲目调大连接数，每个连接都占用数据库的资源，连接数太大，数据库直接被压垮，接口从慢变成彻底不可用，正确的做法是：
- 确认连接池的最大连接数是否匹配数据库实例的规格。
- 检查 SQL 执行时间，连接池耗尽只是结果，根因通常是 SQL 本身太慢、事务太长。
- 确认是否存在连接泄漏,也就是代码里获取了连接但没有归还。
第三动：优化热点 SQL 和索引
早间推送的核心链路无非是：查用户设备信息、查用户偏好设置、写入推送记录，这三步的 SQL 都可能成为瓶颈。
- 对高频查询字段建立联合索引,比如用户 ID 加推送类型的组合字段。
- 避免在 SQL 里做函数运算，
WHERE DATE(create_time) = ...会导致索引失效。 - 分页查询不要用
LIMIT 100000, 20这种深分页写法，改用游标分页。
这些操作做完了,接口自身的能力基本就释放出来了，这里还有一个细节，推送高峰接口响应慢，有相当一部分比例是日志打太多导致的，每打印一条业务日志，即使到了日志平台，也占用 CPU 和 IO，早间高峰把日志级别从 INFO 调整成 WARN，接口耗时会明显下降，这个操作很多人想不到。
接口响应慢先查什么：缓存设计和依赖调用的隐藏坑
代码和配置调完之后,再看缓存和依赖调用这两层，早间推送接口如果每次都从数据库查，那优化空间再大也扛不住千万级的推送任务，接口响应慢先查什么，缓存命中和穿透是关键。
- 用户设备信息、App 版本、推送通道 Token 这类高频读取数据，本地缓存加 Redis 双层缓存承接。
- 缓存过期时间要设置随机值，避免同一时间大面积失效。
- 查缓存未命中的数据,加互斥锁或者布隆过滤器，防止缓存穿透瞬间打到数据库。
你大概率遇到过这种情况：推送任务下发瞬间，缓存里的 Token 大面积过期，数据库连接池瞬间被打满，接口集体超时，这不是服务挂了，是缓存雪崩了，处理方式很朴实地讲，就是错峰过期。
依赖调用也要查一遍,推送接口链路里通常要调用户服务、配置服务、风控服务，任何一个下游接口出现慢调用，上游主线程就会被拖住。
- 给所有下游调用设置读超时时间,建议500ms 到 1 秒，超过就熔断降级。
- 打开熔断器,连续失败比例达到阈值就快速失败，不继续消耗线程资源。
- 对不关键的依赖调用改成异步化,比如统计类、日志类操作，不阻塞主流程。
这一层优化完之后,推送高峰接口响应时间应该能回落到一个相对稳定的区间，如果还是没有明显改善，那才轮到架构层面的动作。
推送服务接口优化方案对比：改动小见效快的加缓存，改动大但支撑长远的上异步架构
架构调整一定是最后一步,但不是推翻重来的意思，业内专家指出，多数推送系统的性能瓶颈是读写比例失衡造成的，不需要重构，加一层缓存就能解决大部分问题。
这里做一个推送服务接口优化方案对比,方便你根据自身的瓶颈类型做选择。
| 优化手段 | 适用场景 | 改动量 | 见效速度 | 主要成本 |
|---|---|---|---|---|
| 加 Redis 缓存 | 重复查询多、数据变化慢 | 小 | 快 | 缓存一致性问题 |
| 调线程池和连接池 | 线程阻塞、资源耗尽 | 小 | 快 | 压测验证成本 |
| SQL 索引优化 | 慢 SQL 明显 | 小 | 快 | 索引维护成本 |
| 批量接口合并 | 推送任务逐条发送 | 中 | 中 | 对接方配合改造 |
| 异步化 + 消息队列 | 主链路依赖较多 | 大 | 中后期 | 消息不丢失、顺序性处理成本 |
| 服务扩容 | QPS 持续超出单机极限 | 很小 | 最快 | 费用成本 |
如果你已经定位到瓶颈是数据库查询,但加了缓存之后响应还是慢，那问题可能在推送任务的下发模式上，比如服务端一条条发送推送，每一条都有一次网络开销，改成批量拉取、批量写入，吞吐量直接翻倍。
再进一步,早间高峰推送是一个典型的突发流量场景，平峰和高峰的 QPS 差距可能达到几十倍，针对这个特点，最优方案是把同步下发改成异步削峰：推送任务先写入消息队列，下游消费端按照自己的消费能力拉取推送，既保护了自身接口，也保护了下游通道，这个方案还能顺便解决另一类问题对接多个厂商推送通道时，通道本身有 QPS 限制，异步削峰可以精确匹配通道上限。
推送高峰接口性能优化步骤走到这一步,你已经完成了从定位到配置，再到架构层面的完整闭环，说白了，早间推送接口响应慢，最怕的就是跳过排查直接扩容，那样不但没解决慢，还把成本打上去了。
整体优化做完后,还有一件小事值得做回看日志和监控数据，把早间高峰这段时间的指标存下来，作为下一次优化的基线，推送这个业务很有规律，今天调好了，过俩月用户量翻倍又会慢，有基线数据在手，下次排查就快得多。
关于早间推送接口响应慢的常见问题
早间推送高峰接口响应慢怎么优化最有效？
最有效的动作是观察链路追踪里,耗时占比最高的那个环节，然后精准爆破，用 SkyWalking 或 Pinpoint 打开任意一条慢请求 Trace，超过 60% 的耗时集中在哪一步，排查重点就放到哪里，多数情况下，慢的不是应用代码，而是一次没走索引的数据库查询或一次迟迟不返回的下游调用。
接口慢优化方案对比里，扩容是优先级最高的一项吗？
不是,扩容是兜底手段，不是优化手段，推送接口的瓶颈通常在于线程阻塞、锁竞争、串行调用，先解决这些进程内的问题，再考虑加机器，在进程没有优化的情况下扩容，只会让更多机器同时卡在同一个瓶颈问题上。
推送高峰接口响应慢，调线程池参数有哪些实际经验值？
核心线程数设为 CPU 核数的两倍，最大线程数等于核心线程数即可，队列用有界队列，容量看任务平均耗时和目标等待时长，超时时间设置在 300ms 到 500ms，过了就放到重试队列，这个配置适合大多数 IO 密集型的推送服务，压测后微调即可确定最终值。
早间推送高峰接口响应慢,本质上是资源错配的问题，优化顺序是一条清晰的决策链：定位、配置、缓存、架构，按这个顺序走，每一步都有数据支撑，每一步都可回退，别急着加机器，先把现有资源的潜力挖干净。