Serverless AI系统备份恢复：架构师的特殊处理

1. 引入：一场Serverless AI系统的“惊魂时刻”

凌晨3点，某在线教育公司的AI答疑系统突然宕机——用户发送的数学题无法得到AI解答，后台报警短信像潮水般涌来。运维团队紧急排查发现：负责AI推理的Serverless函数（AWS Lambda）配置被误删，存放在S3的最新版数学模型（基于GPT-4微调）因版本控制未开启而丢失，更糟糕的是，用户的会话上下文（存放在Redis）因未备份而全部清空。

当技术团队耗时8小时终于恢复系统时，业务已经损失了近10%的日活用户。这场故障的核心问题不是“没有备份”，而是用传统IT系统的备份思维应对Serverless AI系统——他们备份了函数代码，却忽略了函数的配置；备份了模型文件，却没管模型的版本关联；甚至完全忘记了Serverless系统中“外置状态”的备份。

Serverless AI系统的本质是**“无状态计算+有状态AI资产”的混合体**：函数是无状态的，但AI模型、训练数据、用户状态是有状态的；计算资源是弹性的，但AI资产的一致性是刚性的。架构师需要解决的，不是“如何备份服务器”，而是“如何备份Serverless资源的配置、AI资产的关联，以及系统的运行逻辑”。

2. 概念地图：Serverless AI系统的“备份对象全景图”

在设计备份方案前，我们需要先明确Serverless AI系统的核心组件——备份的本质是备份“系统运行的必要元素”，而这些元素散落在Serverless架构的各个层中：

2.1 Serverless AI系统的组件分层

层级	核心组件	备份关键对象
计算层	FaaS函数（Lambda/阿里云FC）	函数代码、配置（环境变量/触发器/权限）、版本别名
AI资产层	模型（S3/OSS/Model Registry）	模型文件、元数据（框架/版本/训练参数）、版本线
数据层	训练数据/推理数据/元数据	结构化数据（DynamoDB/TableStore）、非结构化数据（对象存储）、流式数据（Kafka）
状态层	外置状态存储（Redis/Memcached）	会话上下文、实时缓存、状态一致性快照
触发与流程层	API网关/EventBridge/Step Functions	触发关系（API→函数→模型）、工作流定义（DAG/状态机）

2.2 备份的“特殊性”根源

Serverless AI系统的备份之所以需要“特殊处理”，是因为它同时具备**Serverless的“无状态+弹性”和AI系统的“重资产+强关联”**两大特性：

• 无状态≠无配置：函数本身不存储状态，但函数的运行依赖配置（如触发器、权限、内存设置）——这些配置是“隐形的系统资产”，丢失后函数无法正常工作。
• 弹性≠无数据：Serverless函数会动态创建/销毁实例，但AI模型、训练数据是“静态重资产”（单模型可达数十GB），弹性伸缩不会改变这些资产的存储位置，但会放大“资产不一致”的风险（比如新实例拉取到旧版本模型）。
• AI资产≠普通数据：模型是“代码+数据”的混合体（比如PyTorch模型包含权重参数和计算图），训练数据是“模型的原料”，元数据是“模型的身份证”——这三者必须关联备份，否则恢复后的模型可能“无法运行”或“运行结果错误”。

3. 基础理解：Serverless AI备份的“三大误区”

在开始设计备份方案前，我们需要先澄清传统备份思维带来的三大误区：

误区1：“备份函数代码就够了”

传统IT系统中，备份应用程序的代码和二进制文件就能恢复服务。但在Serverless中，函数的“配置”比“代码”更重要——比如：

• 函数的触发器是API Gateway的/api/ai/answer路径，如果备份时没记录这个配置，恢复后的函数会变成“无家可归的孤儿”。
• 函数的IAM权限是“允许访问S3的模型桶”，如果权限配置丢失，函数会因无法拉取模型而报错。
• 函数的内存设置是10GB（用于加载大模型），如果恢复时设为1GB，函数会因内存不足而频繁崩溃。

结论：函数的备份必须包含“代码+配置+版本别名”，三者缺一不可。

误区2：“模型文件备份=模型备份”

很多团队会把模型文件上传到S3并开启版本控制，就认为完成了模型备份。但模型是“文件+元数据+版本线”的三位一体：

