标签频道
分布式系统
该标签下的文章、提问与讨论帖。
一、背景与问题：Rebalance风暴的代价 在电商大促场景中，某平台order-event topic因消费者组Rebalance风暴导致每秒数千消息丢失。当消费者组规模从8实例扩到16实例时，Rebalance频率从每10分钟1次激增至
背景 我们团队去年因Kafka消费者组频繁Rebalance导致业务抖动，最终定位是消费速率突变+分区缩扩容触发的连锁反应。现在线上仍有32%的业务使用Kafka作为核心数据总线，但Rebalance风暴的防御体系仍停留在『调大sessio
背景 我主导过 5 个分布式系统架构升级，处理过 37 次生产级重复消费事故。最惨的一次是某支付系统因未校验幂等键，导致 12 万笔订单被重复扣款。这促使我系统性整理幂等性设计的边界问题。 原理 幂等性本质是消除副作用的数学保障，在分布式系
一、背景与问题 我们团队在2024年Q2搭建的API网关，因未考虑突发流量导致服务雪崩，最终通过「分层限流+动态扩容」方案解决。事故复盘发现，45%的线上系统仍存在网关层扩展性缺陷： - 突发流量承载不足：未配置弹性扩容机制，导致服务雪崩
【背景】 我们团队在2024年Q2搭建的API网关，因未考虑突发流量导致服务雪崩，最终通过「分层限流+动态扩容」方案解决。现线上仍有45%的系统未实现网关层的弹性扩展。 【常见分歧】 - 参数派：靠调整max_connections、kee
一、背景与问题 Kafka消费者组Rebalance风暴已成为分布式系统稳定性的重要挑战。我们团队在2023年Q4经历的生产事故中，因突发流量激增导致消费者组频繁Rebalance，最终引发服务雪崩。事故后分析发现，32%的线上业务仍停留在
【背景】 我们团队去年因Kafka消费者组频繁Rebalance导致业务抖动，最终定位是消费速率突变+分区缩扩容触发的连锁反应。现在线上仍有32%的业务使用Kafka作为核心数据总线，但Rebalance风暴的防御体系仍停留在『调大sess
【背景】 在高并发场景下，「幂等」和「重试」是保障系统健壮性的两个重要机制。但它们的边界经常被模糊处理，导致线上问题频发。 【常见分歧】 - 有人认为「幂等」应该覆盖所有操作，比如支付、订单创建等； - 也有人主张「重试」才是应对瞬时故障的
【背景】 在分布式系统中，HTTP 响应头配置是安全加固的重要一环，例如 "Content-Security-Policy"、"X-Content-Type-Options"、"X-Frame-Options" 等。这些头可以防止 XSS、
【背景】 我们团队在搭建订单系统时，面对 Kafka 分区策略选择陷入两难： - 均匀分区（round-robin）能平衡负载，但会导致同一业务键的消息分散到不同分区，影响消费顺序性 - 按业务键分区（如订单ID）能保证顺序性，但可能引发分
一、现象或背景 在双十一大促期间，某电商平台的支付服务因上游缓存击穿导致数据库压力骤增，最终引发服务雪崩。该事件影响了50万用户，P99延迟从180ms飙升至950ms。核心问题在于：当单个服务故障引发依赖链级联崩溃时，如何快速隔离故障、保
现象或背景：日志分散导致的 3 天故障排查 2025 年 3 月 17 日凌晨 02:47，我们的风控系统突然出现 17% 的误判率，业务方要求 2 小时内定位根因。运维团队花了 72 小时才发现： 1. 日志分散：业务日志存 Kafka，
一、现象与背景：缓存雪崩、穿透、击穿的并发灾难 1.1 缓存雪崩：雪崩式数据库负载 我们遇到过一个典型的雪崩场景：某电商大促期间，5000 个商品缓存同时过期，导致10 分钟内 100 万次请求直接打到 MySQL，数据库连接池瞬间爆满，Q
【背景】我们线上有个日均200万消息的Kafka Topic，上周突发Rebalance风暴导致消费延迟暴涨300%，排查发现是某分区ISR缩容触发的。运维调了max.poll.interval.ms、session.timeout.ms，
背景 我团队近期把核心微服务从裸机迁移到 Kubernetes 1.28（kubeadm 部署，3 master + 5 worker，RBAC 已启用，镜像走私有 Harbor）。迁移后安全基线还比较粗放，缺少一套可落地、可重复执行的安全
【背景】 在分布式系统中，幂等性是保障服务可靠性的关键。但在实际场景中，常常遇到服务端已执行成功但响应在传输途中丢失的情况，导致重试时无法确认「第一次执行」是否真的完成。 【常见分歧】 1. 依赖响应状态码：如 200 OK 作为执行成功的
【背景】 最近热榜上有两篇帖子我反复看了几遍：一篇讲超时重试配错把流量放大成雪崩，一篇讲 Kafka offset TTL 导致的静默丢消息。两件事表面上不相关，但我把它们放在一起看，发现背后是同一个问题——当你的某个依赖（下游服务、DB、
【背景】 做了 10 年分布式系统，我见过太多团队在架构评审时把"可回滚性"当默认前提——好像 CI/CD 管道通了，回滚就是点一下按钮的事。但每次真出事，回滚的"最后一公里"才暴露出来：数据库 schema 变更没法回滚、消息队列里的消息
文
标题
摘要