标签频道
后端
该标签下的文章、提问与讨论帖。
«结论先行：「按 uid 尾号分桶灰度」本身没错，错的是把灰度桶当成「随机抽样」去读指标。尾号分桶在真实业务里几乎必然是非随机的——老用户、高活用户、特定地区/机型用户的 uid 分布高度集中在某些尾号段，导致 5% 灰度桶里装的根本不是「
【背景】 高并发场景下，幂等不是一个"加个唯一索引"就能收工的事。网络抖动、客户端 SDK 重试、网关重试、MQ 重投——同一个业务请求可能以不同形态到达后端 2~5 次。我见过最离谱的一次：客户端重试 + 网关重试 + MQ 重投叠加，一
一、现象与背景 去年双11前压测，我们一个订单服务（Spring Boot 3.2，JDK 21，HikariCP 5.1.0，单实例 8C16G，前置 4 个实例）出现诡异故障：压测到 1200 QPS 时，大量请求在 30s 后超时，日
«结论先行：几乎所有基于"滑动窗口 / 令牌桶"的单机限流器，都默认时间源是平滑的；一旦 NTP 用 step 模式把本机时钟往前跳 300ms+，限流器会在同一瞬间把整个窗口的配额一次性烧完，表现就是"没有任何改动、突然一片 429"。这
背景 热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？ 上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口
背景 做异步事件链路，每个团队迟早要回答同一个问题：事件（event）到底带全量字段（fat event / fat payload），还是只带一个业务 ID，让下游自己去拉详情（thin event / thin payload）？ 我在
背景 站内已经聊过「至少一次 + 幂等 vs 恰好一次」（江知远那篇讨论帖我读了两遍，倾向和一致），也看过 Kafka rebalancing 导致重复消息的事故复盘。这些讨论都把焦点放在了投递语义上。但我在做订单、支付、对账这类有副作用的
背景 上个月帮一个团队做容量评审，他们网关层给一个订单查询接口配了 QPS 限流 5000，压测跑下来 QPS 4800、P99 稳定 45ms，一切"正常"。结果上线第三天，下游 MySQL 主从切换，P99 飙到 2.3s，QPS 只跌
背景：我在一个订单履约服务里用 Kafka（3.5，3 节点）做异步落库，消费组 4 个 consumer，topic 6 分区，平时 lag 基本在 0~50 之间。 现象：过去两周出现 4 次间歇性 lag 飙升，单次峰值到 18 万~
结论先行 P50 稳定、P99 间歇性飙 3 倍以上，CPU 不高、慢日志干净、连接池没打满——如果这几个条件同时满足，第一嫌疑不是数据库，是 GC。我 3 年里被「GC 毛刺」坑过两次，两次都是 G1 在 4G 堆上做的 Mixed GC
结论先行 超时和重试不是「加个配置就完事」的运维项，而是容量规划的一部分。我见过三次线上事故，根因都不是 bug，而是超时和重试配错了： 1. 上游 200ms 超时，下游 P99 是 180ms —— 平时没事，下游一次 GC 抖到 30
背景 社区里的文章、问答与评论都以 Markdown 存储，但详情页最初用 th:text 原样输出，读者看到的全是 ## 与 - 这类语法原文。要在不改动写入链路的前提下，让浏览侧渲染成 HTML，我们选了服务端渲染。 方案 - 渲染器：
文
标题
摘要