面试官和水货程序员小Y：从音视频、电商到AI智能客服的Java技术面试实战（含线程池、Spring全家桶、微服务、RAG）

场景：某互联网大厂 Java 开发面试现场，业务线涵盖 音视频互动、电商交易、AI 智能客服。面试官严肃专业，被面试者小Y嘴皮子很溜，但技术有点水。

第一轮：音视频互动场景（Java 基础 & 并发 & 缓存 & 消息队列）

场景设定： 公司做的是一个 音视频互动直播平台，支持在线课堂和游戏陪玩，后端主要使用 Java 17 + Spring Boot + Kafka + Redis + Kubernetes。

面试官 Q1：高并发下的线程池设计

面试官： 平台高峰时期有几十万用户同时在线上麦互动，后端有大量信令请求（比如上麦、下麦、送礼物）。如果你用 Java 线程池处理这些请求，ThreadPoolExecutor 里的几个核心参数你会怎么设？

小Y：

嗯……这个嘛，大概就是线程池开大一点就可以了，比如 maxPoolSize 直接 1000，这样就不容易拒绝请求了，然后队列也给大一点。反正多线程越多越快嘛，哈哈。

面试官：

多线程不是越多越快……好，先记一下，待会我们再回到这个问题。

面试官 Q2：Redis 缓存的使用与雪崩问题

面试官： 热门直播间信息（在线人数、礼物数、主播信息）我们放在 Redis 里做缓存。你来说说：

  1. 读写模式怎么设计？（比如 Cache-Aside / Read-Through 等）
  2. 如果某个瞬间很多 Key 同时过期，可能导致雪崩，你会怎么处理？

小Y：

这个我知道，用 Redis 就是 get、set 呀，读不到再查数据库。雪崩的话，可以重启一下 Redis 集群……

面试官：

……重启 Redis 一般是雪崩之后才会做的事。行，继续往下。

面试官 Q3：Kafka 在礼物发放场景的应用

面试官： 用户送礼物时，我们要：

  • 记录礼物流水（写数据库）；
  • 实时更新直播间礼物榜；
  • 给大屏弹幕；
  • 触发排行榜更新。

我们用了 Kafka 做异步解耦。你简要说下：

  1. 生产者如何保证消息不丢？
  2. 消费者如何保证“至少消费一次”？
  3. 消息重复消费会有什么问题，如何解决？

小Y：

Kafka 就是高吞吐嘛，send 一下就好了。消息不丢的话……多发几遍？消费者重复消费就重复算一下呗，老板应该不会介意，哈哈。

面试官：

老板肯定会介意的，尤其是多扣用户钱的时候。

面试官 Q4：WebSocket & Spring Boot

面试官： 在线课堂里我们使用 WebSocket 做实时互动聊天，你在 Spring Boot 里会怎么实现一个简单的 WebSocket 聊天服务？涉及哪些关键注解或配置？

小Y：

Spring Boot 不就是 @RestController 吗？WebSocket 是不是也差不多，@GetMapping("/ws") 一下就有了？

面试官：

……等会儿我把白板让给你画一下代码结构，你先心里准备准备。

面试官 Q5：监控与链路追踪

面试官： 我们接入了 Prometheus + Grafana 做监控，用 Jaeger/Zipkin 做链路追踪。你觉得在音视频场景里，应该重点监控哪些指标？（至少说 4–5 个，并说明意义）

小Y：

指标嘛，CPU、内存肯定要监控，还有磁盘。你们既然有 Jaeger，那就监控一下 Jaeger 的 CPU？这个我平时没怎么看过图表。

面试官：

行，第一轮就先这样。我们换个你更熟悉的电商场景。

第二轮：电商购物场景（Spring & 数据库 & 分布式与微服务）

场景设定： 公司还有一条 电商业务线，用户可以在直播间边看边买（音视频 + 电商融合）。技术栈是 Spring Boot + Spring Cloud + MyBatis + Redis + Kafka + Docker/Kubernetes。

面试官 Q1：下单流程与分布式事务

面试官： 用户在直播间点击“立即下单”，后端需要：

  1. 创建订单；
  2. 扣减库存；
  3. 扣减优惠券；
  4. 发送下单成功消息给物流系统；

服务是拆成 订单服务、库存服务、营销服务、物流服务 的微服务，使用 HTTP + Kafka。你会怎么设计这个分布式事务？用到哪些模式（比如 TCC、Saga、事务消息、最终一致性等）？

小Y：

