快手后端实习二面复盘：高并发、MySQL主从复制、JVM调优与括号生成算法全解析-平芜编程栈

快手后端实习二面复盘：高并发、MySQL主从复制、JVM调优与括号生成算法全解析

面试时长：50分钟
岗位方向：Java 后端开发实习生（快手）
关键词：高并发处理、MySQL 主从复制、JVM 调优、WebSocket 通信、LeetCode 括号生成

在经历了快手后端实习一面之后，我迎来了更具挑战性的二面。这场面试不仅深入挖掘了我的项目细节，还围绕高并发场景下的系统设计、数据库优化、JVM 性能调优以及一道经典算法题展开了连环追问。本文将完整还原本次模拟面试过程，并结合专业视角给出高质量回答，希望能为正在准备后端实习面试的同学提供参考。

一、项目深挖：从功能实现到高并发应对

面试官提问：

“先介绍一下你简历中的这个电商秒杀项目吧。”

我的回答：
“好的。我做的这个项目是一个模拟的高并发秒杀系统，主要包含商品展示、用户登录、库存扣减、订单创建等模块。技术栈用了 Spring Boot + MyBatis + Redis + RabbitMQ + MySQL。核心目标是解决超卖和高并发冲击问题。”

面试官追问：

“项目中有并发比较大的情况，订单量大的时候怎么办的？用户量本身很大怎么办？”

我的回答：
这个问题其实涉及两个层面：瞬时高并发（比如秒杀瞬间）和长期高用户基数。

对于瞬时高并发，我们做了以下优化：
- 前置限流：使用 Nginx + Lua 实现 IP 级别的请求限流，防止恶意刷接口。
- 缓存预热：秒杀开始前，将商品信息、库存数量加载到 Redis 中，避免直接打到数据库。
- 异步削峰：用户提交秒杀请求后，先校验资格（如是否登录、是否重复下单），然后将请求放入 RabbitMQ 队列，由消费者异步处理库存扣减和订单生成。这样即使瞬间有 10w QPS，后端服务也能平稳消费。
- 库存扣减用 Redis 原子操作：DECR+ Lua 脚本保证原子性，避免超卖。
对于用户量大（长期高 DAU）：
- 读写分离：MySQL 主从复制，读请求走从库，减轻主库压力。
- 分库分表：虽然项目中没实际落地，但我在设计时预留了 user_id 取模分表的扩展点。
- CDN + 静态资源缓存：商品图片、前端页面通过 CDN 加速，减少服务端负载。

二、搜推与大模型相关能力考察

面试官提问：

“你有搜推（搜索推荐）经历吗？学过 Transformer 吗？做过大模型开发吗？”

我的回答：
“目前我的项目聚焦在后端工程和高并发系统，没有直接参与搜推系统开发。不过我在课程和自学中了解过推荐系统的基本架构，比如协同过滤、Embedding + 召回 + 排序 pipeline。

关于Transformer，我在学习 NLP 时深入研究过其结构——自注意力机制、位置编码、Encoder-Decoder 架构等，也跑过 HuggingFace 的 BERT 微调 demo。

至于大模型开发，目前主要是通过开源框架（如 Llama.cpp、LangChain）做应用层集成，比如搭建 RAG 问答系统，但没有参与过大模型的训练或底层优化。”

💡点评：快手作为内容平台，对搜推和 AIGC 有强需求。即使没经验，也要展示出学习能力和技术敏感度。

三、MySQL 主从复制 + 秒杀场景优化

面试官提问：

“你在项目中用了 MySQL 主从复制，具体步骤是什么？在抢票/秒杀场景下，服务端如何进一步优化？”

我的回答：
主从复制配置步骤简述：

主库开启 binlog（log-bin=mysql-bin），设置server-id=1；
从库设置唯一server-id=2，配置主库 IP、用户名、密码、binlog 文件和位置；
从库执行START SLAVE，IO 线程拉取 binlog，SQL 线程重放。

但在秒杀场景下，主从复制存在一个关键问题：

主从延迟（Replication Lag）可能导致从库读到旧库存！

所以我们的策略是：

强一致性读走主库：比如查询“当前剩余库存”这种关键数据，必须查主库。
非关键读走从库：如商品详情、历史订单列表。
进一步优化：
- 使用Redis 缓存库存，完全绕过 MySQL 读；
- 库存扣减成功后，通过Binlog + Canal异步同步到 ES 或其他系统，用于后续分析；
- 对于极端场景，可考虑分段库存（如将 1000 件库存拆成 10 个 100 件的分段），分散热点。

四、JVM 调优实战经验

面试官提问：

“你有 JVM 调优的经历吗？”

我的回答：
“在压测秒杀服务时，我们发现 GC 频繁，尤其是 Young GC 每秒多次，导致接口响应时间波动大。

我们通过以下步骤进行调优：

监控工具：使用jstat -gcutil和 Arthas 查看 GC 频率和堆内存使用；
发现问题：Eden 区太小（默认 1/8 堆），对象频繁晋升到 Old Gen；

调整参数：

-Xms4g-Xmx4g# 固定堆大小，避免动态扩容-XX:NewRatio=2# 新生代:老年代 = 1:2-XX:SurvivorRatio=8# Eden:S0:S1 = 8:1:1-XX:+UseG1GC# 改用 G1，控制停顿时间

代码层面：减少临时对象创建（如避免在循环内 new 对象），使用对象池（谨慎）。

调优后，Young GC 从每秒 5 次降到每 10 秒 1 次，P99 延迟下降 60%。”

五、服务端与客户端通信方式对比

面试官提问：

“服务端和用户端怎么通信？有哪几种方式？有没有更轻一点的？”

我的回答：
常见的通信方式有：

方式	特点	适用场景
HTTP/REST	请求-响应，无状态	普通 API 调用
WebSocket	全双工、长连接	实时聊天、推送
SSE (Server-Sent Events)	服务端单向推送，基于 HTTP	实时通知、股票行情
gRPC	基于 HTTP/2，二进制协议，高效	内部微服务通信

“更轻一点”的方案？
如果是移动端或弱网环境，我会考虑：

SSE：比 WebSocket 更轻，只需 HTTP 协议支持，无需维护复杂连接状态；
HTTP/2 多路复用：减少 TCP 连接数，提升效率；
Protobuf 替代 JSON：序列化体积更小，解析更快。

在我们的项目中，订单状态变更用了WebSocket推送，但后续考虑改用SSE + 长轮询降级，以兼容更多客户端。

六、算法题：生成有效括号组合

面试官提问：

“数字 n 代表生成括号的对数，请你设计一个函数，用于生成所有可能的并且有效的括号组合。”

我的思路（回溯法）：
有效括号的核心规则：

任意前缀中，左括号数量 ≥ 右括号数量；
总左括号数 = 总右括号数 = n。

代码实现（Java）：

publicList<String>generateParenthesis(intn){List<String>res=newArrayList<>();backtrack(res,newStringBuilder(),0,0,n);returnres;}privatevoidbacktrack(List<String>res,StringBuildersb,intleft,intright,intn){if(sb.length()==2*n){res.add(sb.toString());return;}// 可以加左括号：只要 left < nif(left<n){sb.append('(');backtrack(res,sb,left+1,right,n);sb.deleteCharAt(sb.length()-1);// 回溯}// 可以加右括号：只有 right < left 时才合法if(right<left){sb.append(')');backtrack(res,sb,left,right+1,n);sb.deleteCharAt(sb.length()-1);}}