企鹅后端日常实习二面

二面全程场景题,完全没法准备,只能靠仅有的知识储备来应对,好在面试官人挺好,没有那种上压力甩脸子,给我充足的时间来思考修正。

以下是相关问题和个人思路

1、项目简单介绍

我简历写了两个项目,传统后端开发无非是外卖+点评,我是把第一个换成了本科比赛毕设的项目,反正技术栈也差不多,而且还有获奖经历作为背书。第二个在点评技术上加了一些ai的内容,让整体更加有新意。

面试官估计也是简历看多了,对于第一个项目(毕竟不是外卖)进行深入挖掘了。

这个比赛的项目结构是怎样?你负责的版块是什么?最大的困难是什么?

刚开始这几个问题我还以为是那种传统的KPI面,问问宽泛的问题,后面逐步深入挖掘了,才意识到问题的严重性

2、负责的后端板块,为什么选用springboot+vue?

这里问我技术栈选用问题,我只能说是当时比较前沿热门可靠的项目,我可以直接拿来复用,降低开发的复杂度,缩小开发周期。

面试官应该是组长级别的,继续问我选用这些组件有什么特性,是开发中需要考量的?

3、对于项目中用到的数据表格的设计,是如何确认的?

我那个项目是有一定现实基础,和相关的业内人员咨询之后进行了确定,保证数据的真实可用。

4、在项目开发完成之后,正式上线之前,有哪些点是要考虑到的?什么是最重要需要关注的?

这感觉就有些软件工程开发流程方面的内容了,Java八股肯定是准备不到的,我回答说一个是进行模块测试保障性能、一个是进行安全校验,现在问问ai,给出如下答复

我们可以从 技术准备 + 风险防控 + 运维监控 + 用户体验 四个维度来讲清楚 👇

🚀 一、上线前的核心检查清单(技术向)

✅ 1. 功能完整性与稳定性

  • 所有主流程已测试通过(注册、登录、支付、交互等);
  • 边界场景与异常路径测试(输入异常、网络超时、接口报错);
  • 确保无阻断性 BUG(影响核心功能的优先级最高)。

✅ 建议:用 checklist 管控上线风险,如“支付是否走预生产环境验证过”、“Redis 缓存是否生效”、“外部接口是否稳定”等。

✅ 2. 配置与环境一致性

  • 测试环境、预发布环境、生产环境的配置保持一致(除了数据库和密钥等);
  • 使用 Spring Profile 或 环境变量 分离配置:
spring:
  profiles:
    active: prod
  • 确保数据库连接、Redis、消息队列、第三方 API 都已配置为生产版本;
  • 检查 .properties、.yml 文件中是否存在硬编码路径、测试账号、日志级别。

⚠️ 常见事故:忘记切换为生产配置,导致数据写入测试库或日志量爆炸。

✅ 3. 性能优化与压力测试

  • 进行 Load Test / Stress Test(压力与并发测试);
  • 确定系统的瓶颈(数据库、IO、缓存、线程池);
  • 评估系统的 QPS(每秒请求数) 和 响应时间;
  • 对大流量接口使用缓存、限流或异步化;
  • 设置数据库连接池、线程池大小合理上限,避免资源耗尽。

✅ 建议:使用工具如 JMeterwrklocust 进行压测。

✅ 4. 安全检查

  • 检查 SQL 注入、XSS、CSRF、文件上传等安全漏洞;
  • 隐藏敏感信息(如日志中不能打印密码或 Token);
  • HTTPS 必须启用;
  • 权限体系核对(防止接口越权访问);
  • 加密存储用户隐私信息。

✅ 建议:上线前做一次安全扫描(如 SonarQube 或 OWASP ZAP)。

✅ 5. 日志与监控

  • 打好关键日志(INFO/ERROR/DEBUG 分级清晰);
  • 统一日志格式(方便 ELK、Loki 等采集分析);
  • 设置系统监控与告警(CPU、内存、磁盘、接口耗时);
  • 接入 APM(应用性能监控)系统,如 SkyWalking、Pinpoint、Prometheus + Grafana。

🚨 日志是排查问题的生命线。上线前一定确认能追踪关键链路。

✅ 6. 数据库与数据迁移

  • 检查表结构变更脚本(确保幂等、安全);
  • 上线前备份生产库;
  • 如果涉及数据迁移或初始化,先跑预演;
  • 评估索引是否需要优化。

⚠️ 常见错误:忘记加索引,结果生产环境查询慢到超时。

✅ 7. 缓存与消息队列检查

  • Redis 缓存过期策略合理;
  • 消息队列(如 RabbitMQ、Kafka)消费逻辑无死循环;
  • 防止消息丢失或重复消费;
  • 缓存预热(避免冷启动时穿透数据库)。

🧩 二、上线策略与风险控制

✅ 1. 灰度发布(Canary Release)

  • 先让部分用户访问新版本(比如 5% 流量);
  • 观察日志与监控数据;
  • 无异常再逐步放开流量。

✅ 2. 蓝绿发布

  • 部署两个生产环境(蓝 / 绿);
  • 新版本上线后,流量切换;
  • 若异常,立即切回旧版本。

