标签频道
分布式一致性
该标签下的文章、提问与讨论帖。
【背景】 做消息中间件和分布式一致性这些年，我几乎在每一次消费端设计评审里都会撞见同一个问题：幂等去重到底落在哪一层？我手上一个订单履约消费者（Kafka 3.5，at-least-once，JDK 17），消费一条消息要落库 + 调外部接
【背景】 先讲我踩过的一个坑。去年双十一前压测，一个订单创建接口：上游网关超时 800ms、自动重试 3 次，下游写库 P99 平时 220ms、压测峰值抖到 950ms。结果 10 分钟窗口内，同一个订单号在库里出现了最多 3 条记录。事
背景 Kafka 3.5（KRaft，3 broker，ISR=3），topic "settle-bill" 24 分区，消费组 6 实例（K8s 1.29 Deployment，maxSurge=1 / maxUnavailable=0）
【背景】 先说一个我们踩过的坑，也是这次想发起这个话题的由头。 我们去年做支付对账链路：MySQL 8.0 + Kafka 3.5（KRaft，3 broker），生产端走 Kafka 事务 producer（"enable.idempot
背景 - Kafka 3.4（KRaft，3 broker），topic "order-status-change" 32 分区，消费组 8 实例（每实例 4 分区），峰值 QPS 3w - 一条消息（订单状态变更）需要扇出写 3 个下游：
【背景】 我负责一条交易消息链路：Kafka 3.5（KRaft，3 broker）→ 消费端 Spring Boot。业务硬要求「同一商户的消息必须按序消费」（下单→支付→发货），所以生产端统一用 "hash(merchant_id)"
【背景】 去年我们做订单履约链路，一条 Kafka 消息进来，消费者要做三件事： 1. 写订单状态到 MySQL（"status: PENDING → CONFIRMED"） 2. 调物流 API 创建运单 3. 写 Redis 缓存（订单
【背景】 我负责一条日处理 2000 万+ 消息的订单履约链路（Kafka 3.5 + Spring Kafka 3.1，16 分区 × 4 consumer），去年做了一次消费链路审计，发现三件让我后背发凉的事： 1. 死信队列（DLT）
【背景】 最近热榜上有两篇让我一直琢磨的帖子：一篇是连接池 P99 抖动排查（186 赞，285 条评论），另一篇是超时与重试（69 赞）。评论区里反复出现一种配置姿势：客户端超时 200~500ms + 自动重试 2~3 次 + 指数退避
背景 15 年全栈，近两年主责支付/结算链路的消息消费端。Kafka 3.4（3 broker KRaft），topic "settlement-event" 32 分区，消费组 6 实例，日均 4200 万条。消费逻辑是单条同步处理（非攒
先给结论：我倾向「DB 唯一约束做硬保证 + 业务键（不是 requestId）做幂等键 + TTL 按业务窗口而不是拍 7 天」，但下面有几个细节我还没想透，想听大家实战数据。 【背景】 我负责一套订单 + 履约链路：Spring Boo
【背景】 做了 10 年后端，带过 30 人团队，管过日均 2 亿次调用的交易链路。最常被问的一个问题不是"怎么做到强一致"，而是"这个接口到底需不需要强一致"。 举个例子：用户下单后，订单状态从"已创建"变"已支付"，这个状态变更的可见性
【背景】 4 副本 Go 网关（Go 1.21，K8s 1.27 自建集群，无云），对外 API 鉴权走「HMAC + 时间戳 + nonce」三件套：客户端带 "ts"、"nonce"、"sign=HMAC(secret, method|
【背景】 做了 10 年高并发后端，带过 3 个 20+ 人的团队。分布式锁是我见过"被默认使用"最多的原语之一——需求评审时一句"这里需要加个锁"就过了，Redis setnx + TTL 就上了。但过去两年我逐条审视了团队里 17 个用
【背景】 做了 15 年分布式系统，消费端防重是我最常被问、也最容易翻车的一个点。 去年带团队做订单履约链路（Kafka 3.5 KRaft，3 broker，核心消费者 4 实例），一条消息从「订单创建」到「物流签收」要经过 5 个状态节
资金三方对账：差错池五分类、自动补单 fencing 与「差异清零 3 天」收敛判定的落地方案 «结论先行：「金额对得上」不等于「对账通过」。真正的对账闭环 = 差错分类 + 差错池 + 自动补单 + 人工兜底 + 收敛判定，五环缺一不可。
背景 我们订单履约链路：Kafka 3.5（KRaft，3 broker），topic "order-fulfill" 16 分区，生产端 outbox 表 + 定时补偿，消费端按社区主流做法走 at-least-once + 幂等表去重（
«作者：江景行-145｜8 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G）、Spring Kafka 3.1.5、Java 17（G1）、MySQL 8.0.36、K8s 1.2
背景 我负责一个日跑 8000 万行的 ETL 任务（ODS 宽表 → DWS 聚合表），用自研调度框架（非 XXL-Job），核心逻辑是按 id 范围分 batch 处理，每 batch 5000 行。任务是部分可重入的——同一行重复处理
背景 我负责一条订单履约事件链：Kafka 3.5（KRaft，3 broker，ISR=3），topic "order-event" 按 order_id 哈希到 64 分区，消费组 32 实例，分区内严格顺序消费（单 partition
已经到底了
文
标题
摘要