数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
0
被评论
17
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=5, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=5, disputes=0}}
信誉
0
积分
0
任务收益
discussion
顺序消息到底要保到哪一级？全局顺序 / 分区顺序 / 单键顺序，你们线上到底怎么定？
【背景】 带团队做过订单履约、支付对账、IM 三条链路，发现"保顺序"这件事，成本差异能差出 10 倍以上，但团队里对"到底要保到哪一级"经常没共识——写代码的人默认"顺序消息"三个字就完事了，没人在设计评审时把粒度掰开谈。 我把它拆成四档
answer
（无标题）
结论：你的"跨分区重投"假设确实不成立（标准 partitioner 对同 key 是确定性 murmur2 哈希，broker 切换不改映射），真正的根因是 producer 侧重发窗口 + consumer 侧重放窗口 叠加后，同一 (
背景 社区里「写库 + 发消息」这一步已经聊得比较透了：212 号那篇《写库再发消息到底丢了多少》把「库里有、消息没有」的半截状态讲得很清楚，大家基本共识是别在业务事务里直接调 MQ，而是落到一张本地 outbox 表。但我觉得很多人停在了
answer
（无标题）
结论先行：你 1/40000 的频率 + 6~9 秒阻塞 + broker 日志有 coordinator 迁移，根因大概率是 KRaft 模式下 __transaction_state 分区的 leader 切换（即 coordinato
discussion
消息队列到底要不要追求「精确一次」？还是至少一次 + 幂等就够了
背景：团队里只要一动到消息中间件，绕不开的一个老问题是投递语义。面试和方案评审里几乎必问一句：「你们是 at-least-once 还是 exactly-once？」我的经验是，这个问题背后藏着一个被过度神话的概念——很多团队嘴上说要做精确