✅ 3. 回滚机制

  • 确保有 一键回滚脚本;
  • 数据结构变更时,提前考虑“是否可逆”;
  • 版本控制中必须有上一个可运行版本的镜像。

🌐 三、运维与部署层面

  • 使用 CI/CD(如 Jenkins、GitLab CI)实现自动化部署;
  • Docker 镜像版本固定;
  • 检查容器健康探针(liveness/readiness probe);
  • 日志与监控配置挂载到持久化卷;
  • 设置系统启动参数(JVM 内存、GC 策略)。

👀 四、用户体验与前端层面

  • 前端资源开启 GZIP 压缩与 CDN 加速;
  • 大文件懒加载、分页展示;
  • 404 / 500 页面友好;
  • 错误提示明确;
  • 埋点统计(用户行为 + 性能指标)。

5、对于性能测试,要求达到的目标是怎样的?

我之前可以说完全没考虑到这个问题,因为项目本身也不是高并发场景,但是面试官让我考虑了一下极端的情况,比如100QPS,问我是否可能存在,为什么要达到这个性能指标?

我考虑了一会,觉得这个业务场景是存在的,所以需要达到。我感觉面试官的深意是问我这个性能指标是根据设备性能来,还是根据历史数据来,还是自己推理得到性能指标。

6、对于一个游戏排名系统,有玩家账号、得分、排名,这三个数据,要求能根据账号查找到得分,根据账号能查到排名,根据排名也能查找到玩家账号。

对于这个系统,玩家账号和得分是相对固定的,但是由于玩家的新增,排名可能会有变动

我一开始是想着用hashmap,key为账号,value为{得分,排名},这样能根据账号直接查到所有信息,但是无法根据排名查账号,而且排名可能是动态变动的,如果因为一个新的分数导致全部的账号排名都需要更新,这样性能负担很大。

我想着用两个表,一个hashmap {账号→得分} 另一个treemap{得分→账号},利用treemap的天然排序特性,对于分数进行排名,并且能够省略一个【排名】这个数据,隐藏在treemap的位置里面。但这个思路没法从排名得到账号,而且treemap只能查找某个范围的key,无法得到其下标

📚TreeMap常用方法

put(K key, V value)

插入键值对

get(K key)

根据键取值

remove(K key)

删除键值对

firstKey() / lastKey()

获取最小 / 最大键

ceilingKey(K key)

返回 ≥ key 的最小键

floorKey(K key)

返回 ≤ key 的最大键

higherKey(K key)

返回 > key 的最小键

lowerKey(K key)

返回 < key 的最大键

subMap(fromKey, toKey)

获取指定范围内的键值对

descendingMap()

返回一个键降序的视图

对于hashmap用于根据账号查得分肯定是没问题的,就是账号和排名互查方面是个问题。

面试官提示,如果存储在线性结构中,查找效率必然是o(n)数量级,可以达到o(logn),而且现有的数据结构肯定是不能直接使用的,要想着去改造以实现目标。

那毫无疑问,直接就是二叉树了,可以达到o(logn)的查询效率。我脑子一抽,突然想起来了败者树(胜利者树)要想获取排名每次获取树根部元素就行了,又和面试官叨叨半天,但胜利者树获取排名要求弹出根的节点,这会破坏原有的数据。

面试官又提示了一点,我想到了B树,但没法我想起来平衡二叉树可以,节点中存储{账号,得分,左子树节点数,右子树节点树}以得分为值构建平衡二叉树。左边节点都比自己小,相当于知道前面的位次,也就知道自己的排名了,而且插入删除元素的过程中会对途径的节点左右子树信息同步更新就行,并不会破坏原来树的结构。这样可以根据得分查到全部信息,也可以遍历查询到名次对应的玩家账号。

我感觉这段至少有15分钟,我反复探索和理清思路,面试官没有催促不耐烦,还是很开心能遇到好面试官。

7、对于一个计算机,有2GB的存储空间,现在使用malloc函数每次申请512MB的空间,最多可以申请几次?

理论上是4次,但实际会有额外的开销损耗,最多申请3次,第4次回报错

malloc() 分配的空间中,不仅包括用户申请的内存,还包含额外的管理开销(metadata)。

这些开销主要包括:

  • 内存分配器保存块信息(如大小、状态)的头部信息;
  • 内存页对齐(alignment);
  • 操作系统页级分配粒度(通常为 4KB);
  • 有时还包括堆起始地址的对齐损耗。

比如:

每次 malloc(512MB),实际上系统分配的可能是:

512MB + 结构体开销 + 对齐开销 ≈ 512MB + 几 KB。

因此第 4 次申请时,可能已经超出可用空间,导致返回 NULL

👉 实际情况:一般只能成功分配 3 次。

闲聊部分

整个面试全程大概40分钟,还是比较舒服的,但我反问环节问面试官的感受,他表示无可奉告。

问了我实习时长,当前所在地,实习结束后的规划,告诉我转正需要答辩这些信息。

我的舍友说腾讯如果意向要你,当场就给了hr面,我这个一天过去了还是没动静,两次面试都没开摄像头,心中还是有些不安。

全部评论

相关推荐

评论
点赞
3
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务