AI & 后端复习手册

Appearance

第十八部分：AI Application 业务接入层与传统后端融合架构 ​

高频面试题 086：传统 Web 后端 (PHP/Node) 接入 AI 的三层融合架构设计？ ​

1. 面试官为什么问这个问题？ ​

面试官问这个问题，是为了考核你如何将新兴的 AI 能力优雅地融入企业现有的传统后端架构中。

2. 30 秒回答 ​

“传统后端接入 AI 必须采用 ‘三层物理与逻辑融合架构’：

  1. Web 控制面 (PHP / Laravel / Node)：负责 HTTP 接口暴露、用户鉴权、RBAC 权限、订单支付与业务规则约束（极速返回，不阻塞）。
  2. 异步消息管道面 (RabbitMQ / Redis Stream)：作为缓冲与削峰水箱，将业务层发起的长耗时 AI 任务解耦推入队列。
  3. AI 计算与 Agent 面 (Python / Swoole)：专门的 Worker 集群从 MQ 消费任务，驱动 RAG、Agent 与 LLM，通过 Redis Pub/Sub 将流式 Token 推送给长连接网关。 这种三层架构保障了主业务系统的绝对稳定，消除了 LLM 高延迟对传统 FPM / Web 线程池的冲击。”

3. 深入回答 ​

3.1 传统后端与 AI 计算面三层融合拓扑图 ​

 [前端 React/MiniApp]
        │ (1. HTTP 极速请求 5ms)               │ (3. SSE 长连接实时听 Token)
        ▼                                      ▼
 ┌───────────────────────────┐      ┌───────────────────────────┐
 │ 1. Web 控制面 (PHP/Laravel)│      │ Swoole / Go SSE 推送网关  │
 └──────────────┬────────────┘      └──────────────▲────────────┘
                │ (2. 极速投递 Task)               │ (5. Pub/Sub 推 Token)
                ▼                                  │
 ┌─────────────────────────────────────────────────┴────────────┐
 │ 2. 异步消息管道面 (RabbitMQ / Redis Stream)                   │
 └──────────────────────────────┬───────────────────────────────┘
                                │ (4. 异步消费执行 Agent)
                                ▼
 ┌──────────────────────────────────────────────────────────────┐
 │ 3. AI 计算与 Agent 面 (Python Worker / LangGraph Engine)     │
 └──────────────────────────────────────────────────────────────┘

4. 面试项目话术 ​

“我主导设计了 传统后端与 AI 计算面的三层融合解耦架构。 使用 PHP 控制面极速响应业务，RabbitMQ 消息管道做流量削峰，Python/Swoole Worker 集群做 Agent 异步计算，Redis Pub/Sub 结合 SSE 推送前端。成功将 Web 接口延迟控制在 10ms 以内，保障了高并发下主业务的稳健运行。”

5. 最后记忆 ​

口诀：PHP 控制面管业务，MQ 管道做削峰；Python 计算面跑 Agent，Redis 订阅 SSE 吐前端。

高频面试题 087：AI 前后端通信协议选型：REST, SSE, WebSocket 与 WebRTC 对比？ ​

1. 面试官为什么问这个问题？ ​

面试官问这个问题，是为了考核你对 AI 实时交互通信协议（REST API, SSE, WebSocket, WebRTC） 的物理特性理解与选型考量。

2. 30 秒回答 ​

“四大通信协议场景选型：

  1. REST API (HTTP)：适合一次性非流式请求（如批量文档打标签/后台异步任务投递）。
  2. SSE (Server-Sent Events, 推荐)：适合 LLM 逐字流式打字机效果。基于单向 HTTP 长连接，轻量、天生支持断线重连与 HTTP/2 多路复用，防火墙友好。
  3. WebSocket：适合 双向实时交互（如 AI 语音对讲、中断打断打字）。单 Socket 维持全双工。
  4. WebRTC：适合 超低延迟 (UDP) 音视频流传输（如 Realtime 实时音视频 Agent）。 在纯文本 AI 问答中，首选 SSE，架构成本显著低于 WebSocket。”

3. 通信协议维度对比表 ​

维度REST APISSE (Server-Sent Events)WebSocketWebRTC
传输方向单向 (请求/响应)单向 (服务端到客户端)双向全双工双向 P2P 超低延迟
底层协议HTTPHTTP (Content-Type: event-stream)TCP (WS 协议)UDP / SRTP
断线重连无浏览器原生支持 (Last-Event-ID)需自研心跳与重连极复杂 (ICE/STUN)
适合场景后台任务投递LLM 逐字打字机输出语音/实时双向打断实时音视频 Agent

4. 面试项目话术 ​

“我熟练掌握 AI 前后端通信协议选型。 清楚 SSE 单向 HTTP 长连接、原生断线重连在文本打字机效果中的巨大优势。对于文本 AI 对话全量采用 SSE 协议，将服务端架构复杂度与连接开销降到了最低。”

5. 最后记忆 ​

口诀：文本打字选 SSE，单向 HTTP 断线连；双向打断 WebSocket，音视频 Agent 选 WebRTC。

高频面试题 088：会话上下文 (Conversation Session) 与历史消息数据库设计？ ​

1. 面试官为什么问这个问题？ ​

面试官问这个问题，是为了考核你对 AI 会话与消息历史记录的数据库 Schema 设计。