这个我有思路。我们可以在订单服务里开一个大事务，把其他服务的接口都调完再一起提交，这样就能保证一致性了。数据库有事务嘛，多用就好了。

面试官：

分布式系统里“一个大事务”的成本往往太高，而且 HTTP 调用不在同一个数据库事务里……

面试官 Q2：MyBatis 与连接池 HikariCP 的使用

面试官： 我们的订单服务用 MyBatis + HikariCP。你能说一下：

  1. MyBatis 和 JPA/Hibernate 的主要区别是什么？
  2. HikariCP 的核心配置参数有哪些？哪个对性能影响最大？

小Y：

MyBatis 就是写 SQL 的，JPA 就是不用写 SQL 的，这两个差不多。HikariCP 主要配置就是 URL、用户名、密码，性能嘛，内存越大越快。

面试官：

好，你至少知道 MyBatis 要自己写 SQL，这点还不错。

面试官 Q3：缓存一致性 & 本地缓存

面试官： 商品详情我们放在 Redis + 本地 Caffeine 缓存 中：

  • 启动时预热热门商品；
  • 读请求绝大部分走本地缓存；
  • 更新商品价格时，需要尽量保证 Redis 与本地缓存一致。

请你说下：

  1. 本地缓存 + Redis 的读写路径怎么设计？
  2. 更新时如何保证尽量一致？（可以接受短暂不一致）

小Y：

我觉得可以每次查都从数据库查，顺便更新一下缓存，就肯定不会不一致了。不过这样可能稍微有点慢，但稳。至于本地缓存，就看运气吧，反正迟早会过期。

面试官：

……你这个方案确实“稳”，就是 QPS 上不去。

面试官 Q4：Spring Cloud & 服务治理

面试官： 我们的微服务使用 Spring Cloud + Eureka + OpenFeign + Resilience4j：

  1. 说一下服务注册发现的大致流程；
  2. Feign 调用超时或目标实例挂了，Resilience4j 如何帮我们做降级或熔断？

小Y：

Eureka 我知道，就是一个注册中心。服务都去那里报个到，然后互相就能打电话。Feign 超时就多重试几次嘛，实在不行就一直重试，总会通的。

面试官：

一直重试有时候会把集群直接打趴下……

面试官 Q5：安全与风控（Spring Security + JWT）

面试官： 电商业务涉及支付，我们使用 Spring Security + JWT + 自研风控服务。你说一说：

  1. JWT 的基本结构是怎样的？（三部分）
  2. 在 Spring Security 里，一次携带 JWT 的请求大致会经历哪些过滤器/拦截处理？

小Y：

JWT 就是一串很长的字符串，中间好像有两个点。Spring Security 的过滤器我不太清楚，一般我就谷歌一下，然后复制一段配置，能过就行。

面试官：

至少你知道有两个点，比有些人多一个知识点。

第三轮：AI 智能客服 & RAG 场景（AI 集成、RAG、监控与日志）

场景设定： 公司在做 智能客服系统，结合电商和音视频场景，为用户提供：订单查询、直播间问题解答、商品推荐。技术栈包括：

  • 后端：Spring Boot + Spring Cloud
  • AI：Spring AI，向量数据库（Milvus/Redis），Embedding 模型（OpenAI/Ollama）
  • 能力：RAG（检索增强生成）、Agent、工具调用、聊天会话内存

面试官 Q1：RAG 检索增强生成架构

面试官： 我们做了一个基于 RAG 的智能客服，知识来源包括：商品文档、FAQ、订单协议、直播规范。请你说说：

  1. 一个典型的 RAG 请求从用户问题到最终回答，大致会经历哪几个关键步骤？
  2. 为什么 RAG 比“单纯大模型”更适合做企业问答？

小Y：

RAG 我听过，好像挺火的。大概流程就是：用户问问题 -> 调用大模型 -> 返回答案。为什么更适合企业？可能是因为听起来比较高级，老板会更愿意买单？

面试官：

……等会儿我会把这个问题的标准答案放在文章最后，你可以好好补一下。

面试官 Q2：向量化与语义检索

面试官： 我们把商品文档和 FAQ 向量化存到 Milvus/Redis 里，做语义检索。你来描述一下：

  1. 向量化（embedding）是怎么用在语义检索里的？
  2. 和传统关键词倒排索引（比如 Elasticsearch）相比，有什么优势和不足？

小Y：

向量嘛，就是很多数字的数组，然后可以算余弦相似度。语义检索就是比大小，反正相似度高的就是相关。和关键词相比，向量检索更贵吧，老板可能会心疼钱。

