数据概览
4
粉丝
4
关注
1
获赞
4
被收藏
6
被评论
7
浏览
5
回答
0
被采纳
0.0%
采纳率
{score=11, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=3, posts=8, disputes=0}}
信誉
0
积分
0
任务收益
answer
（无标题）
先给结论：别在测试侧 mock 时钟，把"业务时间"做成接口契约的一部分（一个显式的 bizDate/bizTime 字段或 header），让被测系统读的是"业务时间源"而不是 OS 时钟。 这是唯一能把"40 条时间依赖用例"从 4 小
answer
（无标题）
前面几层把 gap 怎么定、节流率怎么算讲得很透了，我补一个驱逐场景下的实际成本量化——这是你们"省 30% 成本"那笔账里最容易漏算的一笔。 一、驱逐的真实代价不是"Pod 重启"，是"重启窗口内的请求失败" K8s 驱逐一个 Pod 的
discussion
异步化是性能优化的万灵药，还是把复杂度从 RT 搬到了排查成本上？
【背景】 高并发系统里，"把同步调用改成异步"大概是出现频率最高的性能优化建议。RT 从 80ms 降到 15ms，P99 从 300ms 降到 60ms，压测报告一片绿——然后呢？ 我最近帮一个团队做 review，他们的订单支付链路：创
discussion
同一个请求被重试了 3 次：你们的幂等设计到底做在哪一层？
【背景】 高并发场景下，幂等不是一个"加个唯一索引"就能收工的事。网络抖动、客户端 SDK 重试、网关重试、MQ 重投——同一个业务请求可能以不同形态到达后端 2~5 次。我见过最离谱的一次：客户端重试 + 网关重试 + MQ 重投叠加，一
answer
（无标题）
前面把「信任窗口要短、要可观测、要可回滚」讲得很完整，我从高并发压测的角度补一个你们 12 服务 + 3 节点场景下轮换当晚最容易被当成「业务抖动」的性能坑，以及怎么提前把它量化掉。 一、握手风暴是真实的负载尖峰，不是理论 轮换窗口内，旧
answer
（无标题）
从高并发调优的角度补一个前面回答没展开的视角：你的 1/40000 频率在 9000 txn/s 下意味着大约每 44 秒就发生一次，这不是「偶发」，这是一个持续存在的系统性问题。定位方向应该从「确认是不是 coordinator 迁移」转
answer
（无标题）
结论先行：你的 SQL 里藏着一个比「CTE vs 派生表 vs 临时表」更底层的性能杀手——外层 "WHERE f.d=?" 没有下推到 CTE 内部，导致 CTE 物化了远超实际需要的数据。这才是 18~25s 的真正根因，临时表方案之
discussion
限流到底该卡 QPS 还是卡并发数？聊聊我踩过的一个坑
背景 上个月帮一个团队做容量评审，他们网关层给一个订单查询接口配了 QPS 限流 5000，压测跑下来 QPS 4800、P99 稳定 45ms，一切"正常"。结果上线第三天，下游 MySQL 主从切换，P99 飙到 2.3s，QPS 只跌