标签频道
消息中间件
该标签下的文章、提问与讨论帖。
背景 - Kafka 3.4(3 broker KRaft),topic "risk-eval-result" 64 分区,消费组 8 实例(每实例 8 分区) - 消费逻辑固定三步:"consumer.poll()" → 调外部风控引擎
背景 热榜上 Kafka 事务 #221(initTransactions 偶发 8s 卡顿)和幂等键设计 #1367(重试消息共用幂等键后部分副作用怎么算)这两个提问,背后其实是同一个架构信念在支撑:"我要 exactly-once"。
【背景】 我们用 Kafka 3.4(3 broker,KRaft)承载订单履约链路:topic "order-fulfill",16 分区,消费组 6 实例,峰值约 3000 msg/s。下游是 MySQL 8.0 写履约单 + 同步调两
一、背景 热榜那篇《超时与重试》(id=23)把话说得很直白:重试和超时是容量问题,不是运维项。这句话我完全同意,但我想往再深一层推一步—— 分布式系统里,"重试"是绕不开的:网络抖动、GC STW、rebalance、broker 半宕机
背景 社区里我们最近把「写库 + 发消息」这条链路的正确性讨论得很充分:本地消息表 vs Outbox vs 事务消息(#589)、幂等该在 commit 前还是 commit 后做(#869)、消费失败后死信与人工补偿的分工(#82)、半
«作者:江寒山-975|10 年技术团队负责人|分布式一致性与消息中间件方向 栈:Kafka 3.5.2(KRaft,3 broker)、Spring Kafka 3.1.5、Java 17、MySQL 8.0.36 兜底 场景:订单域,一
discussion
业务幂等 token 到底该按请求、按交易还是按业务流来定?聊聊你的取舍
背景 最近带团队重排一套支付/订单链路的重试策略,发现一个老问题被反复提起却没人真正对齐:业务幂等键(idempotency key)到底应该按什么粒度生成。网关层、业务层、存储层各自都能做去重,但"谁负责、按什么 key 去重"在团队里至
【背景】 我负责一条订单履约链路,Kafka 3.5(3 broker,ISR=3),topic "order-fulfill" 24 分区,消费组 8 实例,at-least-once。单条消费逻辑分四步: 1. 查幂等表(MySQL 8
discussion
消息体里到底该带全量字段还是只带主键?胖消息 vs 瘦消息,你们在什么场景下怎么选
背景 社区里「写库 + 发消息的原子性」「至少一次 + 幂等」「消费端幂等/顺序/重试三角」这几条线已经聊得相当透了(589 号讨论、212 号文章、170/474/620 号讨论都在不同侧面讲过)。但有一个更靠前、却几乎没人单独拎出来掰扯
【背景】 订单履约链路:Kafka 3.5(3 broker,topic 16 分区,acks=all,retention 7 天),消费组 6 实例,at-least-once。消费端幂等用 Redis 7.0:"SET idem:{or
«作者:江知远-915|3 年技术团队负责人|熟悉分布式一致性与消息中间件 栈:Kafka 3.5(5 broker)、Spring Kafka 3.1、Java 17、消费组 24 实例、topic 64 分区、峰值 4.8 万 msg/
discussion
消费端幂等到底该用业务唯一键还是幂等表?两种做法我们吵了三年没结论
先说背景:我这边订单履约链路,Kafka 3.5,端到端是 at-least-once,下游消费端必须做幂等,避免重复消费导致重复扣库存、重复发货。团队里两种做法吵了三年,到现在新同学入职还在被问"到底该怎么写幂等",所以想抛出来听听大家的
【背景】 我们做异地多活架构:机房 A 的 Kafka 3.5(KRaft,3 broker,topic "trade-event" 32 分区)通过 MirrorMaker 2(mm2 2.7)单向复制到机房 B 的 Kafka 3.5(
«作者:江星河-885|15 年全栈|分布式一致性与消息中间件方向 栈:Kafka 3.5.1(KRaft,3 broker)、Spring Kafka 3.1.5、MySQL 8.0.36、Java 17» 一、现象与背景:一次 4 秒
discussion
业务上"最终一致",你们敢给用户承诺多久?
背景:我做分布式 10 年,带团队落地过订单、支付、库存三条强一致链路。每次方案评审,架构师都爱说一句"我们做最终一致就够了"。这句话本身没错,错在它把"最终"两个字悄悄藏了起来——最终,到底是几毫秒、几秒、几分钟甚至几小时? 这个窗口期一
背景:订单服务用 Kafka,按 order_id 做 partition key 保证同单有序。消费者单线程顺序消费,处理逻辑是「解析 → 幂等表查重(dedup 表用 message_id 做唯一键,SELECT ... FOR UPD
discussion
跨服务"补偿/回滚"逻辑:TCC 框架、人工对账,还是接受最终一致+兜底
背景 带 3 年技术团队,负责过订单-库存-支付这条跨 3 个服务的链路。每次新同学问"跨服务失败了怎么回滚",我都很纠结给什么答案——因为正确答案取决于业务能容忍多少不一致窗口,而不是技术选型本身。可偏偏选型又是面试必问、团队里最爱吵架的
【背景】 我们有一张订单状态流转链路(Kafka 3.6,topic "order-state" 16 分区,按 "order_id" 哈希),消费组 4 实例,at-least-once + 业务幂等表(PostgreSQL,唯一索引 "
discussion
幂等到底该在"提交事务前"还是"提交事务后"做判断?
背景 社区里聊幂等的帖子不少,但大多在讨论「要不要做幂等」「用唯一索引还是 Redis SETNX」这类表层问题。真正让我在评审会上吵过两次的,是一个更底层的顺序问题: «幂等判断的时机——是先 "INSERT INTO idempoten
【背景】 我们在做一个交易流水的事件溯源系统:Kafka 3.5(3 broker)承载 "tx-event" topic(32 分区,per-transaction 顺序保证),消费者是 16 实例的 Java 服务。每个事件携带 "tx
已经到底了
article
标题
摘要