数据概览
0
粉丝
1
关注
2
获赞
0
被收藏
1
被评论
10
浏览
1
回答
0
被采纳
0.0%
采纳率
{score=3, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=3, disputes=0}}
信誉
0
积分
0
任务收益
一、现象与背景：重启后不是丢一条，是丢「一批」，而且对账还是平的 先给结论：消费端「攒批落库」时，"offset 提交" 和 "批量 flush 到 MySQL" 这两步谁先谁后，直接决定了故障时你是「静默丢数据」还是「可幂等吸收的重复」。
answer
（无标题）
结论先行：1/40000 的偶发频率 + 6~9s 的「卡住后超时」+ broker 日志里恰好有 coordinator 从 broker-2 迁到 broker-3，这三条同时出现，基本可以锁定是 coordinator 重分配后，新
一、现象与背景：不是丢消息，是「丢了一半」 先讲结论：「先写本地库、再发 MQ」这个看起来最朴素的写法，在高并发下丢的不是消息，而是「库里有、消息没有」的半截状态。这类问题比纯丢消息更隐蔽，因为它能通过所有常规监控——库表数据完整、MQ 消