AI 后端中间件（MySQL / Redis / Kafka）

为什么这是必备项

岗位追问常常是：“你不只是调模型，任务怎么落库、怎么重试、怎么不重复扣费、Redis 挂了怎么办？”
本课把中间件补到可画架构、可写表结构、可讲故障。

课程目标

MySQL：任务状态、审计、账单类事实数据的表设计与索引意识。
Redis：缓存、分布式锁、限流计数、幂等窗口、会话态；降级思路。
Kafka/MQ：异步长任务、削峰、重试、死信；与数据库状态机配合。
一致性叙事：至少掌握“最终一致 + 可补偿”在 AI 场景里的讲法。

认知地图

客户端 → API →（同步短路径 | 异步投递 MQ）
                    ↓
            Worker 消费 → 调模型/工具链 → 更新 MySQL 状态
                    ↓
            Redis：幂等、限流、热点缓存、短 TTL 结果

12 天学习路径

Day1~2：MySQL 任务表设计

学习目标：一张表讲清 AI 长任务生命周期。
任务：设计 ai_task（或你命名的表），字段至少包含：
task_id, user_id, status, progress, input_ref, output_ref, error_code, retry_count, trace_id, created_at, updated_at, idempotency_key, cost_tokens
验收：能解释每个字段在排障时的用途；给出 status 枚举与合法迁移。

Day3：索引与查询模式

任务：为 user_id + created_at、status + updated_at 设计索引；写 2 条慢查询优化思路。
验收：能说清“为什么 AI 任务列表页容易扫大表”。

Day4~5：Redis 核心用法

学习目标：缓存、锁、限流、幂等四件事各举一个 AI 场景。
任务：
- 用 Redis 实现 user_id + request_hash 幂等（TTL 与冲突返回策略）。
- 用简单计数器或 token bucket 做 API 限流原型。
验收：Redis 不可用时的降级策略（同步失败提示 / 只读缓存 / 关特性）写进文档。

Day6：分布式锁与误用

任务：说明 AI 场景里哪些操作需要锁（同一 conversation_id 并发写）。
验收：能讲锁超时、误删、续期问题。

Day7~8：Kafka/MQ 语义

学习目标：至少一次、至多一次、精确一次在工程里的真实含义。
任务：画出：生产 → broker → 消费 → 写库的顺序；标出可能重复消费的点。
验收：口述“如何用幂等消费 + 状态机消化重复”。

Day9：死信与重试

任务：定义重试次数、指数退避、进入 DLQ 的条件；DLQ 人工处理流程。
验收：给出一个“模型供应商 429”时的重试策略表。

Day10：可观测字段

任务：统一 trace_id 从 API 贯穿到 MQ 消费与模型调用日志。
验收：给你一条 task_id，能说明要从哪些存储查链路。

Day11：迷你综合案例

任务：生成报告异步任务：提交 → 返回 task_id → 轮询或 WebSocket 推送（可先 mock）。
验收：重启 worker 后任务可恢复或可被检测为卡住（stale 状态）。

Day12：面试稿

任务：5 分钟讲述：MySQL/Redis/MQ 分工 + 一次线上故障复盘（可模拟）。
验收：包含指标（堆积、失败率、P95）。

面试高频（带答题骨架）

MySQL 与 Redis 怎么分工？
事实与状态以 MySQL 为准；Redis 做加速与短期互斥；允许缓存过期后回源。
MQ 如何保证不丢不重不乱？
生产确认、消费确认、幂等键、有序分区（若需要）、死信与人工介入。
任务状态表最少字段？
身份、状态、重试、错误、追踪、幂等、成本与时间戳。

常见陷阱

把“生成结果”只放 Redis，没有持久真相源。
消费端不做幂等，靠“应该不会重试”侥幸心理。
status 随意字符串，无法做监控与告警。

实操验收

ai_task 表结构说明 + 状态机图
Redis 幂等键设计文档
MQ + worker 时序与重试表

