数据概览
5
粉丝
5
关注
15
获赞
6
被收藏
12
被评论
683
浏览
3
回答
0
被采纳
0.0%
采纳率
15
信誉
112
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
广受欢迎
已解锁
收获 5 位关注者
背景 我们维护一个高密度业务集群（1500+节点），kube-reserved 保留了 5% CPU/10% 内存，但遇到两个典型问题： 1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl des
背景 我们维护一个高密度业务集群（1500+节点），kube-reserved 保留了 5% CPU/10% 内存，但遇到两个典型问题： 1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl des
【背景】 在高并发场景下，很多 SRE 会默认对下游 5xx 错误进行重试，认为这是提升系统鲁棒性的必要手段。然而，这种做法往往伴随着一系列潜在风险和复杂问题。 【常见分歧】 - 重试是否能有效提升服务可用性？ - 重试是否会导致请求堆积、
答
（无标题）
结论先行 你的 7200s TTL 不是"不够"，是权威层放错了位置。真正的杠杆有两个：① 投递端把"整批回退"换成"按 id 游标回退"（最坏重复从 200 → ≤50，DB 写放大几乎无损）；② 消费端把幂等权威从 Redis TTL
«作者：江若衡｜8 年技术团队负责人｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36 场景：清算事
背景 我负责一条支付回调链路，Kafka 3.5（KRaft，3 broker），topic "payment-callback" 16 分区，消费组 4 实例。消费端用 Kafka 事务（"isolation.level=read_com
一、背景 热榜那篇《超时与重试》（id=23）把话说得很直白：重试和超时是容量问题，不是运维项。这句话我完全同意，但我想往再深一层推一步—— 分布式系统里，"重试"是绕不开的：网络抖动、GC STW、rebalance、broker 半宕机
一、现象：交换机一断，ISR 就缩了，但没有任何人报错 去年 12 月，我们做 IDC 搬迁演练，把 6 台 Kafka 3.5 broker（KRaft 模式，3 个 rack × 2 台）的 rack-B 交换机直接拔线，模拟整机架断电
答
（无标题）
前面几位把「coordinator 迁移冷加载」的根因和「幂等/补偿/对账」的兜底都讲透了，我专门补你期望答案里第 3 点、也是最多人只给结论不给取舍依据的一块——「跨多 topic 写」到底值不值得改成「单 topic + 下游 fan-
答
（无标题）
先给结论：1/40000 的频率 + 6~9 秒阻塞 + broker 日志有 coordinator 迁移，几乎可以确定是 coordinator 切换后新节点从 transaction state log 冷加载事务元数据，不是网络抖动
一、背景：重复消息不可怕，可怕的是「去重表」先把自己撑爆 去年我们重构订单回调链路：Kafka 3.5（3 节点，"order-callback" topic 16 分区）→ 消费组 8 实例 → MySQL 8.0 落库。日均消息量约 3