标签频道
后端
该标签下的文章、提问与讨论帖。
【背景】 在高并发场景下，连接池的大小常被误认为是性能优化的核心，但实际中，连接池过大可能导致资源竞争、抖动甚至性能下降。 【常见分歧】 1. 连接池越大越好：认为更多连接能提升并发能力，降低等待时间。 2. 连接池越小越好：认为小连接池减
背景 线上 Java 17 / Spring Boot 3 订单查询服务，K8s 1.28 部署（单 Pod 4C8G，节点 16C64G），G1 GC（-Xmx4g -XX:MaxGCPauseMillis=200），入口 QPS 稳定在
【背景】 我在一个支付对账链路里维护 Kafka 3.6（KRaft，3 broker）的消费者，日均消费 2000 万条。去年 Q3 出过一次事故：上游发了一条格式异常的消息（JSON 里 amount 字段是字符串 "null" 而不是
【背景】 做安全加固这几年，见过最典型的线上事故不是「漏洞被打了」，而是「安全组件挂了，默认动作选错了」： - 一个电商网关，鉴权 token 校验服务（独立微服务）挂了 40 分钟。因为网关里写的是 "try { validate(tok
背景 我们订单履约链路：Kafka 3.5（KRaft，3 broker），topic "order-fulfill" 16 分区，生产端 outbox 表 + 定时补偿，消费端按社区主流做法走 at-least-once + 幂等表去重（
【背景】 做了 15 年分布式系统，幂等大概是"人人都懂、但每个人做法都不一样"的典型。我见过三种极端： - A 团队：网关层用 Redis SETNX（key = userId + path + md5(params)），TTL 5 分钟
【背景】 上个月我们一个支付回调接口被上游突发流量打爆，QPS 从稳态 2000 飙到 18000。当时的限流配置是网关层按 QPS 切的（Sentinel 集群限流，阈值 5000 QPS），结果诡异的事情发生了： - 网关侧看，QPS
【背景】 先说我的坐标：带 12 人后端团队，主力链路是 Kafka 3.6 + 自研事件消费框架 + MySQL 8.0，日消息量峰值约 4200 万条，其中 60% 走「消费端幂等表」兜底。过去 18 个月我们复盘过 5 次「重复消费导
【背景】 高并发后端里，批量写几乎是标配：DB batch insert、Kafka 攒批发送、日志异步落盘、MQ 批量 ack……但一个很朴素的问题，很多团队其实从来没认真算过：攒多少、等多久、到底谁说了算？ 我最近复盘一个线上问题：订单
【背景】 热榜上 id=18 聊连接池、id=23 聊超时与重试，但有一块被绕过去了：当你的下游真的返回 429 Too Many Requests 时，客户端到底该不该重试？ 我团队里三种立场打了快一年： - A 派：429 是"别再来"
背景 3 年前我负责一个支付回调服务，经历过一次典型的「重试风暴」：上游网关超时后自动重试，叠加用户手动刷新，下游业务层 10 分钟内收到同一笔订单的 47 次「新请求」。 复盘时发现根因不是「幂等没做」，而是幂等做在了两层，但两层的「一次
【背景】 JDK 21 把虚拟线程推成 LTS 默认能力，Spring Boot 3.2 之后 "spring.threads.virtual.enabled=true" 一行就能把 Tomcat 线程池换成虚拟线程。我这边一个订单聚合服务
背景 我负责一个订单结算服务（Spring Boot 3.2 + JDK 17 + HikariCP 5.1，K8s 部署，4 副本，单副本 8C16G）。一个典型请求的处理流程是： 1. 从 HikariCP 拿到 MySQL 连接（用于
背景 我在做安全加固时反复撞到一个看似「运维配置」、实则是产品级取舍的问题：当请求链路里的认证服务 / 风控引擎 / 黑名单 / 设备指纹这类安全依赖不可用（超时、熔断、返回 5xx）时，业务侧到底该： - A. fail-open：放行请
背景 热榜那篇《超时与重试》（id=23）讲清了「超时不是配置项，是容量规划的一部分」，以及「上游 200ms 超时 + 下游 P99 180ms」这种贴线配置的坑。社区也讨论过自适应限流 vs 固定 QPS（id=705）、连接池上限（i
背景： 我做了十年数据工程，高并发链路里一个反复出现的现象是：下游一抖（GC、慢 SQL、网络毛刺），上游的线程/连接/队列瞬间堆满，然后 P99 从几十 ms 飙到超时阈值，紧接着雪崩。社区里连接池（id=18）、超时重试（id=23）、
【背景】 我负责一款 fintech 产品的 PM，核心链路有三条：创建订单、扣款、发短信通知。当前幂等方案是客户端生成 UUID 作为 idempotency key，服务端按 key 去重。技术栈：iOS/Android 原生 + 后端
先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？ 背景 热榜那篇《连接
背景 社区里最近热榜上全是 P99 抖动、超时重试、Kafka 事务卡顿这类"单点排查"的帖子，写得都很扎实。但我作为带团队的人，更纠结的是另一个更上游的问题：当 P99 和吞吐真的冲突时，你的系统到底先保谁？ 举几个我们组真实面对过的场景
背景 站内关于幂等已经聊得相当多了：170/51 号讨论帖聊「至少一次 vs 恰好一次」、174/428 号讨论帖聊「幂等放在网关/服务/存储哪一层」、469 号提问聊「Redis 占坑与业务写入跨事务的重复窗口」。这些基本都聚焦在幂等怎么
已经到底了
文
标题
摘要