• 元数据：模型的框架（TensorFlow/PyTorch）、输入输出格式（比如[batch_size, 512]）、训练数据集（比如math_dataset_v3）、评估指标（准确率92%）——这些信息丢失后，恢复的模型无法被函数正确加载。
• 版本线：模型的迭代历史（v1→v2→v3），比如v3是线上稳定版，v2是实验版——如果备份时没记录版本线，恢复时可能误选v2导致线上故障。

结论：模型备份需要“文件版本控制+元数据数据库备份+版本线记录”。

误区3：“无状态函数不需要备份状态”

Serverless函数是无状态的，但AI系统的状态是“外置”的——比如：

• LLM聊天系统的会话上下文（用户前面问了“什么是导数”，现在问“如何求导”），存放在Redis中。
• 推荐系统的实时用户行为缓存（用户刚浏览了“初中数学”，需要推荐相关知识点），存放在Memcached中。

这些外置状态是AI系统“理解用户”的关键，丢失后会导致“用户体验断裂”（比如聊天机器人突然忘记之前的对话）。无状态函数的“状态外置”特性，让状态存储的备份成为Serverless AI系统的“生命线”。

4. 层层深入：架构师的“组件级特殊处理方案”

Serverless AI系统的备份恢复需要**“组件拆解→针对性策略→协同恢复”**的设计思路。下面我们针对每个核心组件，讲解架构师的“特殊处理”技巧。

4.1 FaaS函数：配置优先，代码为辅

4.1.1 备份对象清单

对象类型	具体内容
函数代码	函数的部署包（.zip/.jar）或代码仓库中的版本（Git commit ID）
函数配置	环境变量、内存/超时设置、触发器（API Gateway/EventBridge）、IAM角色权限
版本与别名	函数的版本（如v1/v2）、别名（如Prod/Dev）及别名指向的版本

4.1.2 特殊处理策略

• 用IaC工具固化配置：将函数的配置用**基础设施即代码（Infrastructure as Code）**工具（如AWS CloudFormation、Terraform、阿里云ROS）描述，并存入Git仓库。例如，CloudFormation模板可以定义函数的触发器、权限和环境变量：

  Resources:
    AIDemoFunction:
      Type: AWS::Lambda::Function
      Properties:
        FunctionName: ai-demo-function
        Runtime: python3.9
        Handler: index.handler
        Code:
          S3Bucket: my-lambda-code-bucket
          S3Key: ai-demo-function-v1.zip
        Environment:
          Variables:
            MODEL_BUCKET: my-model-bucket
            REDIS_ENDPOINT: redis://my-redis-cluster:6379
        Role: !GetAtt LambdaExecutionRole.Arn
        MemorySize: 10240  # 10GB内存，用于加载大模型
        Timeout: 300       # 5分钟超时
  
    APIGatewayTrigger:
      Type: AWS::ApiGateway::Method
      Properties:
        RestApiId: !Ref MyRestApi
        ResourceId: !Ref ApiResource
        HttpMethod: POST
        AuthorizationType: NONE
        Integration:
          Type: AWS_PROXY
          IntegrationHttpMethod: POST
          Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${AIDemoFunction.Arn}/invocations
  

  这样，函数的配置就变成了“可版本控制的代码”，备份时只需提交Git仓库即可。

• 函数版本与别名备份：Serverless函数的版本（Version）是 immutable的（不可修改），别名（Alias）是指向版本的“指针”（比如Prod别名指向v3）。备份时需要：

  1. 记录所有版本的ARN（如arn:aws:lambda:us-east-1:123456789012:function:ai-demo-function:3）。
  2. 记录别名与版本的映射关系（如Prod→v3，Dev→v4）。
     恢复时，先创建函数版本，再重新绑定别名，保证线上流量指向正确的版本。

4.1.3 恢复验证要点

• 恢复后的函数能否被触发器（如API Gateway）正确调用？
• 函数的环境变量是否正确（比如 MODEL_BUCKET 指向正确的模型桶）？
• 函数的内存/超时设置是否与备份一致？

4.2 AI模型：文件+元数据+版本线的“三位一体”

4.2.1 备份对象清单

对象类型	具体内容
模型文件	模型的二进制文件（如math-model-v3.pth）或ONNX格式文件
模型元数据	框架类型、输入输出形状、训练数据集、评估指标、创建时间
模型版本线	版本迭代历史（v1→v2→v3）、每个版本的上线时间、下线原因

4.2.2 特殊处理策略

