1. AIGC 异步回调系统架构解析
在AIGC(AI生成内容)领域,视频生成、图片生成等任务通常需要较长的处理时间。传统的同步请求方式会导致客户端长时间等待,严重影响用户体验。我们设计了一套通用的异步回调系统架构,完美解决了这个问题。
1.1 系统核心优势
这套架构具有以下显著特点:
- 即时响应:接收请求后立即返回task_id,不阻塞客户端
- 状态追踪:通过数据库完整记录任务生命周期
- 智能回调:任务完成后自动通知业务后端
- 统一管理:一套架构支持多种AIGC业务类型
- 全链路监控:完整的时间戳记录,便于问题排查
1.2 典型应用场景
这套系统特别适合以下场景:
- 视频生成(1-10分钟处理时间)
- 高清图片生成(30秒-2分钟)
- 3D模型渲染(5-30分钟)
- 语音合成(1-3分钟)
2. 系统架构设计
2.1 整体架构分层
系统采用经典的分层架构设计:
code复制┌───────────────────────┐
│ API层 │ ← 接收HTTP请求/响应
├───────────────────────┤
│ 业务逻辑层 │ ← 核心处理逻辑
├───────────────────────┤
│ 数据层 │ ← 数据持久化
├───────────────────────┤
│ 外部服务集成 │ ← 对接AIGC供应商
├───────────────────────┤
│ 工具层 │ ← 通用功能组件
└───────────────────────┘
2.2 核心组件说明
2.2.1 回调统一入口
作为系统的"前门",负责:
- 接收所有供应商的回调请求
- 解析不同格式的回调数据
- 路由到对应的业务处理器
python复制@router.post("/callback")
async def handle_callback(request: Request):
# 支持多种TaskId提取方式
task_id = (data.get("TaskId") or
data.get("task_id") or
data.get("req_id") or
data.get("Event", {}).get("TaskId"))
# 数据库查询
task = await db.get_by_model_task_id(task_id)
# 路由到处理器
handler = Dispatcher.get_handler(task.business_type)
await handler.process_callback(task, data)
2.2.2 处理器分发器
采用策略模式实现业务路由:
python复制class CallbackDispatcher:
_handlers = {} # 处理器注册表
@classmethod
def register(cls, business_type: str, handler_class: Type):
"""注册处理器"""
cls._handlers[business_type] = handler_class
@classmethod
def get_handler(cls, business_type: str):
"""获取处理器实例"""
return cls._handlers[business_type]()
2.2.3 处理器基类
定义标准处理流程模板:
python复制class BaseCallbackHandler(ABC):
async def process_callback(self, task: Task, data: dict):
# 1. 提取结果URL
url = self.extract_result_url(data)
# 2. 上传到存储
storage_url = await self.upload_to_storage(url)
# 3. 更新数据库
await db.update_storage_uploaded(task.model_task_id, storage_url)
# 4. 检查并通知
await self.check_and_notify(task.task_id)
3. 核心业务流程
3.1 任务提交流程
- 客户端发起异步请求
- 系统生成唯一task_id
- 提交任务到AIGC供应商
- 立即返回task_id给客户端
- 记录任务初始状态到数据库
mermaid复制sequenceDiagram
participant Client
participant System
participant Vendor
participant DB
Client->>System: POST /api/async (with callback_url)
System->>DB: 记录任务(状态=pending)
System->>Vendor: 提交生成任务
Vendor-->>System: 返回vendor_task_id
System->>DB: 更新vendor_task_id
System-->>Client: 202 Accepted (with task_id)
3.2 回调处理流程
- AIGC供应商回调系统
- 系统验证并提取结果
- 下载生成内容并上传到存储
- 更新任务状态为completed
- 回调业务方通知结果
python复制async def handle_callback(data: dict):
# 验证签名
if not verify_signature(data):
raise HTTPException(403)
# 处理回调
task = await get_task(data)
handler = get_handler(task.type)
await handler.process(task, data)
# 通知业务方
if task.callback_url:
await notify_client(task)
4. 数据模型设计
4.1 任务状态机
mermaid复制stateDiagram-v2
[*] --> PENDING: 创建任务
PENDING --> PROCESSING: 收到回调
PROCESSING --> COMPLETED: 处理成功
PROCESSING --> FAILED: 处理失败
FAILED --> PROCESSING: 重试
4.2 数据库表结构
sql复制CREATE TABLE tasks (
id INTEGER PRIMARY KEY,
task_id TEXT NOT NULL, -- 业务ID
vendor_task_id TEXT UNIQUE, -- 供应商ID
business_type TEXT NOT NULL, -- 业务类型
status TEXT NOT NULL, -- 任务状态
callback_url TEXT, -- 回调地址
result_url TEXT, -- 结果URL
created_at TIMESTAMP, -- 创建时间
updated_at TIMESTAMP, -- 更新时间
completed_at TIMESTAMP -- 完成时间
);
5. 关键实现细节
5.1 回调安全性保障
- 签名验证:所有回调请求必须携带有效签名
- IP白名单:仅允许供应商IP访问回调接口
- 幂等处理:相同回调只处理一次
- 重试机制:失败回调自动重试3次
5.2 文件上传优化
- 流式传输:不落地直接上传到对象存储
- 分块上传:大文件分块并行上传
- 断点续传:上传中断后可恢复
- CDN加速:结果文件通过CDN分发
python复制async def upload_to_storage(url: str):
async with aiohttp.ClientSession() as session:
async with session.get(url) as resp:
async with storage_client.open_upload_stream() as buffer:
async for chunk in resp.content.iter_chunked(1024*1024):
await buffer.write(chunk)
return storage_client.get_public_url()
6. 运维监控体系
6.1 监控指标
| 指标名称 | 说明 | 报警阈值 |
|---|---|---|
| 任务提交成功率 | 成功提交的任务比例 | <99% (5分钟) |
| 平均处理时间 | 从提交到完成的耗时 | >30分钟 |
| 回调失败率 | 回调通知失败的比例 | >5% |
| 存储上传延迟 | 结果上传到存储的时间 | >5分钟 |
6.2 日志分析
python复制logger.info("Task submitted", extra={
"task_id": task_id,
"vendor": "vendor_a",
"type": "video_gen"
})
logger.error("Upload failed", extra={
"task_id": task_id,
"error": str(e),
"retry_count": retry_count
})
7. 扩展与优化
7.1 性能优化实践
- 连接池管理:复用数据库和HTTP连接
- 异步IO:全程使用async/await
- 批量操作:合并数据库写入
- 缓存热点数据:缓存频繁访问的任务数据
7.2 扩展新业务类型
- 创建新的处理器类
- 实现业务特定逻辑
- 注册到分发器
- 添加对应的API路由
python复制@dispatcher.register("audio_gen")
class AudioHandler(BaseHandler):
async def process(self, task, data):
# 特定音频处理逻辑
pass
8. 经验总结
在实际落地这套系统的过程中,我们积累了一些宝贵经验:
- 回调超时设置:供应商回调超时应不少于5分钟,但不超过1小时
- 任务状态校验:处理回调前必须校验状态,避免重复处理
- 存储命名规范:采用
{task_id}/{timestamp}.ext格式避免冲突 - 压力测试:模拟峰值流量测试系统稳定性
- 文档完整性:为每个供应商维护详细的回调协议文档
这套系统目前已经稳定运行超过6个月,日均处理任务量超过50万,平均处理延迟控制在3分钟以内,可靠性达到99.99%。