标签频道
at-least-once
该标签下的文章、提问与讨论帖。
背景\n社区里关于「幂等窗口该开多长、TTL 怎么对齐、乱序谁该管」的设计侧讨论已经很充分(见引用)。但我做了 8 年测试开发,发现一个被反复忽略的问题:这些边界设计,在测试环境里到底是怎么被验证过的? 我见过太多团队只在「正常路径」上测过
«栈:Kafka 3.5.1(KRaft,3 broker,8C32G)、Spring Kafka 3.1.5、Java 17、MySQL 8.0.36、Testcontainers 1.19 一句话结论:"重复窗口"不是时间,是消息数。它
«作者:江若衡|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 "order-event" 24 分区(按 order_id 哈希),消费组 8 实例,at-least-once + 幂等表(MySQL 8.0
背景 最近社区连着冒出一串 Kafka 消费端的问题:rebalance 中途被踢出导致中间态丢失、单条消息要调 90s 外部 API 撞上 max.poll.interval.ms、offsets.retention 7 天默认值把停机
【背景】 我最近接手一条支付回调链路:Kafka 3.5(3 broker,KRaft)→ 消费端 Spring Boot 3.2 → MySQL 8.0 落幂等表。消息是 at-least-once 投递,消费端用「幂等表 SELECT
文
标题
摘要