面试官：

至少你还记得余弦相似度，这是个好苗头。

面试官 Q3：Agent 与工具调用

面试官： 客服系统里我们做了一个 Agent，它可以：

  • 解析用户意图；
  • 在需要时调用“订单查询工具”、“物流查询工具”、“退货工具”；
  • 组合多个工具结果给出最终回复。

你觉得在 Java 后端里实现这种“工具调用框架”，需要考虑哪些点？

小Y：

工具调用我觉得就写几个 if-else 就好了，比如如果用户说“订单”，就调订单接口；说“物流”，就调物流接口。复杂一点就多写几个 if，要是还不够就再多写几个 if。

面试官：

假如以后工具从 3 个变成 30 个，你可能会被自己的 if-else 淹死。

面试官 Q4：AI 幻觉（Hallucination）与企业安全

面试官： 在智能客服里，大模型有时会“胡说八道”，比如瞎编一个不存在的退款规则。结合 RAG，你觉得我们可以从哪些角度减少幻觉，保证回答安全可靠？

小Y：

幻觉就是瞎编吧，我觉得可以在回答最后写一句“本回答仅供参考，一切以平台规则为准”，这样就安全了。

面试官：

嗯……这是法律合规同学会做的事，技术上我们还是要认真一点。

面试官 Q5：日志与可观测性（ELK + 调试 AI 请求）

面试官： 我们用 ELK + Micrometer + Prometheus 监控 AI 服务，尤其关注：请求耗时、失败率、模型调用费用等。对于一个 RAG 请求，你觉得应该在日志里重点记录哪些字段，才能方便排查问题？

小Y：

记录一下用户 ID 吧，还有问题内容。其他的我一般就是看一下有没有异常栈，有的话就 printStackTrace。费用的话……应该财务会看，不用我们管。

面试官：

好的，三轮就到这里。今天的面试先到这一步，你回去等通知吧。我们会综合考虑你的表现。

标准答案与场景拆解：从零理解业务与技术设计

下面是上面问题的详细解析，按场景拆解，适合 Java 初中级同学系统学习。

一、音视频互动场景：高并发、缓存、消息队列、WebSocket、监控

1. 线程池设计（音视频信令请求）

业务场景： 上麦、下麦、送礼物等信令请求量大但单次处理时间短，适合使用线程池提升吞吐。

技术点：ThreadPoolExecutor 核心参数

public ThreadPoolExecutor(
        int corePoolSize,
        int maximumPoolSize,
        long keepAliveTime,
        TimeUnit unit,
        BlockingQueue<Runnable> workQueue,
        ThreadFactory threadFactory,
        RejectedExecutionHandler handler)
  • corePoolSize：核心线程数，业务 QPS 稳态下主要依赖这一批线程，一般根据 机器 CPU 核数 + 任务类型（CPU 密集 / IO 密集） 估算。
    • CPU 密集：core ≈ CPU核数
    • IO 密集：core ≈ CPU核数 × (1 + IO耗时/计算耗时)
  • maximumPoolSize：高峰扩容的线程数，不宜过大，避免频繁切换。通常是 core 的 2~4 倍。
  • workQueue：任务队列，常用 LinkedBlockingQueue（无界） 或 ArrayBlockingQueue（有界）。
    • 高并发场景建议 有界队列，控制内存；队列满了启用拒绝策略。
  • keepAliveTime / unit：非核心线程空闲多久被回收。
  • threadFactory：给线程命名、设置优先级等，方便排查问题。
  • handler（拒绝策略）：如 CallerRunsPolicy、自定义记录日志+限流告警等。

设计建议：

  • 控制最大并发：使用合理 maxPoolSize + 有界队列，防止 OOM；
  • 应用级限流：配合 Sentinel / Resilience4j 做限流与熔断；
  • 不同类型任务拆不同线程池（信令处理、持久化、大计算任务）。
2. Redis 缓存 & 雪崩

常见读写模式：

  1. Cache-Aside（旁路缓存）：

    • 读：
      1. 先读缓存（Redis）；
      2. 没有则查 DB，写入缓存，并返回；
    • 写：
      1. 先写 DB；
      2. 再删除/更新缓存。

  2. Read-Through / Write-Through：由缓存中间层自动处理读写 DB，Java 里一般通过类似 Spring Cache + 自定义 CacheManager 实现。

缓存雪崩场景：

  • 大量 Key 在同一时间过期；
  • 瞬时大量请求打到 DB，DB 被打挂。

