企业官网建设流程全解析

从电商到智能客服：一场 Java 大厂面试串起来的 Spring Cloud、Redis、Kafka 与 RAG 技术实战

一、面试开场：互联网大厂电商场景

场景：某互联网大厂的电商事业部，技术面试，岗位是 Java 后端工程师。主要负责「高并发订单系统 + 智能客服平台」相关业务。

人物：

• 面试官：架构组负责人，风格严肃、逻辑清晰。
• 小Y：号称“八年经验”的水货程序员，实则 CRUD 居多，回答简单问题还不错，复杂问题就开始打哈哈。

二、第一轮：电商下单链路与基础技术栈

这一轮聚焦：Spring Boot 电商下单接口、数据库设计、MyBatis/JPA、Redis 缓存、简单的高并发思路。

第一轮第 1 题：下单接口的整体设计

面试官：

我们先从最基础的来说。假设你要在一个电商平台里实现「立即下单」接口，技术栈是：

• 核心语言与平台：Java 11 + Spring Boot
• Web 框架：Spring MVC
• 数据库与 ORM：MySQL + MyBatis 或 JPA

请你说一下：

1. Controller、Service、Repository 分层如何设计？
2. 下单要涉及哪些关键表？
3. 用什么方式保证基本的数据一致性？

小Y：

这个嘛……就很简单啦。

1. Controller 里面写个/order/create的接口，参数就传商品 ID、数量啥的；
2. Service 就调一下 DAO；
3. 表的话，一个t_order就够了吧，其他的以后再加；
4. 一致性的话……加个事务注解@Transactional就完事了。

面试官（点点头）：

分层的大方向还可以，不过略微简单了些，等下我们再展开。

第一轮第 2 题：MyBatis 与 JPA 的选型与对比

面试官：

你刚才说可以用 MyBatis 或 JPA。那在我们的电商下单场景中：

1. MyBatis 和 JPA 的主要差异是什么？
2. 假设订单表字段比较多，而且经常要写复杂查询，你更偏向用哪个？为什么？

小Y：

呃……这个嘛……

MyBatis 就是写 XML，那种 SQL；JPA 就是不用写 SQL，那种自动的东西。

复杂查询的话……我觉得都行，看公司习惯吧。反正我只要能跑起来就行。

面试官（微微皱眉，又缓和下来）：

嗯，你说到了“XML”和“自动 SQL”，算是抓住了一个点，但还是太笼统了。后面我会用一个具体例子帮你区分。

第一轮第 3 题：Redis 缓存与库存扣减

面试官：

电商下单离不开库存。假设我们要做一个「秒杀」活动，技术栈上：

• 用Redis作为缓存和库存控制；
• 底层数据库仍然是 MySQL；

请你回答：

1. 为什么常用 Redis 来做秒杀库存？
2. 如何避免出现“超卖”的情况？
3. Redis 挂了怎么办？

小Y：

Redis 这个我熟！

1. Redis 很快嘛，内存的；
2. 超卖就……加个锁？synchronized一下？或者用 Redis 的INCR函数？反正别人都是这么写；
3. Redis 挂了就重启一下，实在不行再连数据库？

面试官（适度夸赞）：

你知道 Redis 用来做秒杀，是因为“快”，这个点是对的。不过在生产环境里，锁怎么加、超卖怎么解决、Redis 挂了之后的降级方案，都需要更系统的设计。这个我们放在答案里细讲。

第一轮第 4 题：简单的高并发思路

面试官：

假设我们的秒杀活动，同时要承受10 万 QPS的抢购请求。只从后端 Java 的角度，讲讲：

1. Spring Boot 应用层面，你会做哪些基础优化？
2. 数据库和缓存层面，你会做哪些思路上的设计调整？

小Y：

10 万 QPS……那就多加几个机器嘛，水平扩展一下就好。

Spring Boot 的话，就调一下线程池，Tomcat 的连接数搞大一点； 数据库嘛，能放 Redis 就放 Redis，实在不行多搞几个库分库分表？具体怎么分，我还没怎么做过，都是架构师搞的。

