后端

【背景】 我们用 Kafka 3.6（3 broker，topic "order-paid" 32 分区）承载订单支付成功事件，消费组 12 实例（每实例 2~3 分区），日均约 800 万条，峰值 6500 msg/s。消费逻辑如下： 1

结论先行 如果一次「正常流量压测全绿、合法输入 P99 只有几百纳秒」的校验接口，却在某天被几个恶意请求把整台机器 CPU 打满——第一嫌疑不是下游、不是 GC、不是连接池，而是那条你以为很普通的正则。我上个月在 UGC 服务上栽过：一个用

【背景】 我们用 Kafka 3.6（3 broker，topic "order-event" 64 分区）承载订单事件分发链路：消费组 16 实例（每实例 4 分区），日均约 3000 万条，峰值 12000 msg/s。下游是 gRPC

一、现象：为什么我的 compacted topic 在删 key 后 30 分钟还在返回旧值 去年 11 月，我们给一个内部配置中心做了迁移：把原本走 ZK 的 key-value 配置搬到了 Kafka compacted topic（

【背景】 高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。RT 从 80ms 降到 15ms，P99 从 300ms 降到 60ms，压测报告一片绿——然后呢？ 我最近帮一个团队做 review，他们的订单支付链路：创

背景：讨论投递语义（at-least-once vs exactly-once）、讨论幂等该放哪一层，社区都聊过不少了。但真正到生产里，最让人睡不着的其实不是"消息重了"，而是另一种更隐蔽的形态——链路走到一半挂了，前面几步已经产生了副作用

背景 社区里 K8s 侧的「优雅停机」已经讲得很透了——preStop、terminationGracePeriodSeconds、摘流量时序、in-flight 排空，好几篇都在讲「编排层怎么给窗口」。但我最近在一个组里发现，真正翻车的往

【背景】 我负责一个支付网关服务：Spring Boot 3.2 + JDK 17（G1，"-Xmx4g"，tiered compilation 开启，默认参数）+ MySQL 8 + Redis 7，K8s 滚动发布，单副本 4C8G，Q

【背景】 我们订单履约链路用 Kafka 3.5（3 节点）传事件，topic "order-fulfill" 16 分区，消息体是裸 JSON（没有 Avro/Schema Registry），生产端是 3 个微服务版本不一致地灰度发布，

«结论先行："SET key val NX" 拿到锁这件事，本身不携带任何持久性保证。在 Redis Sentinel / 主从架构里，锁是写在单机主库上的一条普通 key，靠异步复制传给从库——主库在复制确认前宕机，这条锁就会从整个集群里

【背景】 高并发场景下，幂等不是一个"加个唯一索引"就能收工的事。网络抖动、客户端 SDK 重试、网关重试、MQ 重投——同一个业务请求可能以不同形态到达后端 2~5 次。我见过最离谱的一次：客户端重试 + 网关重试 + MQ 重投叠加，一

背景 我最近在帮一个组定「服务间调用的公共规范」，走到「默认要不要开重试」这一步，组内直接吵起来了。这个点平时大家各自服务里都有一套，但没人愿意把它写成团队级默认值——因为它一旦写成默认，就等于替所有调用方做了决定。 三种常见做法（也是三种

【背景】 Spring Boot 3.2 + JDK 17 + MySQL 8.0 + HikariCP 5.1，池大小 20，connectionTimeout=3000ms，minimumIdle=5，maxLifetime=1800s

背景：做订单/支付/库存这类异步链路时，"顺序"几乎是每个团队绕不开的关键词。Kafka 用一个 partition 天然保证 per-key 有序，大家也默认"保证顺序"是理所当然的事。但真正落到生产里，顺序是最容易被悄悄打破、又最难被察

【背景】 我做订单履约服务，Kafka 3.5（3 节点），topic "order-fulfill" 16 分区，实时消费组 8 实例，日均约 4000 万条，消费逻辑是「读 batch → 写 MySQL 8.0 → 提交 offset

结论先行：热 key 的根因不是「Redis 慢」，而是集群分片均衡被单 key 击穿——所有读都落在同一个分片上，其余 7 个分片在空转。解法不是加机器、不是调 Redis，而是把 90% 的读拦在应用进程内（本地缓存），用一致性令牌控制

【背景】 订单履约链路，Kafka 3.5（3 broker，KRaft）。事务生产者：enable.idempotence=true，transactional.id=order-fulfil-{instance}，同一个事务内顺序写三个

结论先行 先给结论：在一台 8 物理核 / 16 逻辑核的机器上，8 个线程各自累加一个 "long" 计数器，如果这些计数器在堆内存里"挨着"，总吞吐只有 1180 万 ops/s；把它们各自撑到独占一条 64 字节缓存行之后，同一台机器

一、现象与背景 去年双11前压测，我们一个订单服务（Spring Boot 3.2，JDK 21，HikariCP 5.1.0，单实例 8C16G，前置 4 个实例）出现诡异故障：压测到 1200 QPS 时，大量请求在 30s 后超时，日

背景 做了 10 年性能优化，带过的团队里有一个反复出现的"信任危机"：压测报告写得很漂亮，P50 / P99 都达标，但一上真实流量，P99 就翻 2~3 倍。不是每次都这样，但每次遇到，排查起来都很痛苦——因为压测数据"看起来是对的"，