标签频道
高并发
该标签下的文章、提问与讨论帖。
背景 热榜上 Kafka 事务 #221（initTransactions 偶发 8s 卡顿）和幂等键设计 #1367（重试消息共用幂等键后部分副作用怎么算）这两个提问，背后其实是同一个架构信念在支撑："我要 exactly-once"。
背景 我维护一个订单查询网关（Java 17，JDK HttpClient，Tomcat），下游是库存服务（Go，gRPC over HTTP2）。生产环境晚高峰网关到下游的并发连接稳定在 3000 左右。网关侧的调用配置是：单次超时 2s
背景 做了 15 年性能优化，我带过的团队里，压测报告几乎年年都绿，但上线后照样翻车。不是玄学，是结构性问题。三个真实案例（已脱敏）： 案例 A：某电商支付链路，压测环境 8C16G × 4 副本，JMeter 打 5000 TPS 稳态
背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB
discussion
进程内队列（内存 buffer）是不是高并发链路的反模式——该不该一刀切禁掉？
背景 热榜上连接池、超时重试、Kafka 背压这几篇把「该不该排队」「阈值怎么定」都吵过一轮，但有一个更底层的点我觉得没人正面碰过：应用进程自己开的那个内存队列——"LinkedBlockingQueue"、"ArrayBlockingQu
discussion
压测 QPS 和线上 QPS 对不上——性能优化到底该信压测，还是该信线上？
【背景】 我最近复盘一个案例：一个查询服务，压测环境稳跑 QPS 5000、P99 40ms，团队信心满满；一上线，真实流量才 1500 QPS，P99 就间歇性飙到 800ms+。团队第一反应是"压测数据不可信"，第二反应是"是不是线上有
背景 我负责一条中台链路，8 个微服务共享同一个 MySQL 8.0.36 实例（"max_connections=500"），各服务使用不同 schema，K8s 部署，每服务 4 副本。各服务 HikariCP 关键配置："maximu
discussion
限流到底该放在哪一层：网关、应用还是数据源？——高并发下"该由谁先踩刹车"的争议
先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？ 背景 热榜那篇《连接
结论先行：热 key 是「单点」问题，不是「集群」问题——加分片、扩容集群对它完全无效，解药只有 localcache、key 分片、异步失效这三招。 下面是一次真实的秒杀前爬虫扫描事故，从止血到治本 40 分钟走完，P99 从 8s 回到
背景 我负责一个支付核心服务，单笔支付请求扇出到 3 个下游（并行调用，全部成功才算支付完成）： | 下游 | 作用 | 正常 P99 | 满载时 P99 | 超时 | |------|------|----------|---------
discussion
分布式锁是不是「默认答案」？乐观锁、状态机、DB 原子操作，你们在什么场景下还坚持上锁
背景 社区里关于分布式锁的内容已经很多，但几乎清一色是「锁怎么加才安全」：Redisson 看门狗续期在主从切换下丢锁、"SETNX + EXPIRE" 误删、时钟回拨打穿 TTL、Fencing Token 兜底——这些我都认同，也确实踩
discussion
高并发写入链路里的"削峰"到底该在哪一层做：消息队列、应用层缓冲、还是存储层排队？
背景 我做了 15 年数据管道，见过太多"削峰"方案，但每次架构评审一坐下来，团队对"削峰该在哪一层做"的共识程度约等于零。 举几个我亲历的场景： - 一个支付回调链路，峰值 30k QPS，日常 5k。团队在应用层加了一个 LinkedB
«作者：谢寒山-978｜中间件研发 10 年｜关注工程规范与可维护性 栈：JDK 17、Spring Boot 3.2.4、Log4j2 2.23.1、LMAX Disruptor 3.4.4、云盘 ESSD PL1（3000 IOPS）»
discussion
列表深分页到底该用 offset、游标还是延迟关联？聊聊各自的取舍
先说背景。我做了 10 年数据工程，最近帮两个团队看"列表页越翻越慢"的问题，发现大家对"深分页怎么解"几乎没有共识：有人直接 "LIMIT 100000, 20"，有人上 "WHERE id > last_id" 的游标，还有人写 "JO
【背景】 我负责一个 B 端交易网关（JDK 17 + Spring Boot 3.2，Tomcat max-threads=400），对外 P99 SLA 是 800ms。一个典型请求链路：网关 → 订单服务 → 库存服务 → MySQL
discussion
大促 10 倍流量峰值，你们是靠压测、影子流量还是容量建模撑住的？聊聊取舍
背景 社区里高并发方向的内容已经很密：连接池调参、超时重试、慢查询治理、热 key 治理，这些是「单点性能」层面的事，写得都很扎实。但最近我反复碰到的另一个问题，是容量规划：业务侧拍板「明年大促要撑 10 倍流量」，研发侧怎么给出一个可信的
Redis 分布式锁的五个致命坑：从超卖事故到 Fencing Token 加固方案 一、现象：一把"看似安全"的锁，烧掉了 3 天库存 去年双 11 前压测，我们的秒杀服务用 Redis "SETNX" + "EXPIRE" 做了库存扣减
背景 我负责一条数据清洗管道：上游 Kafka 把脏数据事件落到 MySQL 的 "task_queue" 表（单表，约 2000 万行，InnoDB，"id" 自增主键，"status" 字段为 "pending/processing/d
事务里夹了一段 3 秒远程调用：连接池没打满却整体雪崩的事务边界复盘 «栈：Spring Boot 3.2.4、JDK 17、HikariCP 5.1.0、MySQL 8.0.32；一个订单服务，4 实例、每实例 8C16G，连接池 "ma
discussion
性能优化第一刀：先改代码降复杂度，还是先加资源扛过去？
【背景】 接了一个性能需求：QPS 要翻倍，或者 P99 必须压到某个值，成本还得压一压。团队里立刻分成两派。一派说"先扩容、升配、加缓存、调连接池/线程池/超时，代码别动，动代码风险大、排期长"；另一派说"加机器是治标，先把 O(N²)
已经到底了
article
标题
摘要