面试官（略感无奈又保持礼貌）：

水平扩展和线程池是一个方向，但还不够。等会我们用详细答案把高并发的思路拆一下。

三、第二轮：微服务、消息队列与支付系统

这一轮聚焦：Spring Cloud 微服务拆分，Kafka 消息队列、支付与金融服务、日志与监控。

第二轮第 1 题：微服务拆分与 Spring Cloud

面试官：

我们的电商系统已经从单体应用升级为微服务架构，使用：

• Spring Cloud+OpenFeign调用；
• Netflix OSS（例如 Eureka 做注册发现）；

请你设计一下：下单流程会涉及哪些微服务？大概说说服务之间如何调用。

小Y：

这个我在简历里写过！

下单嘛，就有订单服务、商品服务、用户服务、支付服务，还有库存服务之类的。

调用的话……就订单服务先调商品服务，确认库存；然后调支付服务，让用户付款；再调用户服务，看看是不是黑名单什么的。至于 Spring Cloud、Eureka 啥的，我一般都是看脚手架怎么给我生成的，直接用就行。

面试官（保持冷静）：

服务拆分的名字算说到了，但调用链的容错、重试、限流、熔断这些，你还没涉及。后面我们会用 Resilience4j 讲给你听。

第二轮第 2 题：Kafka 在订单与支付中的作用

面试官：

我们使用Kafka做订单与支付的异步解耦。场景如下：

• 用户下单成功后，订单服务先写入数据库，然后发送 Kafka 消息；
• 支付服务异步消费消息，发起第三方支付。

请回答：

1. 为什么要用 Kafka 做异步？
2. 如果 Kafka 消息重复消费，会有什么问题？如何应对？

小Y：

Kafka 就是那个特别快的消息队列嘛。

1. 用它做异步，主要是可以削峰填谷呀，让系统没那么卡；
2. 重复消费的话……再扣一次钱？这个肯定不行，不过一般不会重复吧？就加个幂等验证什么的，我在网上看过，有个字段叫requestId之类的。

面试官（稍微赞许）：

知道“削峰填谷”和“幂等”是不错的，说明你有接触过一些概念。只是如果让你自己设计幂等方案，可能还做不到落地，这个我们在答案中详细说明。

第二轮第 3 题：支付安全与 Spring Security / OAuth2

面试官：

进入支付环节，我们需要保证：

• 请求身份合法；
• 支付接口不被恶意调用；
• 用户敏感信息安全。

我们使用：

• Spring Security+JWT做认证授权；
• 第三方登录用OAuth2。

请你回答：

1. JWT 的基本结构是什么？为什么适合在微服务里使用？
2. OAuth2 在支付场景里一般怎么用？

小Y：

JWT 我知道，是一个很长的字符串，中间有点号，三段的。里面有用户信息和过期时间，适合分布式，因为不用每次查数据库。

OAuth2……就是微信登录、支付宝登录那种吧。具体流程就是重定向过去，再回来一个 code，然后就登录了。支付场景的话，应该也差不多吧，我还没自己写过，都是接第三方 SDK……

面试官（温和地引导）：

你对 JWT 的理解还不错。OAuth2 在支付场景里确实会跟第三方平台打交道，里面还有授权码模式、客户端凭证模式等。我们会在答案里画一个简单流程让你更清晰。

第二轮第 4 题：日志与监控体系

面试官：

电商+支付系统的可观测性很重要。我们现在使用：

• 日志：Logback+SLF4J，集中到ELK Stack（Elasticsearch + Logstash + Kibana）；
• 指标：Micrometer+Prometheus+Grafana；
• 链路追踪：Zipkin或Jaeger。

你能说一下：

1. 为什么要这么多工具一起用？
2. 出现订单支付延迟，你会从哪些指标或日志入手排查？

小Y：

这个就很复杂了……

