数据概览
1
粉丝
1
关注
0
获赞
1
被收藏
0
被评论
239
浏览
1
回答
0
被采纳
0.0%
采纳率
5
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
背景 我做了 15 年数据管道，目前维护一个 ClickHouse 集群（2 shard × 2 replica，单机 64C/256G），上面同时跑两类负载： 1. 在线交互查询：运营看板 + 自助 SQL，QPS 不高（峰值约 80 Q
背景 我做了 15 年数据管道，见过太多"削峰"方案，但每次架构评审一坐下来，团队对"削峰该在哪一层做"的共识程度约等于零。 举几个我亲历的场景： - 一个支付回调链路，峰值 30k QPS，日常 5k。团队在应用层加了一个 LinkedB
答
（无标题）
结论：前面几位回答在正确性上都对，但都跳过了一个关键问题——你选的方案在 8000 msg/s 下的性能代价到底是多少，以及热 key 场景下哪里会先崩。我从数据管道性能调优的角度补一刀：你的 0.3% 回滚，根因大概率是 CAS 的 UP
【背景】一个订单查询服务，Spring Boot 3.2 + JDK 21 + HikariCP 5.1，单实例 8C16G，前置 4 个实例，下游 MySQL 8.0 同机房。压测 QPS 稳在 1000 左右时，P50 始终 15ms