9月下旬，莫着急！附虾皮一面面经。

9 月下旬，看身边有些同学开始着急了。但我的结论就是实力不差的，没拿到 offer 只是暂时的。

对于腰部和裆部选手来说，可能 11 月 12 月才是真正的舞台，还需要再坚挺一段时间。等头部选手和肩部选手把 offer 释放出来后，你可能突然发现，拿个 offer 竟然这么容易。

所以一定要学会解压，游戏该打打、体能锻炼也不能丢，实在是心里委屈了，可以一块诉诉苦。

这种不被进度压垮的心态在接下来这三个多月时间里非常关键。

目前最应该去做的，就是不断迭代简历、升级项目、复盘面试题。

接下来这段时间，我也会高频给大家复盘各大公司的面试题。

目的只有一个，哪里跌倒就从哪里爬起来，复盘是为了下一次面试能顺利通过。

接下来，我们就以虾皮一面为例，来看看下面这些题目该怎么回答，好做到知彼知己百战不殆。

虾皮一面

讲一下派聪明的主要模块和功能

派聪明是一个企业级的 AI 知识库管理系统 。它的核心功能是对用户上传的私有文档（比如 Word、PDF、txt 等），进行语义解析和向量处理，然后存储到 ElasticSearch 中以供后续的关键词检索和语义检索。

它的主要模块和功能包括：

1. 文档处理 ：用户上传文档后，系统会像图书管理员一样，自动将文档内容拆分成一个个小的知识片段。
2. 知识向量化 ：接着，派聪明会利用豆包/阿里的向量模型为每个知识片段生成一个独特的“语义指纹”，并存入 Elasticsearch 中。
3. 智能检索 ：当用户提出问题时，系统会先将问题转换成“语义指纹”，然后在 ES 中寻找与问题意图最匹配的几个知识片段。
4. 生成答案 ：最后，派聪明会将用户的原始问题和找到的相关知识片段一起交给大型语言模型（比如 DeepSeek ），让这个“大脑”基于给定的上下文，生成一个精准、流畅、人性化的回答。

es 怎么存的

我们在 ElasticSearch 中新建了一个名 knowledge_base 的索引，它将为每一条数据存储两种关键信息。

其中，textContent 字段用于关键词搜索，vector 字段用于语义搜索。

关键词会通过 ik 分词器直接存储在 textContent 字段中，而文本的 chunk 会通过 embedding 模型向量后存入 vector 字段。

kafka 是如何处理异构的

首先，Kafka 能处理异构系统的核心在于，它本身并不关心消息到底是什么内容。无论是 JSON、文本，还是其他任何格式，Kafka 的服务端都一视同仁，把它们当作一堆字节数组（byte[]）来处理。

这种把数据格式的定义和解析工作，从 Kafka 服务端转移到客户端，也就是生产者和消费者身上。就是解耦的关键。

生产者在发送数据前，会用一个“序列化器”把程序中的数据对象“翻译”成字节数组。消费者在收到数据后，会用一个“反序列化器”把字节数组再“翻译”回自己能理解的数据对象。

比如说用户提了一个问题， ParseService 在处理后，会向 user_interactions 主题发送一条 JSON 格式的消息： {"userId": "123", "action": "ask_question", "timestamp": 1678886400, "details": "Kafka是什么？"}。

有哪些生产者哪些消费者

从生产者角度来看，系统的核心生产者是 UploadController.java 中的文件上传控制器。当用户完成文件分片上传并触发合并操作时，系统会在 mergeFile 方法中通过 kafkaTemplate.executeInTransaction 以事务性方式发送 FileProcessingTask 消息到 file-processing-topic1 主题。

消费者方面， FileProcessingConsumer.java 承担着主要的消息处理职责。它监听 file-processing-topic1 主题，接收到 FileProcessingTask 后会执行文件解析、内容提取和向量化等复杂的 AI 处理流程。

消费者采用了智能的错误处理机制，当处理失败时会自动重试最多 4 次，如果仍然失败，消息会被自动路由到死信队列 file-processing-dlt 中，避免了单个问题文件阻塞整个处理流程。