我平时就是log.info多打点日志，然后出问题就去 Kibana 搜一下关键字。Prometheus 和 Grafana，我偶尔看过监控图，Zipkin 好像是做链路的？具体怎么配，我都是运维或者 SRE 在搞，我看到 URL 能访问就行。

面试官（略微叹气但仍尊重）：

至少你知道 ELK 是看日志，Prometheus 是看指标，Zipkin 是看链路，这个算基础认知。实际场景中，我们需要把它们串起来做系统排查。答案会补全这块。

四、第三轮：智能客服、RAG 与 AI 服务

这一轮聚焦：AIGC + 智能客服系统、RAG 检索增强生成、向量数据库、Agentic RAG 与复杂工作流。

第三轮第 1 题：智能客服业务场景设计

面试官：

我们公司正在做一个「智能客服系统」，主要能力是：

• 回答用户关于订单、物流、退款的问题；
• 支持自然语言语义搜索企业文档；
• 接入多渠道（App、Web、微信）。

技术栈包括：

• Spring Boot+Spring WebFlux（异步 Web）；
• Spring AI或 Google 的类 A2A 客户端；
• RAG（检索增强生成）、向量数据库（如 Milvus / Chroma / Redis）；
• Embedding 模型（OpenAI / Ollama）。

请你设计一下整体架构的思路：

1. 用户一句话过来，后端大致怎么处理？
2. 向量化与语义检索在哪一步做？

小Y：

AI 这个很潮啊，我也在玩 ChatGPT！

用户一句话过来，后端就转发给大模型，让它回答就好了吧？向量化的话……应该是先把问题转成向量，再去库里找相似的，然后拼在一起给模型？整体我还没实际做过，就是听别人讲 RAG 很厉害。

面试官（稍微肯定）：

你抓到了“向量化”和“语义检索”的关键步骤，这是不错的。实际项目里，我们还要考虑多轮会话、会话内存、工具调用等，这个在答案里会展开。

第三轮第 2 题：Agent、工具执行框架与 Agentic RAG

面试官：

在智能客服里，我们不仅要让模型“聊天”，还要让它：

• 查询订单系统；
• 发起退款审批；
• 调用物流查询接口。

我们使用：

• **Agent（智能代理）**框架；
• 工具执行框架 + 工具调用标准化；
• Agentic RAG来处理复杂工作流。

请你回答：

1. Agent 相比普通聊天有什么额外能力？
2. 工具调用大致是怎么回事？

小Y：

Agent……就是那种能自己想办法解决问题的 AI？普通聊天就是问答，Agent 好像还能帮你调用 API，帮你下单呀、改密码呀之类的。

工具调用嘛，就是给模型一堆“函数说明”，它决定要用哪个，然后我们后端去真的调那个接口再把结果给它。具体实现我没写过，就是在一些开源项目里看到过类似的东西。

面试官（认可其概念）：

你的理解方向是对的。实际上，工具调用需要严格的协议、权限控制和审计，Agentic RAG 会把检索、工具调用和多步推理整合起来。答案我们会用通俗方式解释。

第三轮第 3 题：向量数据库与企业文档问答

面试官：

我们要实现「企业文档问答」，让客服可以回答：

• 退款规则；
• 运费政策；
• 优惠券使用说明等。

底层我们使用：

• 文档加载（PDF、Word、网页）；
• 向量化（Embedding 模型）；
• 向量数据库（Milvus / Chroma / Redis）；
• 语义检索 + RAG。

请你回答：

1. 为什么不直接把所有文档丢给大模型？
2. 向量数据库比传统关系型数据库有什么不同？

小Y：

文档太多的话，大模型肯定吃不下呀，直接丢给它又贵又慢。

向量数据库……呃，就是存那种高维向量的东西？跟 MySQL 不一样，它好像是根据“相似度”来查的，而不是根据主键或条件。细节我不是很清楚，我只知道有个 Milvus 很火。

面试官（平静总结）：

你看，多知道一些“为什么”，即便没做过，也能走在正确方向上。这点不错。

第三轮第 4 题：AI 幻觉与安全风控

