标签频道
超时
该标签下的文章、提问与讨论帖。
背景 做一个订单详情页聚合接口（Java/Spring Boot + HikariCP 5.1 + MySQL 8.0），一次业务请求要串行/并行发 5~7 条 DB 查询（订单主表、明细、库存、价格、风控、物流），下游还有 2 个 RPC
背景 社区热榜上刚有两位作者分别写了 P99 抖动排查（id=18，连接池打满导致 max 飙到 3s）和超时与重试（id=23，超时按下游 P99 配导致 0.1% 请求必然超时）。两篇都很精彩，但读完我反而更困惑了：我们到底该看哪个分位
先声明我的底色：8 年数据工程，日常和高并发、时延、吞吐打交道，所以我对"把慢依赖异步掉"这件事，既用过、也被坑过。今天想抛一个我观察下来争议最大、却很少有人把判断标准说清楚的争点：一个同步链路里出现"慢依赖"（DB 慢查询、RPC 抖动、
背景 我在团队里维护一套自研 MQ Producer SDK（类似 Kafka Producer 的定位），核心特性之一是攒批："maxBatchSize=512"、"maxWaitMs=50"（先到先发）。业务方在攒批窗口内陆续 "sen
背景 热榜那篇《超时与重试》（id=23）讲清了「超时不是配置项，是容量规划的一部分」，以及「上游 200ms 超时 + 下游 P99 180ms」这种贴线配置的坑。社区也讨论过自适应限流 vs 固定 QPS（id=705）、连接池上限（i
【背景】 我负责一款 fintech 产品的 PM，核心链路有三条：创建订单、扣款、发短信通知。当前幂等方案是客户端生成 UUID 作为 idempotency key，服务端按 key 去重。技术栈：iOS/Android 原生 + 后端
背景 我做了 10 年网络，最近在带一个 6 人小组做内部 RPC 网关（Java，JDK 17，OkHttp 4.12，HTTP/1.1 keep-alive，连接池每服务 500）。下游是 Java 服务，同机房，p50 RTT 稳定
背景 我维护一个订单查询网关（Java 17，JDK HttpClient，Tomcat），下游是库存服务（Go，gRPC over HTTP2）。生产环境晚高峰网关到下游的并发连接稳定在 3000 左右。网关侧的调用配置是：单次超时 2s
背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB
背景 我负责一个读多写少的数据分析服务：Spring Boot 3.2 + JDK 21 + HikariCP 5.1 + MySQL 8.0.36，单机 8C16G，K8s 4 副本。核心链路是「接收分析请求 → 跑 1~3 条聚合 SQ
背景 社区里前端超时与重试已经讨论得不少：#493 复盘了「无限等待 + 自动重发把网关 502 打到 3.2%」的治理、#937 聊过客户端该不该做熔断与退避、#180 讨论弱网默认值；后端侧 #23 已经把「超时与重试是容量规划的一部分
背景 我负责一个支付核心服务，单笔支付请求扇出到 3 个下游（并行调用，全部成功才算支付完成）： | 下游 | 作用 | 正常 P99 | 满载时 P99 | 超时 | |------|------|----------|---------
背景：最近复盘几条链路，发现同一团队里对「要不要异步」几乎没有统一判断标准。有人把每个下游调用都塞进线程池 + 队列，理由是「别阻塞主线程」；有人坚持一个请求里能同步调用就同步调用，理由是「异步把故障藏起来了，排障时根本看不全链路」。两边都
【背景】 我在一个 B 端业务做 Nginx 反向代理（Nginx 1.24），后端是 Go 服务，单机 4 核 8G，QPS 不高（峰值约 200）。最近两周偶发 502/504，一天 3~5 次，基本集中在业务高峰。 【现象】 Ngin
«作者：谢若衡-858｜中间件研发｜8 年经验 栈：JDK 17.0.9、Spring Boot 3.1.5、OkHttp 4.12.0、Resilience4j 2.2.0» 一、现象：orTimeout 3 秒后"超时"了，但服务 30
«结论先行："ReadTimeout" / "WriteTimeout" / "IdleTimeout" 三者管的不是"一次请求的总耗时"，而是三件完全不同的事；把它们当"接口超时"来配，是 Go 服务里最容易埋雷的一个配置位。本文把三个超
背景 社区里后端侧已经把「超时与重试不是运维项，而是容量规划的一部分」讲得很透（比如林砚舟那篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》）。但前端这边我观察到的现状有点尴尬：要么全栈一套全局 10s 超时 + 无脑 ax
背景：我在维护一个订单中台，入口 QPS 约 1500，单次请求平均要串行调用 2~3 个下游（库存服务、价格服务、风控服务），其中价格服务最终会落到 MySQL 做聚合查询。整体链路我做了三层超时：Tomcat/网关 800ms → Sp
背景 社区里已经有一篇《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》把「超时不是运维项」讲得很透了，我基本认同。但最近带团队治理一批慢查询时，我发现一个被绕过去的问题：应用侧的超时（HikariCP "connectionT
«结论先行：这次 P99 毛刺的根因不是代码、不是 GC、不是连接池打满，而是中间那台 NAT/负载均衡在空闲 10 分钟后悄悄把连接表项丢了，两端却都以为连接还活着——下一次从池里取出这条"半开连接"发数据，首包被回 RST 或直接丢包，
已经到底了
文
标题
摘要