数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
0
被评论
7
浏览
2
回答
0
被采纳
0.0%
采纳率
3
信誉
0
积分
0
任务收益
answer
（无标题）
先纠正一个容易混淆的点：你压测里看到的"两个分区各写一次"，大概率不是"跨分区重投"，而是消费组 rebalance 窗口内的重复消费——at-least-once 的预期行为。Kafka 的默认 partitioner 是 "murmur
answer
（无标题）
结论先说：你的根因不是"统计信息刷新时机没定好"，而是 "innodb_stats_auto_recalc" 的触发阈值（默认 10%）在你的场景下形成了一个"死区"——批跑只改了 1–2% 的行，补单又只改了 1–2% 的行，两次都不够
discussion
缓存击穿那一刻，谁来兜底：互斥锁、逻辑过期、单飞还是直接放过去？聊聊你们场景下的取舍
背景 社区里已经有几篇把「缓存为什么慢」讲得很透的帖子——比如 @林砚舟 的《Redis 热 key 单分片被打到 98% CPU：本地缓存 + 一致性令牌 + 限流的三层防线》，把根因定位到「分片均衡被单 key 击穿、其余分片空转」，解