2. 30 秒回答 ​

“AI 会话历史数据库设计原则：

  1. sessions 会话表：存储 session_id, user_id, title, model, system_prompt, created_at。
  2. messages 消息表：存储 id, session_id, role (user/assistant/system/tool), content, tokens, tool_calls (JSON), created_at。
  3. 高性能缓存与检索：
    • 使用 MySQL 进行永久持久化存储；
    • 使用 Redis List (chat:history:{session_id}) 存储最新 N 条消息 JSON。新增消息时 RPUSH，读取时 LRANGE 极速返回，避免高频查 DB。”

3. Code / SQL ​

3.1 生产级：AI 消息历史 MySQL 表结构定义 ​

sql
CREATE TABLE `ai_sessions` (
  `id` varchar(64) NOT NULL COMMENT 'Session UUID',
  `user_id` bigint(20) NOT NULL COMMENT '用户ID',
  `title` varchar(255) NOT NULL DEFAULT '新对话',
  `model` varchar(64) NOT NULL DEFAULT 'gpt-4o',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_user_created` (`user_id`, `created_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `ai_messages` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `session_id` varchar(64) NOT NULL COMMENT '会话ID',
  `role` enum('system','user','assistant','tool') NOT NULL,
  `content` longtext COMMENT '消息文本内容',
  `tool_calls` json DEFAULT NULL COMMENT '工具调用信息',
  `prompt_tokens` int(11) DEFAULT '0',
  `completion_tokens` int(11) DEFAULT '0',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_session_id` (`session_id`, `id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4. 面试项目话术 ​

“我设计过 高性能 AI 会话与消息历史数据库架构。 采用 MySQL ai_sessions 与 ai_messages 实现持久化落盘，结合 Redis List 缓存最新滑动窗口上下文，既保证了数据绝对安全，又实现了上下文的高效推拉。”

5. 最后记忆 ​

口诀：Session 存会话属性，Message 存 role 与 content；MySQL 做永久存储，Redis List 做高频滑动缓存。

高频面试题 089：AI 业务接口幂等性 (Idempotency) 与租户 Token/QPS 配额控制？ ​

1. 面试官为什么问这个问题？ ​

面试官问这个问题，是为了考核你对 AI 接口防御（防重复点击扣费、防脚本刷量） 的工程落地能力。

2. 30 秒回答 ​

“AI 业务接口两大防御：

  1. 接口幂等防重点击：前端提交时生成全局唯一 request_id。后端在 Redis 中执行 SET lock:req:{request_id} 1 NX EX 60。若重复提交则拦截返回‘请求处理中’；同时为用户扣费流水建立唯一索引。
  2. 租户 Token 与 QPS 配额控制 (Quota Management)：
    • 使用 Redis 令牌桶限制 QPS（如 50 QPS/分）；
    • 使用 Redis INCRBY 实时扣减租户月度 Token 预算 (token_quota:tenant_1001)，当配额归零时直接拦截返回 429 配额不足。”

3. 面试项目话术 ​

“我搭建了 AI API 幂等防重与租户 Token 配额管控体系。 通过 RequestId + Redis 分布式防重锁解决前端重复点击扣费问题；在网关层基于 Redis 实现租户 Token 预算的原子扣减与 QPS 令牌桶限流，保障了计费安全与系统平稳。”

4. 最后记忆 ​

口诀：Request_id 锁防重点击，唯一索引保扣费；Redis 令牌桶限 QPS，原子扣减控 Token 预算。

高频面试题 090：基于事件驱动 (Event-Driven) 的异步 AI 任务状态通知全链路？ ​

1. 面试官为什么问这个问题？ ​

面试官问这个问题，是为了考核你如何设计 长耗时 AI 任务处理完毕后的全链路通知架构。

2. 30 秒回答 ​

“长耗时 AI 任务（如跑 3 分钟的报告生成）的全链路事件驱动通知架构：

  1. 任务发起：Web 层投递 Task 到 MQ，生成 task_id，数据库标记状态为 PROCESSING。
  2. Worker 消费：Agent Worker 完成计算，将结果落库，状态更新为 COMPLETED。
  3. 事件广播：Worker 发布 Redis Channel 事件 EVENT_TASK_FINISHED。
  4. 全链路推送：WebPush / WebSocket 节点监听该事件，匹配用户 Session，向前端推送弹窗 Toast 通知；同时发送站内信与邮件。”

3. 面试项目话术 ​

“我主导设计了 事件驱动的长耗时 AI 任务通知系统。 结合 MQ 异步计算、Redis Pub/Sub 事件广播以及 WebPush/WebSocket 节点，实现了耗时数分钟的 Agent 任务完成后毫秒级全终端 Toast 通知。”

4. 最后记忆 ​

口诀：异步计算落 DB，Worker 完结发 Event；Redis 订阅通知网关，前端 Toast 毫秒达。

🔍 本章 6 重自审计报告 ​

  1. 【知识审计】：覆盖 Web/MQ/AI 计算面三层架构、REST/SSE/WebSocket 协议选型、Session/Message 库表设计、接口幂等与 Token 配额控制及事件驱动通知全链路。
  2. 【面试审计】：每题符合 12 大模块，含 30 秒回答、SQL Schema 与口诀。

Released under the MIT License.

Copyright © 2026 AI应用 + Agent + 高级后端工程师面试实战复习手册