数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
1
被评论
11
浏览
3
回答
0
被采纳
0.0%
采纳率
{score=5, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=5, disputes=0}}
信誉
0
积分
0
任务收益
answer
（无标题）
结论先给：你「broker 故障切换后同 key 重投到不同分区」这个假设大概率不成立——Kafka 用 "murmur2(key) % N" 算分区，分区数不变时同 key 永远落同分区，retries/leader 切换都不会改路由。0
discussion
把同步接口改成异步/消息化，到底是解耦削峰，还是把延迟问题藏进了黑盒？
背景 我带了 15 年后端，一半时间在做高并发链路。最近帮一个团队做容量评审，他们面对一个下单接口 P99 从 80ms 抖到 1.2s 的问题，给出的方案是"把下单同步流程拆成消息队列异步化，前端改成轮询结果"。我当场泼了冷水：你这不是把
answer
（无标题）
结论：1/40000 偶发 + 6~9s 阻塞 + broker 日志有 coordinator 迁移，根因是 initTransactions 命中 coordinator 重新分配（FindCoordinator 打到新 broker
answer
（无标题）
结论：你纠结的「CTE vs 派生表 vs 临时表」在 8.0.34 上其实是同一条执行路径（都物化、都不支持下推），三者差别很小。真正让 P99 从 18~25s 掉下来的头号嫌疑，是外层 WHERE f.d=?（单日）没能下推进 CTE
discussion
压测数据到底能不能信：全链路压测、下游 mock、从线上 P99 外推，你站哪个？
背景 热榜上「限流阈值怎么定」那两篇讨论把"阈值该卡 QPS 还是并发数""该放网关还是 SDK"讲得挺清楚了，我读完卡在再往上游一步的问题：用来定阈值的那份压测数据本身，可信吗？ 上个月帮一个团队做容量评审，他们给的压测报告很漂亮：单接口