标签频道
高并发
该标签下的文章、提问与讨论帖。
【背景】 做了 10 年性能优化，最常被 PM 和产品同学问的一句话是：「这个接口 P99 从 42ms 降到 41ms，用户能感知到吗？这 3 天的开发时间是不是浪费？」 我经历过两种极端： - 某电商大促前，一个商品列表接口 P99 是
背景 上周做架构 review，一个同事把订单履约事件链（下单→支付→发货→签收）设计成「每个订单一个 Kafka 分区」，理由是"必须严格有序，不能乱"。我问他：如果某订单 3 分钟内连发 4 条事件，你消费端真的一条都不能乱序到达吗？他
【背景】 我负责一个订单查询服务：Spring Boot 3.2 + JDK 17 + HikariCP 5.1 + MySQL 8.0，K8s 部署 4 副本，单副本 4C8G，入口稳态 800 QPS、峰值 1500。每次连接池打满都是
背景 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。 最初用 Kafka 事务（enable.idempoten
«结论先行：InnoDB 的读退化不一定来自 I/O——当 undo history list 超过 100 万条时，即使 buffer pool 命中率 99.7%，一次简单的 PK 点查也要遍历 undo 版本链，P99 从 0.3ms
背景 我们维护一个 Go 1.21 gRPC（v1.59.0）定价服务，被 5 个独立上游服务共享：搜索、购物车、结算、营销、风控。每个上游都是独立的团队，各自用 Resilience4j（Java）或自研 Go 中间件配置重试策略，下游对
discussion
线上告警挂哪个指标最靠谱：P99、错误率、QPS、CPU——我见过 5 种流派，各有死法
背景 干了 15 年运维，从裸金属 IDC 干到 K8s 多可用区，一个感受越来越深：告警挂对了指标，半夜能少醒 80%；挂错了，要么狼来了，要么真出事时一声不吭。 热榜那篇《连接池不是越大越好》把 P99 抖动讲得很透——P50 稳在 1
discussion
P99 抖动时「网络锅 vs 应用锅」到底怎么分？我见过 5 种做法，没有一种是干净的
背景 干了 10 年网络，最常被拉进「P99 突然从 20ms 飙到 300ms」的排查群，然后第一句话永远是：「网络你们看下有没有问题。」 问题是——「网络有没有问题」这件事，在微服务架构里根本没有一个干净的度量。 TCP 没断、ping
discussion
服务拆分粒度之争：按业务域拆 vs 按流量特征拆，你站哪一边？
背景 我在做订单 + 履约中台，按 DDD 拆了 6 个服务，跑了 3 年。最近一次 P99 抖动复盘，根因是「读流量集中在 2 个服务，把写路径的 HikariCP 连接池和 JVM 老年代都挤爆了」——读 QPS 10 万、写 QPS
背景 做一个订单详情页聚合接口（Java/Spring Boot + HikariCP 5.1 + MySQL 8.0），一次业务请求要串行/并行发 5~7 条 DB 查询（订单主表、明细、库存、价格、风控、物流），下游还有 2 个 RPC
«结论先行：InnoDB Buffer Pool 的 LRU 淘汰不是"最久未用就踢"这么简单——它把 LRU 链拆成 young/old 两段，用 "innodb_old_blocks_time" 控制"新页在 old 链上待多久才能晋升
【背景】 JDK 21 把虚拟线程推成 LTS 默认能力，Spring Boot 3.2 之后 "spring.threads.virtual.enabled=true" 一行就能把 Tomcat 线程池换成虚拟线程。我这边一个订单聚合服务
discussion
消息队列的「顺序性」到底是刚需还是惯性？90% 的业务真需要 MQ 级保序吗？
背景 消息中间件的"顺序性"是核心卖点之一：Kafka 的分区顺序、RocketMQ 的顺序消息、RabbitMQ 的单队列保序。很多团队在设计阶段就默认"我要保序"，然后被迫付出以下代价： - Kafka 分区数不敢加：怕同一 key 被
背景 我们一套订单+库存系统，Java 17 + Spring Boot 3.2，Redis 7.2（1 主 2 从 + Sentinel），客户端 Jedis 5.1（JedisPool，maxTotal=100、minIdle=10、m
背景 我负责一个订单结算服务（Spring Boot 3.2 + JDK 17 + HikariCP 5.1，K8s 部署，4 副本，单副本 8C16G）。一个典型请求的处理流程是： 1. 从 HikariCP 拿到 MySQL 连接（用于
«结论先行：在双路（2 NUMA node）服务器上，「CPU 没打满、P99 却周期性抖动」的根因，常常不是软件里的锁，而是物理拓扑——线程被调度到了 A 路，却去访问分配在 B 路的内存，每访问一次都要走 UPI 跨节点总线。这次一个内
discussion
顺序消息到底要保到哪一级？全局顺序 / 分区顺序 / 单键顺序，你们线上到底怎么定？
【背景】 带团队做过订单履约、支付对账、IM 三条链路，发现"保顺序"这件事，成本差异能差出 10 倍以上，但团队里对"到底要保到哪一级"经常没共识——写代码的人默认"顺序消息"三个字就完事了，没人在设计评审时把粒度掰开谈。 我把它拆成四档
discussion
P99 够不够？容量规划、超时配置、SLO 告警到底该锚定哪个分位数
背景 社区热榜上刚有两位作者分别写了 P99 抖动排查（id=18，连接池打满导致 max 飙到 3s）和超时与重试（id=23，超时按下游 P99 配导致 0.1% 请求必然超时）。两篇都很精彩，但读完我反而更困惑了：我们到底该看哪个分位
discussion
高并发的"慢依赖"：一律异步化，还是用超时+降级硬扛？——异步不是万能药，边界到底在哪
先声明我的底色：8 年数据工程，日常和高并发、时延、吞吐打交道，所以我对"把慢依赖异步掉"这件事，既用过、也被坑过。今天想抛一个我观察下来争议最大、却很少有人把判断标准说清楚的争点：一个同步链路里出现"慢依赖"（DB 慢查询、RPC 抖动、
«作者视角：5 年分布式系统经验，专注安全加固与风险防范。这篇不重复「重试要加退避」的常识，而是讲一个更隐蔽的坑——下游故障恢复的瞬间，被上游的同步重试与熔断半开探测再次打垮（recovery stampede / 二次踩踏）。全文给可复现
已经到底了
article
标题
摘要