深度专题：AI 多租户、权限与审计

为什么抽出这一节：AI 应用市场从 2025 开始大量 B2B 落地，多租户隔离 + 审计成为招标硬指标，但大多候选人只会写普通后端的权限。

1. 隔离策略的三种做法

层	方案	强度	适用
数据库	独立数据库每租户一套	最高	大客户 / 合规
Schema	共享实例各 schema	中	中型 SaaS
Row-level	共享表，所有查询带 `tenant_id` + RLS	基础	初期 / 小客户

Postgres RLS 是性价比最高的选择：

ALTER TABLE ai_task ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_iso ON ai_task
  USING (tenant_id = current_setting('app.tid')::uuid);

向量库：Chroma 按 collection，Milvus 按 partition，Qdrant 按 group_id（如不能，至少 filter 强制过滤）。
Redis：key 前缀 t:{tid}:...，容量配额单独统计；避免共用 SCAN。

2. 权限模型：RBAC + ABAC + Scope

User → Role(客服/分析师/管理员) → Scope(行为权限) → Tool 白名单
                              + Attr(tenant, dept, pii_level)

Scope 命名：read:doc, write:order, invoke:refund，和 ai-application-security 一致。
工具白名单：模型看到的 tool 列表 = tools ∩ user.scopes，模型根本看不到越权工具。
ABAC：行级过滤，如客服只能看自己部门工单。

3. 密钥与供应商密钥隔离

按租户 API Key：支持用户“自带模型”（BYOK），计费上也更清楚。
托管：HashiCorp Vault / AWS KMS / 阿里 KMS；程序启动时获取并缓存，定时轮换。
绝不：把 key 写入 prompt / log / trace；统一 redact_secret() 中间件。

4. 配额与计费

各租户两条线：软限（预警）+ 硬限（打回）。

# Redis 记 token 和 cost
key_tok = f"t:{tid}:tok:{today}"
key_usd = f"t:{tid}:usd:{today}"
pipe.incrby(key_tok, tokens)
pipe.incrbyfloat(key_usd, cost)
pipe.expire(key_tok, 86400 * 35)

实时账单导出到 MySQL ai_bill，支持分模型 / 功能粒度。
缓存命中成本按供应商、模型与缓存路径的实际计费规则入账，不在代码里写死“免费/半价”。

5. 审计日志（合规级）

必录字段：

audit_id, trace_id, ts, tenant, user, role, action,
resource, scope, input_hash, output_hash, risk_flags[],
ip, user_agent, approval_ref, result, cost_usd

写 WORM 存储（不可篡改）：S3 Object Lock / 阿里 OSS 归档锁定。
180 天只能作为企业示例。实际期限按处理目的所需的最短时间、合同、适用法域、行业义务与 legal hold 确定。
用户删除请求：级联处理 MySQL 业务表、Redis 会话、向量库 chunk、checkpoint 与备份生命周期；需要保留的最小审计元数据必须有独立依据和访问控制。

6. 工具调用的审计链

用户 → 网关（trace_id 生成）
     → LLM（模型决定调 delete_user）
     → Tool 层（权限校验 → 需审批）
     → interrupt 暂停（写 checkpoint + 推送审批）
     → 主管点击通过 → resume
     → Tool 实际执行 → 写 audit + 审批 ref

每步写一行；任何一步失败，都能用 trace_id 回放。这套是 agent-state-persistence-hitl 中 HITL 的必配。

7. 爆炸半径与故障隔离

限流桶：单租户单接口配额；阻止单租户出事吃掉其他人 QoS。
模型供应商断路：OpenAI 503 时自动切到 Anthropic/通义；带 fallback=true 标记。
资源运行域：K8s namespace + resourceQuota 按租户或按业务线隔离。

8. 面试高频追问（深度版）