• 模型文件的“版本控制+跨区域复制”：

  • 开启对象存储的版本控制（Versioning）（如S3 Versioning、OSS版本控制），保留所有模型版本的历史记录。
  • 开启跨区域复制（CRR）（如S3 Cross-Region Replication），将模型文件复制到另一个AWS区域（如us-east-1→eu-west-1），避免单区域故障导致模型丢失。
  • 对于超大规模模型（如LLaMA-70B，约130GB），使用增量备份：只备份模型的差异部分（比如微调后的权重参数），而不是全量备份，减少存储成本。

• 模型元数据的“数据库化备份”：
  将模型元数据存入结构化数据库（如DynamoDB、MySQL），并开启时间点恢复（PITR）。例如，DynamoDB的PITR可以恢复到过去35天内的任意时间点，保证元数据的一致性。元数据的 schema 示例：

  字段名	类型	说明
  model_id	String	模型唯一ID（如math-model-v3）
  framework	String	框架（如PyTorch 2.0）
  input_shape	List	输入形状（如[1, 512]）
  training_data	String	训练数据集（如math_dataset_v3）
  accuracy	Float	评估准确率（如0.92）
  created_at	Timestamp	创建时间
  s3_key	String	模型文件在S3中的路径

• 模型版本线的“Git式管理”：
  使用模型仓库工具（如MLflow Model Registry、SageMaker Model Registry）管理版本线，记录每个版本的变更日志。例如，MLflow可以记录：

  • v1：初始版本，基于MathDataset v1训练，准确率85%。
  • v2：优化了损失函数，准确率提升至89%，但推理速度下降10%。
  • v3：采用量化技术（INT8），推理速度提升20%，准确率保持89%（线上稳定版）。
    备份时，将模型仓库的元数据（如MLflow的SQLite数据库）定期导出到对象存储，保证版本线的可恢复性。

4.2.3 恢复验证要点

• 恢复的模型文件能否被函数正确加载？（比如用PyTorch的torch.load()加载模型，检查是否报错）
• 模型元数据是否与文件一致？（比如input_shape是否匹配模型的实际输入）
• 版本线是否完整？（比如能否回滚到v2版本）

4.3 数据层：大规模与实时性的“平衡术”

Serverless AI系统的数据层包含三类数据：训练数据（静态）、推理数据（实时）、元数据（关联）。这三类数据的备份策略差异极大，需要架构师在“备份成本”与“恢复需求”之间找到平衡。

4.3.1 训练数据：大规模静态数据的“低成本备份”

训练数据是AI模型的“原料”，通常规模极大（如TB级甚至PB级）。备份策略的核心是**“去重+压缩+增量备份”**：

• 去重：使用数据湖工具（如AWS Lake Formation、阿里云Data Lake Analytics）去除重复数据，减少备份体积。
• 压缩：采用高效压缩算法（如Snappy、Zstandard）压缩数据，降低存储成本。
• 增量备份：只备份新增的训练数据（比如每天新增的10GB数学题数据），而不是全量备份。例如，用S3的生命周期规则将旧数据转移到低成本存储类（如S3 Glacier Instant Retrieval），同时保留增量数据的实时备份。

4.3.2 推理数据：实时流数据的“秒级备份”

推理数据是用户与AI系统的交互数据（如用户的提问、AI的回答），具有实时性高、价值密度低但不可丢失的特点。备份策略的核心是**“流存储+离线归档”**：

• 流存储备份：使用流处理系统（如Kafka、Pulsar）的**镜像复制（MirrorMaker）**功能，将实时流数据复制到另一个集群或区域。例如，Kafka MirrorMaker可以将us-east-1的推理数据流复制到eu-west-1，保证数据不丢失。
• 离线归档：将流数据定期（如每小时）导出到对象存储（如S3），并开启版本控制。这样，即使流集群故障，也能从对象存储恢复历史数据。

4.3.3 元数据：关联型数据的“事务性备份”

元数据是连接“模型、训练数据、推理数据”的纽带（如“模型v3使用了训练数据v3”“推理数据v3对应的模型是v3”），必须保证事务性一致性。备份策略的核心是**“PITR+定期导出”**：

• 时间点恢复（PITR）：对于结构化元数据（如DynamoDB中的模型-数据关联表），开启PITR功能，保证能恢复到任意时间点的一致状态。
• 定期导出：将元数据定期（如每天）导出到对象存储，并生成哈希值（如SHA-256）。恢复时，先通过PITR恢复到最近的时间点，再用导出的文件补充后续数据，保证一致性。