面试官：

最后一个问题。智能客服系统要注意：

• AI 幻觉（Hallucination）：模型胡编乱造；
• 安全与风控：不能乱给用户承诺、不能泄露隐私、不能被 prompt 注入攻击。

你觉得在系统设计上，可以做哪些措施减少这些风险？

小Y：

这个问题就有点玄学……

减少幻觉的话，我觉得就让模型少瞎说，多根据文档回答？还有就是加点规则，让它别乱承诺退款之类的。至于风控，我感觉应该是安全部门干的事情，我只负责把接口写好。prompt 注入听说过，但具体怎么防，我没研究过……

面试官（收尾）：

好的，今天就到这里吧。整体来看，你的基础勉强可以，但在微服务、消息队列、监控、AI 这几块还需要系统学习。

你先回去等通知，我们会综合评估后再决定是否给你下一轮机会。

五、面试题详解：从电商到智能客服的技术与业务梳理

下面是对面试中问题的详细讲解，适合希望系统理解电商业务与相关技术栈的小白读者。

1. 电商下单接口设计与数据库表

1.1 三层架构基本分工

在 Spring Boot + Spring MVC 项目中，常见分层是：

• Controller 层：

  • 接收 HTTP 请求（例如/api/orders/create）；
  • 进行参数校验（@Valid、@Validated）；
  • 只做简单的 DTO 转换，不写业务逻辑。

• Service 层：

  • 编写核心业务逻辑，如：检查库存、计算价格、生成订单号、调用其他服务；
  • 处理事务（@Transactional）。

• Repository / Mapper 层：

  • 与数据库交互；
  • MyBatis Mapper 接口或 JPA 的 Repository 接口。

1.2 下单涉及的关键表

一个基础电商下单，至少涉及：

• t_product：商品信息（名称、价格、库存、状态）；
• t_order：订单主表（订单号、用户 ID、总价、状态等）；
• t_order_item：订单明细（商品 ID、数量、单价）；
• t_user：用户信息（基础信息、会员等级等）；
• t_inventory：库存表（商品 ID、可用库存、预留库存）。

1.3 基本数据一致性与事务

下单时要保证：

1. 扣减库存；
2. 生成订单；
3. 订单与库存状态一致。

在单体应用、同库同事务的场景中，可以在 Service 层用：