Postgres RLS 有什么坑？ — current_setting 未设置可能导致串租户数据；必须在连接初始化时写入，并在 test fixture 中覆盖此场景。
向量库怎么隔离才算安全？ — 最强：物理 collection；次强：服务端强制 metadata filter + 单元测试覆盖。不推荐让 LLM 填写 filter。
怎么给模型供应商那边实现隔离？ — 按租户拆开 API Key，或一个 Key 搭配 user 字段计数。
删除请求下审计怎么留？ — 具体内容脱敏，保留元数据（trace_id、action）满足合规与删除请求并存。
多租户下的缓存挑战？ — key 带 tenant；严禁全局 prompt cache 跨租户。
如何检测跨租户泄漏？ — CI 里跑两个租户并行测试，对后端每个接口验证能访问本租户数据、不能访问其他租户数据。
配额超支怎么处理？ — 软限告警 + 硬限 429；配合 graceful degrade（降模型 / 关高级功能）而不是直接报错。

9. 可交付产物（深度升级）

schema/multi-tenant-rls.sql
middleware/tenant_context.py（统一注入 tid）
libs/quota.py（软/硬限）
docs/audit-log-spec.md
tests/security/cross-tenant.py

与 ai-application-security、agent-state-persistence-hitl、backend-system-design-for-ai 互补。

为什么这是必备项

课程目标

MySQL：任务状态、审计、账单类事实数据的表设计与索引意识。
Redis：缓存、分布式锁、限流计数、幂等窗口、会话态；降级思路。
Kafka/MQ：异步长任务、削峰、重试、死信；与数据库状态机配合。
一致性叙事：至少掌握“最终一致 + 可补偿”在 AI 场景里的讲法。

认知地图

客户端 → API →（同步短路径 | 异步投递 MQ）
                    ↓
            Worker 消费 → 调模型/工具链 → 更新 MySQL 状态
                    ↓
            Redis：幂等、限流、热点缓存、短 TTL 结果

12 天学习路径

Day1~2：MySQL 任务表设计

学习目标：一张表讲清 AI 长任务生命周期。
任务：设计 ai_task（或你命名的表），字段至少包含：
task_id, user_id, status, progress, input_ref, output_ref, error_code, retry_count, trace_id, created_at, updated_at, idempotency_key, cost_tokens
验收：能解释每个字段在排障时的用途；给出 status 枚举与合法迁移。

Day3：索引与查询模式

任务：为 user_id + created_at、status + updated_at 设计索引；写 2 条慢查询优化思路。
验收：能说清“为什么 AI 任务列表页容易扫大表”。

Day4~5：Redis 核心用法

学习目标：缓存、锁、限流、幂等四件事各举一个 AI 场景。
任务：
- 用 Redis 实现 user_id + request_hash 幂等（TTL 与冲突返回策略）。
- 用简单计数器或 token bucket 做 API 限流原型。
验收：Redis 不可用时的降级策略（同步失败提示 / 只读缓存 / 关特性）写进文档。

Day6：分布式锁与误用

任务：说明 AI 场景里哪些操作需要锁（同一 conversation_id 并发写）。
验收：能讲锁超时、误删、续期问题。

Day7~8：Kafka/MQ 语义

学习目标：至少一次、至多一次、精确一次在工程里的真实含义。
任务：画出：生产 → broker → 消费 → 写库的顺序；标出可能重复消费的点。
验收：口述“如何用幂等消费 + 状态机消化重复”。

Day9：死信与重试

任务：定义重试次数、指数退避、进入 DLQ 的条件；DLQ 人工处理流程。
验收：给出一个“模型供应商 429”时的重试策略表。

Day10：可观测字段

任务：统一 trace_id 从 API 贯穿到 MQ 消费与模型调用日志。
验收：给你一条 task_id，能说明要从哪些存储查链路。

Day11：迷你综合案例

任务：生成报告异步任务：提交 → 返回 task_id → 轮询或 WebSocket 推送（可先 mock）。
验收：重启 worker 后任务可恢复或可被检测为卡住（stale 状态）。

Day12：面试稿