4.3.4 恢复验证要点

• 训练数据的完整性：恢复的训练数据能否重新训练出与原模型一致的模型？
• 推理数据的实时性：恢复的推理数据是否包含故障前的最后1分钟数据？
• 元数据的一致性：模型v3是否仍关联训练数据v3？

4.4 状态层：外置状态的“时效性备份”

Serverless AI系统的状态是“外置”的，但状态的时效性极强（比如会话上下文只有5分钟有效期）。备份策略的核心是**“区分状态类型+按需备份”**。

4.4.1 状态类型与备份策略

状态类型	示例	备份策略
会话上下文	LLM聊天的历史对话	短期备份（保留7天），使用Redis的RDB+AOF混合备份（RDB做快照，AOF做增量日志）
实时缓存	推荐系统的用户实时行为	分钟级备份，使用Memcached的dump工具定期导出缓存数据到对象存储
长期状态	用户的个性化设置（如“喜欢用中文解答”）	持久化备份，存入DynamoDB并开启PITR

4.4.2 特殊处理技巧

• Redis的RDB+AOF备份：
  • RDB（Redis Database Backup）：每隔1小时生成一次快照，保存到S3。
  • AOF（Append Only File）：记录每一条写操作（如SET session:user123 "导数问题"），每隔5分钟同步到S3。
    恢复时，先加载最新的RDB快照，再重放AOF日志，保证状态的一致性。
• 会话状态的“过期清理”：
  对于时效性强的会话状态（如5分钟有效期），备份时要过滤掉已过期的状态，避免存储无效数据。例如，用Redis的EXPIRE命令设置状态的过期时间，备份时只导出未过期的键值对。

4.4.3 恢复验证要点

• 会话上下文能否恢复？（比如用户恢复后的对话能否继续之前的话题）
• 实时缓存能否恢复？（比如推荐系统能否继续根据用户的实时行为推荐内容）
• 长期状态能否恢复？（比如用户的个性化设置是否保留）

4.5 触发与流程层：系统逻辑的“完整性备份”

Serverless AI系统的运行依赖触发链（如API Gateway→Lambda→S3→EventBridge→另一个Lambda）和工作流（如Step Functions的状态机）。这些组件的备份直接影响系统的“运行逻辑”——如果触发链断了，系统就会变成“散架的机器”。

4.5.1 备份对象清单

对象类型	具体内容
API Gateway	资源路径（如/api/ai/answer）、HTTP方法（POST）、集成配置（指向Lambda）
EventBridge	规则（如“当S3上传新模型时触发Lambda”）、目标（Lambda函数ARN）
Step Functions	状态机定义（JSON格式）、执行历史（可选）

4.5.2 特殊处理策略

• 用IaC工具备份触发关系：
  像备份函数配置一样，用CloudFormation或Terraform描述API Gateway、EventBridge、Step Functions的配置。例如，CloudFormation模板可以定义EventBridge规则：

  Resources:
    ModelUploadRule:
      Type: AWS::Events::Rule
      Properties:
        Name: model-upload-rule
        EventPattern:
          source:
            - "aws.s3"
          detail-type:
            - "Object Created"
          detail:
            bucket:
              name:
                - !Ref ModelBucket
        Targets:
          - Arn: !GetAtt ModelProcessingFunction.Arn
            Id: "ModelProcessingFunctionTarget"
  

  这样，触发关系就变成了“可版本控制的代码”，备份时只需提交Git仓库即可。

• Step Functions的状态机备份：
  Step Functions的状态机定义是JSON格式的，记录了工作流的逻辑（如“先下载模型→再验证模型→最后更新别名”）。备份时，将状态机JSON存入Git仓库，并定期导出执行历史到S3（可选）。恢复时，先创建状态机，再重新启动未完成的执行。

4.5.3 恢复验证要点

• 触发链是否完整？（比如上传新模型到S3能否触发ModelProcessingFunction？）
• 工作流是否正常运行？（比如Step Functions的状态机能否完成“下载→验证→更新”的流程？）

5. 多维透视：从“备份”到“系统韧性”

Serverless AI系统的备份恢复不是“技术任务”，而是系统韧性（Resilience）的核心组成部分。架构师需要从多个视角理解备份的价值：

5.1 历史视角：从“服务器备份”到“云资源备份”