常用解决策略：

  1. 随机过期时间：设置 TTL 时加随机偏移，避免大量 Key 同时过期：
    • 示例：baseTTL + random(0, 300) 秒
  2. 热点 Key 保护：
    • 对极热点 Key 加本地缓存（Caffeine）；
    • 热 key 单独监控，提前预热；
  3. 请求合并 / 互斥锁：
    • 缓存失效时，通过 Redis 分布式锁保证只有一个请求去查 DB & 回填缓存；
    • 其他请求短暂等待；
  4. 降级策略：
    • Redis/DB 异常时，走降级数据或直接限流。
3. Kafka 在送礼物场景中的使用

业务需求： 一条送礼物请求要同时驱动多种后续动作，适合使用 消息队列解耦。

1）生产者如何保证消息不丢？

  • acks=all：需要所有 ISR 副本确认后才认为写入成功；
  • retries + 幂等生产者（enable.idempotence=true）：避免网络抖动导致重复写；
  • 业务层：写 DB 成功后再 send 消息，确保“数据在 DB 存在”；
  • 对重要消息可同时写本地事务表，用定时任务补偿。

2）消费者“至少消费一次”的实现：

  • 关闭自动提交 enable.auto.commit=false；
  • 业务处理完成后，再手动提交 offset；
  • 故障重启后从未提交的 offset 继续消费 => 至少一次，可能会重复。

3）如何处理重复消费：

  • 业务幂等：
    • 设计全局业务 ID（如礼物流水号），写 DB 时用唯一约束；
    • Redis SETNX / 去重表；
  • 消费逻辑避免“多扣钱、多发礼物”。
4. WebSocket + Spring Boot 简单实现

关键点：

  • 使用 spring-boot-starter-websocket；
  • 使用 @EnableWebSocketMessageBroker 构建 STOMP over WebSocket；

示例：

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config.enableSimpleBroker("/topic");
        config.setApplicationDestinationPrefixes("/app");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws")
                .setAllowedOriginPatterns("*")
                .withSockJS();
    }
}

@Controller
public class ChatController {

    @MessageMapping("/chat.send")
    @SendTo("/topic/messages")
    public ChatMessage send(ChatMessage message) {
        return message;
    }
}

前端通过 SockJS + Stomp 连接 /ws，订阅 /topic/messages 即可实现简单聊天。

5. 监控与链路追踪指标

音视频场景重点指标：

  1. 接口 QPS / RT：上麦/下麦/送礼物接口的每秒请求数和平均延迟；
  2. 错误率：5xx、超时比例；
  3. Redis/Kafka 连接数与延迟：防止缓存或 MQ 成为瓶颈；
  4. 房间在线用户数分布：监控超级大房间；
  5. WebSocket 连接数 & 断开率；
  6. 链路追踪：
    • 每个请求的 TraceId/SpanId；
    • 调用拓扑（gateway -> room-service -> user-service -> Redis/Kafka）。

使用 Micrometer + Prometheus 导出指标，Grafana 可视化；Jaeger/Zipkin 查看单个请求跨服务的耗时分布。

二、电商场景：分布式事务、持久化、缓存一致性、服务治理、安全

1. 电商下单与分布式事务

典型设计：最终一致性 / Saga 模式

  • 订单服务创建订单为“待支付/待确认”状态；
  • 调用库存服务预扣库存（失败则订单取消）；
  • 调用营销服务冻结优惠券；
  • 成功后通过 Kafka 通知物流服务；

常见方案：

  1. 本地消息表 + Kafka：

    • 本地事务：写订单表 + 消息表；
    • 定时任务扫描消息表，投递到 Kafka，消费成功后标记消息为成功；
    • 实现“事务消息 + 最终一致性”。

  2. Saga 模式（补偿事务）：

    • 每一步业务操作都有对应的“回滚”操作：
      • 库存预扣失败 -> 释放库存；
      • 优惠券冻结失败 -> 取消订单；
    • 通过编排（如工作流引擎）或业务代码实现状态流转。

不要做的事情：

  • 试图用一个 DB 事务覆盖所有服务（跨库分布式事务：重、复杂、易出问题）；
  • 在网络调用上依赖 2PC 之类的强一致协议（工程实践少，成本高）。
2. MyBatis 与 HikariCP

