这是 Coachly 的演示报告（虚构用户）
下面看到的所有内容——项目卡片、五维雷达图、追问链、面后评分——都是 Coachly 真实生成的格式，只是用了虚构用户张三的电商秒杀项目作为样本。 用你自己的简历跑一次，会得到针对你具体经历的同等深度分析。
项目级深度分析
上传简历后，Coachly 把每个项目单独抠出来深读，分别给到 STAR 拆解 + 五维短板诊断 + 8 个针对性追问。 这是张三电商秒杀系统项目的分析结果。
原始描述（来自简历原文）
负责双十一秒杀活动的后端架构。核心问题：商品库存只有 5000，但首秒涌入 30 万用户，老系统直接 504。 我做了几件事：把商品详情页和库存查询全部塞进 Redis，订单走 MQ 异步落库，前端加排队页面，并做了风控拦黑产。 最终把首秒成功下单率从 22% 提到 96%，核心接口 P99 控制在 180ms 以内，活动期间零事故。
STAR 拆解
公司双十一秒杀活动，5000 件爆品，预估首秒并发 30 万 QPS。前一年用同一套架构挂了 8 分钟，CTO 指名要保住今年。
我作为活动后端 owner，负责整条链路（商品详情 + 库存扣减 + 下单 + 支付前置校验）的高并发架构改造，目标：首秒成功下单率 ≥ 95%、P99 ≤ 200ms、不影响主站。
1) 库存与商品信息全量预热到 Redis，每秒 sync DB；2) 下单链路改造：Redis Lua 原子扣减 + Kafka 异步落库；3) 前端排队页 + 30s 准入令牌，平滑请求；4) 风控接入：设备指纹 + 行为评分，拦截黑产 70%+ 流量；5) 全链路压测 5 轮，提前发现连接池泄漏。
首秒成功下单率从去年的 22% 提到 96%，核心接口 P99 = 178ms（目标 200ms），全程零事故。被列为公司年度 Top 5 项目，并沉淀成秒杀架构规范在 3 个事业部复用。
五维评分AI 判定为：技术岗画像雷达 + 热力图都是「越长 / 越外 = 越强」
追问链 · 8 题点开查看参考答题骨架
d4Redis 库存扣减用 Lua 是为了什么？换成 DECR 加事务方案有什么本质区别？›
参考答题骨架Lua 在 Redis 单线程模型里保证扣减+判断+回滚整段原子化。DECR 单独跑会出现“扣完发现超卖、再 INCR 回滚”的窗口，期间用户可能已经看到下单成功。我们 Lua 脚本里先 DECR、若结果 < 0 立刻 INCR 回滚并返回失败码——整个动作 1 个 RTT、原子。事务方案（MULTI/EXEC）是 watch+乐观锁，在 30 万 QPS 下 watch key 大量 abort，反而打满 CPU。
d4Kafka 异步落库失败怎么办？比如订单消息丢了，用户钱扣了但订单没生成。›
参考答题骨架三层兜底：① Kafka producer 配 acks=all + 幂等 producer + 本地消息表（先落 outbox 再发，定时扫描重发未确认的）；② 消费者侧手动提交 offset，业务落库成功才 ack；③ 对账 job 每 5 分钟扫一次“已扣减库存但 30 分钟无对应订单”的异常，自动补单或退款。实际活动里跑出 12 条异常，全部由对账 job 兜住。
d4你提到全链路压测 5 轮发现连接池泄漏，具体怎么发现的？修复方案是什么？›
参考答题骨架第 3 轮压测跑 15 分钟后，DB 连接数缓慢爬升到上限 200 没释放，新请求开始 timeout。火焰图定位到一个第三方支付前置校验 SDK——它内部维护一个 connection pool 但漏了 close。我们 fork 后加了 try-with-resources，并在 wrapper 层加 connection leak detector（HikariCP 的 leakDetectionThreshold=30s），后续压测稳定。
d5排队页 + 准入令牌的设计，本质上是在做流量整形。为什么不直接用 Nginx 限流？›
参考答题骨架Nginx 限流是请求级硬切断，用户体验差（直接 503），且无法做用户级公平。我们排队页是业务级整形：① 用户进入立刻拿到排队号，前端 WS 推进度，体验上感觉“在排队”而不是“被拒”；② 准入按 token bucket 平滑下发，每秒固定 N 个进核心链路；③ 黑产识别后直接踢出队列不占名额。Nginx 适合机房防雪崩，排队页适合用户体验+公平性，两层是叠加关系不是替换。
d5如果今年再做一遍，你会改哪里？›
参考答题骨架三个点：① Redis 主从切换演练我们没做，活动当天如果主挂了切换有 5-10s 不可用窗口，下一年要做 sentinel + 客户端旁路；② 排队页准入算法是固定速率，应该改成基于实时 P99 自适应——业务低峰时让更多人进，避免排队冗长；③ 对账 job 是 T+5min，应该缩到 T+30s，减少异常订单的客诉爆发期。
d3你说“首秒成功下单率从 22% 提到 96%”，22% 是怎么算出来的？分母是什么？›
参考答题骨架分子 = 首秒成功创建订单的用户数；分母 = 首秒发起下单请求的去重 UV（按 deviceId）。22% 是去年活动后产研 + 数据团队联合复盘出的口径，今年沿用同一套埋点和算法，所以两个数字可比。如果分母换成“点击秒杀按钮的总人数”就会拉低，但失去了归因能力。
d5风控拦黑产 70%+ 这个数据怎么验证准确性？误杀率多少？›
参考答题骨架我们设了 0.5% 的小流量影子模式：风控判定为黑产的请求里，1/200 仍然放行并打标。事后人工抽样 + 行为回溯，发现真黑产识别准确率 94.3%、误杀率 0.7%。误杀的主要是同 WiFi 多设备的家庭用户，后续把“同 IP 多设备”权重从 0.4 调到 0.2 后误杀降到 0.3%。
d3团队有几个人，你具体负责哪一块、哪些是别人做的？›
参考答题骨架活动小组共 6 人：我（后端 owner，架构 + 库存/下单链路）、1 个前端（排队页 + WS）、1 个风控（规则引擎 + 黑产识别模型）、1 个 DBA（DB 拆分 + 慢查询）、1 个测试（压测脚本 + 演练）、1 个 SRE（监控 + 应急预案）。架构方案我主导拍板，每个子模块的负责人自己实现，我做联调和压测协调。
实时模拟面试 · 单题打分
进入面试模式后，AI 按 JD 召回最相关项目逐题深问。每条回答即时评分 + 找出做得好的点 + 给可执行改进建议。
你说 Redis Lua 脚本保证了原子性，那 Lua 脚本里如果 panic 了怎么办？整个 Redis 实例会不会卡住？
Lua 脚本是单线程执行的，如果 panic 应该会抛错回到 Redis 线程，但具体怎么处理我没特别测过。实际项目里我们脚本写得很短，就十几行，没出过 panic。
- +诚实承认没深入测过，没硬编
- +提到了脚本简短作为风险控制手段
- →可以多答一层：Redis 默认 lua-time-limit=5s，超时 Redis 会标记 BUSY 但不会自动 kill，需要 SCRIPT KILL 或 SHUTDOWN NOSAVE
- →面试官在考你“如何防 Lua 阻塞 Redis 主线程”，可以主动延展到“我们生产里会限制脚本最大行数 + EVALSHA 缓存预编译 + 监控 slow log”
- →可以反问面试官在意的是性能场景还是稳定性场景，展示思考路径
面后综合报告
面试结束后，Coachly 会基于全部对话生成结构化报告：综合评分 + 项目掌握度雷达 + 逐题点评 + 下一步建议复练。
整体表现稳健，核心项目（电商秒杀）的 STAR 拆解清晰、技术深度有抓手、数据敏感度强。短板在两处：① 部分追问下你切换到“我没特别测过”模式，缺少基于已知原理的合理推测；② 协作维度叙述偏个人贡献，缺少团队配合的具体场景。建议下一轮聚焦“压力测试下被追问到边界知识时的应对策略”。
电商秒杀系统
平均 4.0对项目目标、自己的角色、关键数字（QPS、P99、成功率）的把握都很到位。技术深度在主链路（Redis Lua / Kafka）很扎实，但被追问到 Redis 内部机制（Lua panic / 主从切换）时退守到“没测过”，可以更主动用第一性原理推。
- 1电商秒杀系统
针对 Redis Lua 脚本边界（panic / 阻塞 / 主从切换）做一次深度 review，把“没测过”的回答升级成“基于原理推测+生产应急预案”的结构化回答。
- 2电商秒杀系统
在"协作"维度补充 1-2 个具体团队配合场景（压测复盘会上和 DBA 的争执、应急预案演练里的角色分工），让"6 人小组"从抽象描述变成可信故事。
看完了？这只是一个虚构样本。
上传你自己的简历，Coachly 会针对你真实的项目经历生成同等深度的分析 + 模拟面试 + 报告。 首次免费 · 邮箱注册 30 秒 · 数据全国内合规。