传统IT系统的备份是“以服务器为中心”——备份服务器的磁盘、数据库、应用程序。而Serverless时代，备份的对象变成了“云资源的配置与关联”：

• 传统备份：“备份服务器A的C盘”→恢复时“重装服务器A，恢复C盘数据”。
• Serverless备份：“备份函数的配置、模型的元数据、触发链的关系”→恢复时“重建资源配置，关联模型与数据，恢复触发链”。

这种转变的本质是从“物理资产备份”到“逻辑资产备份”——Serverless系统的价值不在“服务器”，而在“资源的组合逻辑”。

5.2 实践视角：某电商推荐系统的备份案例

某电商公司的Serverless推荐系统架构：

• 计算层：Lambda函数处理实时推荐请求。
• AI资产层：S3存储推荐模型（每日更新），MLflow管理模型版本。
• 数据层：DynamoDB存储用户画像（实时更新），Kafka存储用户行为流。
• 状态层：Redis存储用户实时行为缓存（有效期10分钟）。
• 触发层：API Gateway→Lambda→Redis→S3。

备份方案

1. 函数配置：用CloudFormation模板描述Lambda的配置，存入Git仓库，每天提交一次。
2. 模型备份：S3开启版本控制+跨区域复制，MLflow的元数据存入DynamoDB并开启PITR。
3. 数据备份：
   • 用户画像：DynamoDB开启PITR，每天导出到S3。
   • 用户行为流：Kafka MirrorMaker复制到另一个区域，每小时导出到S3。
4. 状态备份：Redis开启RDB（每小时快照）+AOF（每5分钟同步），快照和AOF文件同步到S3。
5. 触发链备份：用CloudFormation描述API Gateway和EventBridge的配置，存入Git仓库。

恢复演练

每季度进行一次全流程恢复演练，模拟“us-east-1区域故障”场景：

1. 在eu-west-1区域用CloudFormation模板重建函数、API Gateway、EventBridge。
2. 用S3的跨区域复制恢复模型文件，用MLflow的元数据恢复版本线。
3. 用DynamoDB的PITR恢复用户画像到故障前10分钟的状态。
4. 用Kafka的镜像数据恢复用户行为流，用Redis的RDB+AOF恢复实时缓存。
5. 验证触发链：发送测试请求到API Gateway，检查推荐结果是否正确。

演练结果：RTO（恢复时间目标）=45分钟，RPO（恢复点目标）=10分钟，满足业务需求。

5.3 批判视角：Serverless AI备份的“四大挑战”

尽管Serverless AI备份有成熟的策略，但仍存在一些难以解决的挑战：

1. 厂商锁定：CloudFormation只能备份AWS资源，Terraform虽然跨云，但不同云厂商的资源类型差异大（如AWS Lambda vs 阿里云FC），迁移成本高。
2. 备份成本：超大规模模型（如LLaMA-70B）的跨区域复制成本极高（每GB数据跨区域复制费用约0.025美元），对于每天更新的模型，每月成本可能高达数万美元。
3. 一致性问题：函数配置、模型、数据的备份时间点可能不一致（比如函数配置备份于10:00，模型备份于10:05，数据备份于10:10），恢复后系统可能出现逻辑错误（如函数用10:00的配置加载10:05的模型，导致参数不匹配）。
4. 恢复时间：跨区域恢复S3数据的时间取决于数据量（如100GB数据可能需要2小时），对于RTO要求严格的业务（如实时推理），可能无法满足需求。

5.4 未来视角：AI驱动的备份恢复

随着AI技术的发展，Serverless AI备份正在向**“智能自动化”**方向演进：

1. AI预测备份频率：用ML模型分析模型、数据的更新频率（如模型每天更新一次，训练数据每周更新一次），自动调整备份频率——模型更新频繁时增加备份频率，训练数据不常更新时减少频率，降低备份成本。
2. 自动化恢复流程：用Step Functions或Argo Workflows定义“故障检测→资源重建→数据恢复→验证”的自动化流程，减少人工干预。例如，当CloudWatch Alarm检测到Lambda函数故障时，自动触发恢复流程。
3. 边缘备份：对于边缘计算的Serverless AI系统（如部署在5G边缘节点的实时推理函数），将备份数据存储在边缘节点的本地存储中，降低恢复延迟（从小时级降到分钟级）。
4. 区块链存证：用区块链技术记录模型、数据的哈希值（如SHA-256），保证备份数据的不可篡改——当恢复时，通过哈希值验证数据的完整性，避免“被篡改的模型”进入系统。