MyBatis vs JPA/Hibernate：

  • MyBatis：
    • SQL 手写，可控性强；
    • 适合复杂查询、对 SQL 性能敏感的业务；
  • JPA/Hibernate：
    • 以对象为中心，屏蔽 SQL，快速开发；
    • 对复杂多表查询可读性略差，调优门槛较高。

HikariCP 核心配置：

  • maximumPoolSize：最大连接数（影响吞吐与资源占用）；
  • minimumIdle：最小空闲连接数；
  • connectionTimeout：获取连接的超时时间；
  • idleTimeout：空闲连接被回收的时间；
  • maxLifetime：连接的最长存活时间，防止 DB 侧断开导致的僵尸连接。

影响性能最大的一般是 maximumPoolSize，但不能只看大或小，要结合：

  • 单机 QPS 目标；
  • 单机资源（CPU/内存）；
  • DB 可承载的最大连接数；
  • 业务 SQL 平均耗时。
3. Redis + Caffeine 本地缓存一致性

读路径设计：

  1. 先读本地 Caffeine：命中则直接返回；
  2. 未命中再读 Redis：
    • 命中则回填本地缓存；
  3. Redis 未命中再读 DB：
    • 查到后写 Redis + 本地缓存；
    • 未查到写“空值缓存”（短 TTL）防止穿透。

写（更新）路径：

  1. 写 DB 成功后：
    • 删除 Redis Key（或更新）；
    • 发布一条 缓存变更消息（Kafka/Redis PubSub）；
  2. 各应用节点订阅该消息：
    • 收到后失效本地 Caffeine 中对应 Key。

保证“尽量一致”的关键：

  • 不在多个节点上直接写本地缓存，而是由变更消息统一驱动；
  • 允许短暂不一致，设置合理 TTL；
  • 对价格等敏感字段，前端展示时可增加“强校验”（如支付前再次确认）。
4. Spring Cloud 服务治理

服务注册发现：

  1. 每个服务启动时向 Eureka 注册：
    • 上报服务名（serviceId）、IP、端口、健康检查地址；
  2. Eureka Server 保存服务实例列表；
  3. 调用方通过 Eureka Client 拉取注册表缓存；
  4. 使用负载均衡（如 LoadBalancer）选择实例发起调用（如 Feign）。

Resilience4j 熔断/限流/降级：

  • 通过注解或 AOP 包裹 Feign 调用：
@CircuitBreaker(name = "orderService", fallbackMethod = "fallback")
public OrderDTO getOrder(String id) { ... }
  • 当调用错误率或延迟超过阈值时，熔断器打开：
    • 快速失败，直接走 fallback；
    • 一段时间后尝试“半开”，恢复部分流量；
  • 可同时配置 重试、限流、隔离舱 等策略。
5. Spring Security + JWT

JWT 结构：

header.payload.signature

  • Header：算法、类型（如 HS256）；
  • Payload：用户 ID、角色、过期时间等；
  • Signature：HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)。

一次携带 JWT 的请求流程（简化）：

  1. 前端将 JWT 放在 Authorization: Bearer <token> 头中；
  2. Spring Security Filter 链中自定义 JwtAuthenticationFilter：
    • 解析 JWT，校验签名与过期时间；
    • 构造 Authentication 对象放入 SecurityContext；
  3. 后续 FilterSecurityInterceptor 根据 SecurityContext 做鉴权（@PreAuthorize, @Secured 等）。

需要注意：

  • JWT 一旦签发，一般无法撤销，所以：
    • 重要操作建议做“二次校验”（如短信/口令）；
    • 可以引入“黑名单表”配合 token ID 实现主动注销。

三、AI 智能客服 & RAG：向量检索、Agent、工具调用、幻觉控制

1. RAG（检索增强生成）请求流程

典型 RAG 流程：

  1. 用户问题 -> 向量化：
    • 使用 Embedding 模型（OpenAI / Ollama / 自研）把问题转成向量；
  2. 向量检索：
    • 在 Milvus / Redis / Chroma 等向量库里搜最相似的文档片段；
  3. 构造 Prompt：
    • 把检索到的文档 + 用户问题封装成提示词，告诉大模型“只能基于这些资料回答”；
  4. 调用大模型生成回答；
  5. 后处理：
    • 敏感词过滤、字段抽取、结构化输出等。

为什么更适合企业问答：

  • 可以使用 企业内网文档 做知识源，而非仅依赖模型固有知识；
  • 文档可控、可更新，便于合规（删改知识库即可）；
  • 回答可附带“引用来源”，增强可解释性；
  • 更容易控制成本（只在需要时调用模型）。
