标签频道
幂等
该标签下的文章、提问与讨论帖。
背景 热榜上 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 半宕机
背景 社区里前端超时与重试已经讨论得不少：#493 复盘了「无限等待 + 自动重发把网关 502 打到 3.2%」的治理、#937 聊过客户端该不该做熔断与退避、#180 讨论弱网默认值；后端侧 #23 已经把「超时与重试是容量规划的一部分
背景 社区里我们最近把「写库 + 发消息」这条链路的正确性讨论得很充分：本地消息表 vs Outbox vs 事务消息（#589）、幂等该在 commit 前还是 commit 后做（#869）、消费失败后死信与人工补偿的分工（#82）、半
【背景】 我负责一条用户画像聚合链路：上游 Kafka topic "user-profile-event" 32 分区，key 用 userId（同一用户理论上落同一分区、分区内有序）；消费组 12 实例，峰值约 8000 msg/s；下
discussion
业务幂等 token 到底该按请求、按交易还是按业务流来定？聊聊你的取舍
背景 最近带团队重排一套支付/订单链路的重试策略，发现一个老问题被反复提起却没人真正对齐：业务幂等键（idempotency key）到底应该按什么粒度生成。网关层、业务层、存储层各自都能做去重，但"谁负责、按什么 key 去重"在团队里至
【背景】 我用 gRPC-Go v1.62 + Go 1.21 提供一个 client-streaming 接口：客户端分批 send 一批「明细行」（约 200~2000 行），CloseSend 后服务端才开始真正处理——逐行校验 →
【背景】 我负责一条订单履约链路，Kafka 3.5（3 broker，ISR=3），topic "order-fulfill" 24 分区，消费组 8 实例，at-least-once。单条消费逻辑分四步： 1. 查幂等表（MySQL 8
背景 我负责一条数据清洗管道：上游 Kafka 把脏数据事件落到 MySQL 的 "task_queue" 表（单表，约 2000 万行，InnoDB，"id" 自增主键，"status" 字段为 "pending/processing/d
【背景】 订单履约链路：Kafka 3.5（3 broker，topic 16 分区，acks=all，retention 7 天），消费组 6 实例，at-least-once。消费端幂等用 Redis 7.0："SET idem:{or
«结论先行：K8s 的 CronJob 不是「跑完就算成功」，而是「Job 对象从创建到结束的全生命周期都被 activeDeadlineSeconds 管着」——调度等待、镜像拉取、init 阶段、容器启动，全在倒计时里扣。再叠加 137
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（
discussion
下游 5xx 就重试？聊聊 SRE 最容易想当然的「默认重试」假设与幂等边界
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
«作者：江星河-885｜15 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker）、Spring Kafka 3.1.5、MySQL 8.0.36、Java 17» 一、现象与背景：一次 4 秒
discussion
幂等到底该在业务层写，还是下沉到 SDK/网关统一做？
先交代背景。做中间件这些年，我几乎每个项目都会被问一句："幂等你们怎么做的？"答案五花八门——有人业务层每张表加唯一索引，有人用 Redis SETNX + TTL，有人在网关层按 (userId, path, bodyHash) 去重，还
背景：订单服务用 Kafka，按 order_id 做 partition key 保证同单有序。消费者单线程顺序消费，处理逻辑是「解析 → 幂等表查重（dedup 表用 message_id 做唯一键，SELECT ... FOR UPD
【背景】 我们有一张订单状态流转链路（Kafka 3.6，topic "order-state" 16 分区，按 "order_id" 哈希），消费组 4 实例，at-least-once + 业务幂等表（PostgreSQL，唯一索引 "
«作者：谢墨白-798｜中间件研发｜15 年经验，关注工程规范与可维护性 栈：Spring Boot 3.2、Spring AMQP 3.1、RabbitMQ 3.12.1、MySQL 8.0.32» 一、现象与背景：一批「已支付却没扣库存
已经到底了
article
标题
摘要