prompt 是如何设计的？

首先，在构建 Prompt 的时候，我们把系统规则始终放在最前面，并用中文直接声明几件关键事情，比如：回复必须标注引用编号（例如来源#1），如果检索不到结果也必须礼貌告知“暂无相关信息”，这一点是通过配置明确约束模型输出行为的。

其次，我们在技术上对检索结果和用户问题进行了语义隔离，所有来自知识库的内容都会被包裹在一对特殊符号 <<REF>> ... <<END>> 之间，这样能让大语言模型非常清楚哪些是“引用材料”，避免混淆生成逻辑。

为了支持连续对话，我们把用户对话历史存在 Redis 中，但也做了长度控制，最多只保留最近 20 条。如果超过，就自动裁剪，这样可以防止上下文爆炸，保持性能和响应效率。

最后，整个 Prompt 逻辑，包括提示词、引导规则、分隔符、温度参数等等，都是配置在 application.yml 文件里的，可以随时调整规则或采样参数。

MySQL 的 MCC 了解吗？

MVCC 指的是多版本并发控制，每次修改数据时，都会生成一个新的版本，而不是直接在原有数据上进行修改。并且每个事务只能看到在它开始之前已经提交的数据版本。

这样的话，读操作就不会阻塞写操作，写操作也不会阻塞读操作，从而避免加锁带来的性能损耗。

其底层实现主要依赖于 Undo Log 和 Read View。

每次修改数据前，先将记录拷贝到Undo Log，并且每条记录会包含三个隐藏列，DB_TRX_ID 用来记录修改该行的事务 ID，DB_ROLL_PTR 用来指向 Undo Log 中的前一个版本，DB_ROW_ID 用来唯一标识该行数据（仅无主键时生成）。

每次读取数据时，都会生成一个 ReadView，其中记录了当前活跃事务的 ID 集合、最小事务 ID、最大事务 ID 等信息，通过与 DB_TRX_ID 进行对比，判断当前事务是否可以看到该数据版本。

间隙锁了解吗？

间隙锁用于在范围查询时锁定记录之间的“间隙”，防止其他事务在该范围内插入新记录。仅在可重复读及以上的隔离级别下生效，主要用于防止幻读。

---- 这部分是帮助大家理解 start，面试中可不背 ----

例如事务 A 锁定了 (1000,2000) 区间，会阻止事务 B 在此区间插入新记录：

-- 事务A
BEGIN;
SELECT * FROM orders WHERE amount BETWEEN 1000 AND 2000 FOR UPDATE;

-- 事务B尝试插入会被阻塞
INSERT INTO orders VALUES(null,1500,'pending');  -- 阻塞

假设表 test_gaplock 有 id、age、name 三个字段，其中 id 是主键，age 上有索引，并插入了 4 条数据。

CREATE TABLE `test_gaplock` (
  `id` int(11) NOT NULL,
  `age` int(11) DEFAULT NULL,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `age` (`age`)
) ENGINE=InnoDB;

insert into test_gaplock values(1,1,'张三'),(6,6,'吴老二'),(8,8,'赵四'),(12,12,'熊大');

间隙锁会锁住：

• (−∞, 1)：最小记录之前的间隙。
• (1, 6)、(6, 8)、(8, 12)：记录之间的间隙。
• (12, +∞)：最大记录之后的间隙。

假设有两个事务，T1 执行以下语句：

START TRANSACTION;
SELECT * FROM test_gaplock WHERE age > 5 FOR UPDATE;

T2 执行以下语句：

START TRANSACTION;
INSERT INTO test_gaplock VALUES (7, 7, '王五');

T1 会锁住 (6, 8) 的间隙，防止其他事务在这个范围内插入新记录。

T2 在插入 (7, 7, '王五') 时，会被阻塞，可以在另外一个会话中执行 SHOW ENGINE INNODB STATUS 查看到间隙锁的信息。

---- 这部分是帮助大家理解 end，面试中可不背 ----

#牛客AI配图神器#