@Transactional public void createOrder(OrderRequest request) { // 1. 校验商品和库存 inventoryMapper.lockInventory(request.getProductId()); // 2. 扣减库存 inventoryMapper.decreaseStock(request.getProductId(), request.getQuantity()); // 3. 生成订单 orderMapper.insert(order); orderItemMapper.batchInsert(orderItems); }

多服务、多数据库则需要分布式事务或最终一致性方案（如可靠消息 + 重试机制）。

2. MyBatis 与 JPA/Jakarta Persistence 的对比

2.1 MyBatis 特点

• SQL 手写（在 XML 或注解中），控制精细；
• 对复杂查询、联表查询友好；
• 更贴近数据库层，适合需要严格控制 SQL 的场景；
• 常与MyBatis-Plus等增强框架一起使用。

2.2 JPA 特点

• 面向对象（Entity + Repository），通常使用 Hibernate 作为实现；
• 自动生成 SQL（基于方法命名规则或 JPQL）；
• 快速开发 CRUD 很方便；
• 对复杂查询虽有支持（Criteria API、Specification），但很多团队认为不如手写 SQL 直观。

2.3 在电商场景的选型建议

• 若订单查询非常复杂，涉及多维度筛选、报表统计，
  • 偏向 MyBatis，方便写复杂 SQL，做索引优化。
• 若业务以常规 CRUD 为主，团队熟悉 JPA，
  • 可以选择 JPA，开发效率较高。

很多大厂会：

• 基础业务用 JPA 或 Spring Data JPA；
• 复杂查询使用 MyBatis 或专门的查询模块。

3. Redis 秒杀库存与超卖问题

3.1 为什么用 Redis 做秒杀库存？

• Redis 在内存中读写，性能高、延迟低；
• 支持原子操作（如DECR、HINCRBY），方便做并发控制；
• 可以通过 Lua 脚本实现复杂逻辑的原子操作。

3.2 防止超卖的经典方案

1. 提前将可售库存加载到 Redis：

   • 数据库中有真实库存；
   • 秒杀前将库存值同步到 Redis。

2. 请求到达时先在 Redis 中扣减：

   • 当 Redis 库存减到 0 或负数时拒绝请求；
   • 用 Lua 脚本保证判断与扣减是一个原子操作。

示例 Lua 脚本（简化）：

local stock = redis.call("GET", KEYS[1]) if (tonumber(stock) <= 0) then return 0 end redis.call("DECR", KEYS[1]) return 1

3. 异步写数据库：
   • Redis 扣减成功的请求入队（Kafka、RabbitMQ 等）；
   • 后端消费者异步写入订单和库存变更。

3.3 Redis 挂掉的降级思路

• Redis 主从架构 + 哨兵 / 集群，提高可用性；
• Redis 不可用时：
  • 暂停秒杀入口（避免数据库被打爆）；
  • 或退回到数据库层的乐观锁 / 悲观锁方案（性能大幅降低）。

4. 高并发下的后端优化思路

4.1 应用层（Spring Boot）

• 适当调优线程池：
  • Tomcat/Netty 的连接数、线程数；
  • 业务线程池（如异步任务专用 Executor）。
• 减少无意义的对象创建和复杂计算；
• 使用连接池（HikariCP）优化数据库连接；
• 使用Spring WebFlux在部分 IO 密集场景提升吞吐（非必须）。

4.2 缓存与数据库层

• 使用 Redis / 缓存热点数据（商品详情、库存、活动配置）；
• 限流与降级：
  • 对秒杀接口做流量控制（网关层、应用层）；
  • 超出能力时返回友好的排队或失败信息；
• 数据库分库分表：
  • 按用户维度或订单时间维度拆分；
  • 使用中间件（如 ShardingSphere）统一管理。

5. 微服务拆分与 Spring Cloud 调用链

5.1 常见的电商微服务拆分

• user-service：用户信息、会员等级；
• product-service：商品信息、上下架；
• inventory-service：库存管理；
• order-service：订单创建、查询；
• payment-service：支付发起与结果处理；
• marketing-service：优惠券、活动；
• customer-service：客服与工单系统。

5.2 Spring Cloud 的典型组件

• Eureka / Consul：服务注册与发现；
• OpenFeign：服务之间的声明式 HTTP 调用；
• Gateway / Zuul：统一网关与路由；
• Resilience4j：熔断、限流、重试、隔离。

5.3 调用链示例：用户下单

1. 网关接收/api/order/create请求；
2. 转发到order-service；
3. order-service使用 Feign 调用：
   • inventory-service：锁定库存；
   • marketing-service：校验优惠券；
   • user-service：校验用户状态；
4. 订单写入数据库后，发送 Kafka 消息；
5. payment-service消费消息，发起支付。

配合 Resilience4j，若下游服务超时或异常，可快速失败或降级，避免雪崩。

6. Kafka 与订单支付的异步解耦

6.1 为什么用 Kafka？

• 高吞吐、可扩展；
• 支持消息持久化与多消费者；
• 可以隔离下单与支付两种操作的时序关系。

6.2 异步解耦的好处

• 下单接口快速返回（仅负责写订单和发消息）；
• 支付服务可以根据自身能力消费消息；
• 出问题时可以重试或补偿，不影响主链路性能。

6.3 幂等处理与重复消费

问题：同一条订单消息可能被重复消费（网络重试、消费者故障）。

常见幂等方案：

1. 在消息体中加入全局唯一 ID（如eventId、orderId+eventType）；
2. 在支付服务侧建立消费记录表或 Redis 集合；
3. 消费前先检查是否已经处理过：
   • 若已处理，则跳过；
   • 若未处理，则执行支付逻辑并记录处理状态。

7. 支付安全：Spring Security、JWT 与 OAuth2

7.1 JWT 基本结构

JWT（JSON Web Token）通常由三部分组成：

1. Header：说明签名算法、类型；
2. Payload：包含用户 ID、角色、过期时间等；
3. Signature：使用密钥对以上内容签名，防止篡改。

格式如：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywiZXhwIjoxNzAwMDAwMDB9.signature...

适合微服务的原因：

• 服务之间可以通过检查 JWT 来完成认证授权，而无需集中查询 Session；
• 无状态，便于水平扩展。

7.2 OAuth2 在支付场景中的应用简图

以第三方支付平台（如支付宝、微信）为例：

1. 用户在我们平台发起支付；
2. 我们平台重定向用户到第三方支付平台；
3. 用户在第三方平台完成授权（确认支付）；
4. 第三方支付平台回调我们的后端，携带授权码或支付结果；
5. 我们后端使用授权码换取支付凭证或查询结果，更新订单状态。

Spring Security OAuth2 或 Spring Authorization Server 可以帮助简化这一流程的实现。

8. 日志与监控：ELK、Micrometer、Prometheus、Grafana、Zipkin

8.1 三大类可观测数据

1. 日志（Logs）：

   • 通过 Logback + SLF4J 输出；
   • 使用 ELK Stack 收集、索引、查询。

2. 指标（Metrics）：

   • 使用 Micrometer 集成到 Prometheus；
   • 在 Grafana 上展示 QPS、RT（响应时间）、错误率、CPU、内存等。

3. 链路追踪（Traces）：

   • 使用 Zipkin / Jaeger；
   • 跟踪一次请求经过的各个微服务与耗时。

8.2 排查订单支付延迟的思路

1. 从 Grafana 看支付接口的平均响应时间是否异常；
2. 从 Prometheus 看数据库或外部服务（第三方支付）相关指标是否有峰值；
3. 使用 Zipkin 查看调用链在哪一段耗时明显变高；
4. 再到 ELK 检索具体错误日志或慢 SQL 日志；
5. 综合判断是内部系统问题还是第三方接口问题。

9. 智能客服系统的整体架构与流程

9.1 基础架构

• 接入层：WebSocket / HTTP，支持 App、Web、微信小程序；
• 会话管理：维护用户会话、上下文、聊天会话内存；
• AI 服务层：
  • LLM 客户端（Spring AI、Google A2A 等）；
  • RAG 模块（检索增强生成）；
  • Agent 模块（工具调用、工作流管理）；
• 业务系统：订单、物流、支付、退款等微服务；
• 向量数据库：Milvus / Chroma / Redis（Vector）；
• 监控与风控：审计日志、安全策略、内容过滤。

9.2 用户一句话的处理流程（RAG 版）

1. 用户在前端输入问题，例如：“帮我查一下昨天买的耳机订单状态”；
2. 后端接收到请求，先解析用户意图和上下文（会话内存）；
3. 判断是否需要检索文档或调用工具：
   • 若是订单查询：调订单服务；
   • 若是政策咨询：走文档问答流程（RAG）。
4. 文档问答流程：
   • 根据问题生成向量（Embedding 模型）；
   • 到向量数据库中做语义检索，找到相关文档片段；
   • 把检索到的内容作为上下文，拼接到提示词中；
   • 调用大模型生成回答。

10. Agent、工具调用与 Agentic RAG

10.1 Agent 的额外能力

相较于普通聊天，Agent：

• 有明确的任务目标（例如：完成订单退款流程）；
• 能根据环境信息选择合适的工具（API、函数）；
• 可以规划多步操作（调用多个工具）完成复杂工作流。

10.2 工具调用框架的基本模式

1. 在后端定义一组可被调用的工具：
   • 如getOrderStatus(orderId)、createRefund(orderId)、queryLogistics(trackingNo)；
2. 将工具的“签名”和“说明”暴露给模型（通过协议，如 MCP 模型上下文协议等）；
3. 模型根据用户输入和自身推理，选择调用某个工具；
4. 后端根据模型输出的工具调用请求，真正执行该工具；
5. 将工具执行结果反馈给模型，让其基于结果继续回答或执行下一步。

10.3 Agentic RAG 的大致思路

• 在传统 RAG 的“检索+生成”之上：
  • 增加 Agent 的规划能力，对问题进行拆解（多步工作流）；
  • 在检索和工具调用之间动态切换；
  • 可以在企业文档问答、订单查询、退款审批之间自适应。

示例：用户问“昨天买的耳机坏了，可以怎么退？”

1. Agent 拆解为：
   • 查订单 -> 查物流状态 -> 检索退货政策文档；
2. 先调用订单查询工具；
3. 再调用物流查询工具；
4. 再做退货政策的 RAG 检索；
5. 综合结果生成最终回答，并引导用户下一步操作。

11. 向量数据库与企业文档问答的核心概念

11.1 为什么不直接把文档丢给大模型？

• 文档量往往巨大（规则、协议、知识库）；
• 直接传给模型成本高、上下文窗口有限；
• 更新文档后，传统“微调”成本非常高。

RAG 通过“检索 + 生成”解决：

1. 文档预处理：切片、清洗；
2. 向量化：用 Embedding 模型将每个片段转换为向量；
3. 存入向量数据库；
4. 问题来时只检索相关片段作为上下文，大幅减少传给模型的内容且保证最新。

11.2 向量数据库与关系型数据库的区别

• 存储的数据类型不同：

  • 向量数据库存储高维向量（如 768 维、1536 维）；
  • 关系型数据库存储结构化数据（字段、表）。

• 查询方式不同：

  • 向量数据库基于“相似度”（如余弦相似度、向量距离）检索；
  • MySQL 常通过索引（B+ 树）按条件查找。

• 应用场景不同：

  • 向量数据库用于语义检索、推荐系统、图像搜索等；
  • 关系型数据库用于事务性业务（订单、用户、库存）。

Redis 也可以通过专门的模块支持向量检索，但对大规模场景往往推荐专业的向量数据库，如 Milvus、Chroma 等。

12. AI 幻觉与安全风控的工程实践

12.1 减少幻觉的技术手段

1. 使用 RAG：让模型基于企业文档回答，而不是随意发挥；
2. 设计提示词：明确告诉模型“只能根据提供的资料回答”；
3. 在答案生成阶段做规则过滤：
   • 若模型回答中出现“我不确定、可能是、据我所知”等模糊语句，要求它重试；
   • 若回答涉及钱款承诺，需经过规则引擎或人工审核。

12.2 安全与风控措施

• 权限控制：
  • Agent 工具调用必须遵循权限规则，不能跨用户查看隐私；
• 审计日志：
  • 记录每次工具调用的参数、结果、调用方；
• 内容过滤：
  • 使用策略或模型过滤敏感内容（黄赌毒、政治、攻击性语言）；
• Prompt 注入防护：
  • 给模型核心系统提示，强调“不执行用户提供的恶意指令”；
  • 对用户输入与系统提示进行分离管理。

六、小结

通过这一场“电商下单 + 支付系统 + 智能客服平台”的 Java 大厂面试，我们串联了：

• 核心 Java 与 Spring Boot / Spring MVC 的分层与数据库设计；
• Redis、Kafka、Spring Cloud 等在电商高并发场景下的典型用法；
• Spring Security、JWT、OAuth2 在支付与安全中的应用；
• ELK、Prometheus、Grafana、Zipkin 等监控与可观测性体系；
• RAG、向量数据库、Agent、Agentic RAG 在智能客服与企业文档问答中的实战思路；
• AI 幻觉与安全风控的工程最佳实践方向。

希望这篇“面试故事 + 技术详解”能让刚入门的小伙伴看到真实业务场景下这些技术栈如何协同工作，也帮助你在下一次面试里，比小Y更从容、更专业。