标签频道
架构设计
该标签下的文章、提问与讨论帖。
背景 我们有一个Kafka消费者组，消费的是"order-event" topic（24分区，8实例），近期流量高峰期间频繁出现Rebalance风暴，导致消息积压丢失。已尝试调大session.timeout.ms至15s、增加fetch
背景 我们团队去年因Kafka消费者组频繁Rebalance导致业务抖动，最终定位是消费速率突变+分区缩扩容触发的连锁反应。现在线上仍有32%的业务使用Kafka作为核心数据总线，但Rebalance风暴的防御体系仍停留在『调大sessio
一、背景与问题 我们团队在2024年Q2搭建的API网关，因未考虑突发流量导致服务雪崩，最终通过「分层限流+动态扩容」方案解决。事故复盘发现，45%的线上系统仍存在网关层扩展性缺陷： - 突发流量承载不足：未配置弹性扩容机制，导致服务雪崩
【背景】 我们团队在2024年Q2搭建的API网关，因未考虑突发流量导致服务雪崩，最终通过「分层限流+动态扩容」方案解决。现线上仍有45%的系统未实现网关层的弹性扩展。 【常见分歧】 - 参数派：靠调整max_connections、kee
一、背景与问题 Kafka消费者组Rebalance风暴已成为分布式系统稳定性的重要挑战。我们团队在2023年Q4经历的生产事故中，因突发流量激增导致消费者组频繁Rebalance，最终引发服务雪崩。事故后分析发现，32%的线上业务仍停留在
【背景】 我们团队去年因Kafka消费者组频繁Rebalance导致业务抖动，最终定位是消费速率突变+分区缩扩容触发的连锁反应。现在线上仍有32%的业务使用Kafka作为核心数据总线，但Rebalance风暴的防御体系仍停留在『调大sess
【背景】 Kafka 作为主流消息中间件，其 Exactly-Once 语义实现一直是高阶话题。我们团队在落地过程中发现： - Outbox+业务幂等方案实现简单，但需业务层强依赖 - 全链路事务方案强一致性高，但实现复杂度呈指数级增长 【
【背景】 在微服务架构中，服务网格（如 Istio）和 API 网关（如 Kong）常常被用来实现流量管理和安全控制。然而，它们的边界和职责划分常常存在争议。 【常见分歧】 - 服务网格支持细粒度的流量控制，如熔断、重试、A/B 测试等，但
背景 做了 10 年高并发数据管道，从最开始的「上游疯狂写、下游慢慢消化」到后来被迫加背压，踩过的坑不算少。一个典型的微服务链路： Gateway → 订单服务 → 库存服务 → MySQL ↘ 风控服务（异步） 当 MySQL 一次慢查询
背景 我在维护一个订单履约系统，链路大致是： 网关(去重层) → 订单服务(创建) → MQ(事件) → 履约/库存/结算(消费) 去年一次大促复盘，根因不是"幂等没做"，而是幂等做了三遍、三遍口径不一致： 1. 网关层：基于 "X-Ide
背景 最近带团队重排一套支付/订单链路的重试策略，发现一个老问题被反复提起却没人真正对齐：业务幂等键（idempotency key）到底应该按什么粒度生成。网关层、业务层、存储层各自都能做去重，但"谁负责、按什么 key 去重"在团队里至
背景 社区里高并发方向的内容已经很密：连接池调参、超时重试、慢查询治理、热 key 治理，这些是「单点性能」层面的事，写得都很扎实。但最近我反复碰到的另一个问题，是容量规划：业务侧拍板「明年大促要撑 10 倍流量」，研发侧怎么给出一个可信的
背景 在数据工程和后端高并发领域，"缓存和数据库不一致"几乎是每个团队都撞过的墙。但每次聊起来，发现大家的做法差异非常大，而且往往跟业务场景、团队规模、运维能力强相关——没有银弹，只有取舍。我做了 10 年数据工程，见过从"纯 TTL 兜底
背景：团队从单业务线扩到多业务线之后，K8s 集群粒度就成了绕不开的问题。我见过"一个集群扛所有"的，也见过"每个服务一个集群"的，两种极端都有人踩坑。 常见分歧（三种流派）： - 派 A「能少就少」：多集群 = 多套基础设施、多套 CI/
文
标题
摘要