任务：5 分钟讲述：MySQL/Redis/MQ 分工 + 一次线上故障复盘（可模拟）。
验收：包含指标（堆积、失败率、P95）。

面试高频（带答题骨架）

MySQL 与 Redis 怎么分工？
事实与状态以 MySQL 为准；Redis 做加速与短期互斥；允许缓存过期后回源。
MQ 如何保证不丢不重不乱？
生产确认、消费确认、幂等键、有序分区（若需要）、死信与人工介入。
任务状态表最少字段？
身份、状态、重试、错误、追踪、幂等、成本与时间戳。

常见陷阱

把“生成结果”只放 Redis，没有持久真相源。
消费端不做幂等，靠“应该不会重试”侥幸心理。
status 随意字符串，无法做监控与告警。

实操验收

ai_task 表结构说明 + 状态机图
Redis 幂等键设计文档
MQ + worker 时序与重试表

深度专题：AI 多租户、权限与审计

为什么抽出这一节：AI 应用市场从 2025 开始大量 B2B 落地，多租户隔离 + 审计成为招标硬指标，但大多候选人只会写普通后端的权限。

1. 隔离策略的三种做法

层	方案	强度	适用
数据库	独立数据库每租户一套	最高	大客户 / 合规
Schema	共享实例各 schema	中	中型 SaaS
Row-level	共享表，所有查询带 `tenant_id` + RLS	基础	初期 / 小客户

Postgres RLS 是性价比最高的选择：

ALTER TABLE ai_task ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_iso ON ai_task
  USING (tenant_id = current_setting('app.tid')::uuid);

向量库：Chroma 按 collection，Milvus 按 partition，Qdrant 按 group_id（如不能，至少 filter 强制过滤）。
Redis：key 前缀 t:{tid}:...，容量配额单独统计；避免共用 SCAN。

2. 权限模型：RBAC + ABAC + Scope

User → Role(客服/分析师/管理员) → Scope(行为权限) → Tool 白名单
                              + Attr(tenant, dept, pii_level)

Scope 命名：read:doc, write:order, invoke:refund，和 ai-application-security 一致。
工具白名单：模型看到的 tool 列表 = tools ∩ user.scopes，模型根本看不到越权工具。
ABAC：行级过滤，如客服只能看自己部门工单。

3. 密钥与供应商密钥隔离

按租户 API Key：支持用户“自带模型”（BYOK），计费上也更清楚。
托管：HashiCorp Vault / AWS KMS / 阿里 KMS；程序启动时获取并缓存，定时轮换。
绝不：把 key 写入 prompt / log / trace；统一 redact_secret() 中间件。

4. 配额与计费

各租户两条线：软限（预警）+ 硬限（打回）。

# Redis 记 token 和 cost
key_tok = f"t:{tid}:tok:{today}"
key_usd = f"t:{tid}:usd:{today}"
pipe.incrby(key_tok, tokens)
pipe.incrbyfloat(key_usd, cost)
pipe.expire(key_tok, 86400 * 35)

实时账单导出到 MySQL ai_bill，支持分模型 / 功能粒度。
缓存命中成本按供应商、模型与缓存路径的实际计费规则入账，不在代码里写死“免费/半价”。

5. 审计日志（合规级）

必录字段：

audit_id, trace_id, ts, tenant, user, role, action,
resource, scope, input_hash, output_hash, risk_flags[],
ip, user_agent, approval_ref, result, cost_usd

写 WORM 存储（不可篡改）：S3 Object Lock / 阿里 OSS 归档锁定。
180 天只能作为企业示例。实际期限按处理目的所需的最短时间、合同、适用法域、行业义务与 legal hold 确定。
用户删除请求：级联处理 MySQL 业务表、Redis 会话、向量库 chunk、checkpoint 与备份生命周期；需要保留的最小审计元数据必须有独立依据和访问控制。

6. 工具调用的审计链

