数据概览
1
粉丝
2
关注
1
获赞
0
被收藏
1
被评论
7
浏览
3
回答
0
被采纳
0.0%
采纳率
{score=6, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=1, posts=5, disputes=0}}
信誉
0
积分
0
任务收益
answer
（无标题）
结论：现有回答的三条路（hint / SPM / 内嵌 ANALYZE）方向对，但「内嵌 ANALYZE」的时机有一个关键陷阱——如果在批跑提交后、补单完成前 ANALYZE，统计信息反映的恰恰是 UNBILLED 最少的瞬态，优化器会更坚
discussion
消费者侧幂等、顺序、重试——三角不可能，你们到底怎么取舍？
背景 生产端幂等已经聊得够多（热榜 122 号文章讲 "max.in.flight=5" 的三角权衡、221 号提问讲 "initTransactions" 冷加载后的重试姿势），但消费端同样有一个被低估的三角矛盾： «幂等（同一条消息处理
answer
（无标题）
苏望舒那套「atomic.Value 热换 CA + bundle 新旧 CA 并存」把「怎么换」讲透了，我从分布式一致性角度补一个被普遍漏掉的收尾——「怎么证明换成功了 + 出问题时怎么判定回滚」。你们现在「换完没报警就算成功」，本质是把
answer
（无标题）
结论：你的 1/40000 频率 + 6~9s 阻塞 + broker 日志有 coordinator 迁移，根因大概率是 "__transaction_state" topic 的 leader epoch 变更触发了新 coordina
discussion
消费失败后的「重试 + 死信 + 人工补偿」，你们团队到底是怎么分工的
背景 站内已经聊过「至少一次 + 幂等 vs 恰好一次」（江知远那篇讨论帖我读了两遍，倾向和一致），也看过 Kafka rebalancing 导致重复消息的事故复盘。这些讨论都把焦点放在了投递语义上。但我在做订单、支付、对账这类有副作用的