面试复盘：腾讯瑞驰 (西安) - Golang开发
写在前面 这是我在腾讯瑞驰（西安）Golang 开发岗位的完整面试复盘。整体面试流程推进比较快，面试官的技术素养很高，问的问题既有扎实的底层基础（八股），也会结合项目场景进行深挖。在部分高并发场景的解决方案上，也给我指出了现有架构的薄弱点，收获颇丰。 🕒 一面（技术初面）| 2026年1月7日 一面主要考察了 Golang 基础、数据库、以及项目中的实际痛点解决思路，最后带了一道动态规划的手撕算法。 项目与架构深挖 自我介绍（教育背景、技术经历、工作经历）。 为什么项目中的技术栈不统一（同时存在 Java 和 Go）？ 回答：解释了由于历史遗留和早期团队同事的技术栈限制，早期版本使用的是 Java；后来因为边缘服务器配置有限（内存/CPU资源吃紧），团队逐渐将重计算、高并发模块转向更轻量的 Go 语言重构。 协程与线程的区别？项目中如何控制并发度？ 回答：解释了协程（Goroutine）在用户态调度、极小内存占用的轻量化优势。但坦诚自己在项目中未使用协程池，暴露出方案在规模化时的潜在瓶颈。当时提出可以用带缓冲的 channel 来控制并发度。 面试官反馈：无限制创建协程会导致 CPU 过载甚至引发 OOM，一针见血地指出当前方案在极端情况下存在稳定性风险。 项目的 QPS 大概是多少？ 回答：预估在 500 左右。 复盘：被质疑这可能不算严格意义上的“高并发”。当我透露部署环境仅为 2核2G 的单点时，暴露了基础设施的薄弱环节。面试官直接点出了单点故障（SPOF）的隐患。 中间件与基础组件 MySQL 数据库的数据量巨大时如何处理？ 回答：冷热数据分离，时间序列数据只存近一个月的到 MySQL 中，更早的历史数据持久化归档到更廉价的磁盘或大数据组件中。 Redis 缓存一致性如何保证？ 回答：采用 Cache Aside 模式（先写数据库再删缓存），能最大程度保证最终一致性，但在极端并发下仍可能存在短暂的数据不一致或查询延迟。 如何保证数据库（MySQL）和消息队列（MQ）中数据的一致性？ 回答：通过监听、解析并投递 Binlog 日志（类似 Canal 的机制），实现异步的数据最终一致性。 语言基础与八股 数据结构：栈和队列的区别？二叉树的遍历方式有哪些？ 数据库优化：MySQL 慢查询如何排查？建索引的优化策略？ 回答：开启慢查询日志 -> 使用 EXPLAIN 分析执行计划 -> 关注 type、key 等字段看是否走了全表扫描。 追问：索引的底层数据结构？答：B+ 树。 Go 语言基础：切片 (Slice) 的底层实现？ 结合底层的 array 指针、len、cap 以及扩容机制进行了详细说明。 微服务设计：API 接口的设计规范应该包含哪些？ 复盘：这块答得不是很好，只说了 HTTP 中间件思想（Prev/After 钩子）。实际上考察的是 RESTful 语义规范、统一的响应结构体封装判断、版本控制（v1/v2）、限流、鉴权（JWT/OAuth） 等综合素养。 算法与反问 手撕代码：打家劫舍（LeetCode 198） 经典动态规划题。先与面试官同步状态转移方程思路，确认没问题后迅速编码通过。 反问环节：主要了解了当前部门的业务方向与技术栈建设情况。 🕒 二面（技术深挖）| 2026年1月12日 二面相比一面，抛弃了单纯的八股背诵，更多地是从我的过往项目出发，拷问架构设计的取舍与各类异常场景的应对方案。 ...