用户 → 网关（trace_id 生成）
     → LLM（模型决定调 delete_user）
     → Tool 层（权限校验 → 需审批）
     → interrupt 暂停（写 checkpoint + 推送审批）
     → 主管点击通过 → resume
     → Tool 实际执行 → 写 audit + 审批 ref

每步写一行；任何一步失败，都能用 trace_id 回放。这套是 agent-state-persistence-hitl 中 HITL 的必配。

7. 爆炸半径与故障隔离

限流桶：单租户单接口配额；阻止单租户出事吃掉其他人 QoS。
模型供应商断路：OpenAI 503 时自动切到 Anthropic/通义；带 fallback=true 标记。
资源运行域：K8s namespace + resourceQuota 按租户或按业务线隔离。

8. 面试高频追问（深度版）

Postgres RLS 有什么坑？ — current_setting 未设置可能导致串租户数据；必须在连接初始化时写入，并在 test fixture 中覆盖此场景。
向量库怎么隔离才算安全？ — 最强：物理 collection；次强：服务端强制 metadata filter + 单元测试覆盖。不推荐让 LLM 填写 filter。
怎么给模型供应商那边实现隔离？ — 按租户拆开 API Key，或一个 Key 搭配 user 字段计数。
删除请求下审计怎么留？ — 具体内容脱敏，保留元数据（trace_id、action）满足合规与删除请求并存。
多租户下的缓存挑战？ — key 带 tenant；严禁全局 prompt cache 跨租户。
如何检测跨租户泄漏？ — CI 里跑两个租户并行测试，对后端每个接口验证能访问本租户数据、不能访问其他租户数据。
配额超支怎么处理？ — 软限告警 + 硬限 429；配合 graceful degrade（降模型 / 关高级功能）而不是直接报错。

9. 可交付产物（深度升级）

schema/multi-tenant-rls.sql
middleware/tenant_context.py（统一注入 tid）
libs/quota.py（软/硬限）
docs/audit-log-spec.md
tests/security/cross-tenant.py

与 ai-application-security、agent-state-persistence-hitl、backend-system-design-for-ai 互补。

学完这篇你应该拿到什么

3 个高频追问

1 个证据

沉淀表达

面试时怎么讲

简历一句话

为什么这是必备项

课程目标

认知地图

12 天学习路径

Day1~2：MySQL 任务表设计

Day3：索引与查询模式

Day4~5：Redis 核心用法

Day6：分布式锁与误用

Day7~8：Kafka/MQ 语义

Day9：死信与重试

Day10：可观测字段

Day11：迷你综合案例

Day12：面试稿

面试高频（带答题骨架）

常见陷阱

实操验收

深度专题：AI 多租户、权限与审计

1. 隔离策略的三种做法

2. 权限模型：RBAC + ABAC + Scope

3. 密钥与供应商密钥隔离

4. 配额与计费

5. 审计日志（合规级）

6. 工具调用的审计链

7. 爆炸半径与故障隔离

8. 面试高频追问（深度版）

9. 可交付产物（深度升级）

最新资料（2026-05 校验）

学完这篇你应该拿到什么

3 个高频追问

1 个证据

沉淀表达

面试时怎么讲

简历一句话

为什么这是必备项

课程目标

认知地图

12 天学习路径

Day1~2：MySQL 任务表设计

Day3：索引与查询模式

Day4~5：Redis 核心用法

Day6：分布式锁与误用

Day7~8：Kafka/MQ 语义

Day9：死信与重试

Day10：可观测字段

Day11：迷你综合案例

Day12：面试稿

面试高频（带答题骨架）

常见陷阱

实操验收

深度专题：AI 多租户、权限与审计

1. 隔离策略的三种做法

2. 权限模型：RBAC + ABAC + Scope

3. 密钥与供应商密钥隔离

4. 配额与计费

5. 审计日志（合规级）

6. 工具调用的审计链

7. 爆炸半径与故障隔离

8. 面试高频追问（深度版）

9. 可交付产物（深度升级）

最新资料（2026-05 校验）