6. 实践转化：架构师的“备份恢复 checklist”

设计Serverless AI系统的备份方案时，架构师可以按照以下 checklist 逐步落实：

6.1 第一步：资产Inventory

• 列出系统的所有组件（函数、模型、数据、状态、触发链）。
• 明确每个组件的备份对象（如函数的配置、模型的元数据）。
• 梳理组件间的依赖关系（如函数依赖模型、模型依赖训练数据）。

6.2 第二步：定义RTO/RPO

• 根据业务需求，确定每个组件的RTO（恢复时间目标）和RPO（恢复点目标）。例如：
  • 函数：RTO=15分钟，RPO=0（配置不丢失）。
  • 模型：RTO=30分钟，RPO=1小时（每小时备份一次）。
  • 用户画像：RTO=10分钟，RPO=5分钟（每5分钟备份一次）。

6.3 第三步：选择备份工具

根据云厂商选择合适的工具：

云厂商	函数配置	模型备份	数据备份	状态备份	触发链备份
AWS	CloudFormation	S3 Versioning+CRR	DynamoDB PITR+S3	Redis RDB+AOF	CloudFormation
阿里云	ROS	OSS版本控制+跨区域复制	TableStore PITR+OSS	Redis 持久化	ROS
跨云	Terraform	对象存储版本控制	数据库PITR+对象存储	Redis 持久化	Terraform

6.4 第四步：设计备份策略

• 函数配置：用IaC工具描述，存入Git仓库，每天提交。
• 模型备份：开启对象存储版本控制+跨区域复制，元数据存入数据库并开启PITR。
• 数据备份：结构化数据用PITR+定期导出，非结构化数据用版本控制+增量备份，流式数据用镜像复制+离线归档。
• 状态备份：区分状态类型，采用RDB+AOF（会话上下文）、定期导出（实时缓存）、PITR（长期状态）。
• 触发链：用IaC工具描述，存入Git仓库。

6.5 第五步：测试与优化

• 每季度进行一次全流程恢复演练，记录RTO/RPO是否达标。
• 分析演练中的问题（如恢复时间过长、数据不一致），优化备份策略。
• 设置监控报警（如备份失败、RPO超时），及时发现问题。

7. 整合提升：从“备份”到“系统设计”

Serverless AI系统的备份恢复不是“事后补救”，而是系统设计的一部分。架构师需要将备份思维融入系统设计的每个环节：

• 在设计函数时：用IaC工具固化配置，避免手动修改配置导致的丢失。
• 在设计模型存储时：开启版本控制和跨区域复制，避免模型文件丢失。
• 在设计数据层时：选择支持PITR的数据库，保证数据的一致性恢复。
• 在设计触发链时：用IaC工具描述触发关系，避免触发链断裂。

8. 结语：备份是架构师的“保险单”

Serverless AI系统的备份恢复，本质是**“为系统的运行逻辑买保险”**——保险的价值不在“平时”，而在“灾难时刻”。架构师的职责不是“做备份”，而是“设计一个能应对故障的系统”：

• 不是“备份所有东西”，而是“备份系统运行的必要元素”。
• 不是“追求完美的备份”，而是“在成本与需求之间找到平衡”。
• 不是“完成备份任务”，而是“保证系统在故障后能快速恢复”。

当我们从“备份技术”上升到“系统韧性”的高度，Serverless AI系统的备份恢复就不再是“特殊处理”，而是“架构设计的必修课”。

拓展任务：设计一个Serverless LLM聊天系统的备份方案，包含以下组件：

1. 函数：Lambda处理聊天请求（加载LLM模型，管理会话上下文）。
2. 模型：S3存储LLM模型（如Llama-2-7B-chat），MLflow管理版本。
3. 状态：Redis存储会话上下文（有效期5分钟）。
4. 触发链：API Gateway→Lambda→Redis→S3。

请写出每个组件的备份策略和恢复步骤，并计算RTO/RPO。

推荐资源：

• 《Serverless Architectures on AWS》（第2版）：讲解Serverless系统的设计与备份。
• AWS文档：《Backup and Restore for Serverless Applications》。
• MLflow文档：《Model Registry》。
• 论文：《Backup and Recovery for Serverless Computing》（IEEE Cloud 2021）。

让我们一起，用备份恢复为Serverless AI系统筑牢“安全防线”！