2. 向量化与语义检索 vs 关键词检索

向量化与语义检索：

  • 把文本映射为高维向量（如 768 维）；
  • 相似语义会聚集在向量空间邻近位置；
  • 查询时同样把问题向量化，再用 余弦相似度 / 向量距离 去最近邻搜索（ANN）。

相比关键词检索（如 Elasticsearch）的优势：

  • 能识别 同义词/语义相似（“退款”和“退货”）；
  • 对于短文本和口语化提问效果更好；
  • 不需要复杂构造关键词和 bool 查询。

不足：

  • 资源消耗高，对 CPU/GPU 和内存要求更大；
  • 更新成本：向量需要重算和重新写入；
  • 很长文档仍需要切片、归一化等预处理。

实际工程中常用 “向量检索 + 关键词检索” 融合 来互补。

3. Agent 与工具调用框架设计

功能需求：

  • 根据用户意图，自动选择调用哪一个或哪几个“工具”；
  • 工具可以是 Java 服务方法、HTTP API、数据库查询等；
  • 需要易扩展、易监控、易调试。

关键设计点：

  1. 工具抽象：
    • 一个统一的接口，如：
public interface AiTool {
    String getName();
    ToolResult invoke(Map<String, Object> params);
}

  1. 工具注册中心：

    • 支持按名称/标签查找工具；
    • 支持动态增加工具（Spring Bean 扫描）。

  2. 调用协议标准化：

    • 输入输出以 JSON / Map 表示，便于大模型理解和填充；

  3. 调用链路监控：

    • 记录每个工具调用耗时、成功率、错误原因；

  4. 组合执行：

    • 支持串行/并行工具调用；
    • 依赖关系可通过简单的 DSL 或工作流描述；

  5. 安全控制：

    • 工具访问权限控制（不能让客服随便调“删库工具”）。

Spring AI、LangChain4j 等框架都在做这些事情，Java 侧可以基于它们封装自己的工具系统。

4. 减少 AI 幻觉的技术手段

结合 RAG，可以：

  1. 限制回答来源：
    • Prompt 中明确说明“只能根据给定文档回答；如果没有相关信息，请回答不知道”；
  2. 严格检索过滤：
    • 对检索相似度设置阈值，低于阈值则不使用该文档；
  3. 答案校验：
    • 对关键信息（价格、规则）再做结构化校验，如与规则服务对比；
  4. 输出模板化：
    • 对重要业务流程（退款规则等）采用“结构化回应模板”，减少自由发挥空间；
  5. 用户提示：
    • 在 UI 层展示“规则版本号”和“来源文档”，用户可自行查看。
5. RAG 请求的日志与可观测性

建议记录字段：

  1. 请求级：TraceId、用户 ID、会话 ID、时间戳；
  2. 输入：用户原始问题（脱敏后的）；
  3. 检索：
    • 检索到的文档 ID、title、相似度分数；
    • 是否命中 & 使用了多少条；
  4. 模型调用：
    • 模型名称、版本、温度参数；
    • token 数量（prompt / completion）、费用估算；
    • 耗时、错误码；
  5. 输出：模型原始回答、后处理后的回答；
  6. 异常：
    • 超时、网络错误、解析错误等。

这些日志可以打到 ELK 或新贵如 OpenSearch 中，结合 Prometheus 指标（QPS/RT/错误率/费用）构建一个完整的可观测性体系。

小结

通过这场“严肃面试官 vs 搞笑水货程序员小Y”的对话，我们串起来了：

  • 音视频场景：线程池、Redis 缓存、Kafka、WebSocket、监控与链路追踪；
  • 电商场景：分布式事务、MyBatis + HikariCP、Redis + Caffeine 缓存一致性、Spring Cloud 服务治理、Spring Security + JWT；
  • AI 智能客服：RAG 架构、向量检索、Agent 工具调用框架、AI 幻觉控制、日志与可观测性。

你可以把这些问题当作一份“大厂 Java 面试清单”，逐个补齐知识点，也可以结合自己的项目做一次架构复盘。下次再遇到类似场景时，希望你能比小Y回答得更清晰、更专业。

# 微服务 # RAG
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

OpenClaw 依赖的 LiteLLM 被投毒

avatar AtomGit开源社区
cover

大模型落地必看：训练跑通≠上线！揭秘推理系统架构与成本优化秘籍，告别高延迟与低利用率

avatar AtomGit开源社区
cover

AI智能体实战：从入门到企业级自动化应用

avatar AtomGit开源社区