# AI 应用架构设计：从百万到亿级用户的扩展之路

前言随着 AI 应用的爆发式增长如何设计一套既能支撑海量用户又能控制运维复杂度的架构成为每一位技术负责人必须面对的课题。本文将系统性地介绍两套方案轻量高效型面向百万级用户以最低成本快速落地分布式高性能型面向千万至亿级用户支撑高并发和海量向量检索无论你的产品处于哪个阶段都能从中找到适合的架构参考。一、百万级用户架构轻量高效型1.1 设计目标用最低的运维成本和复杂度支撑百万用户规模同时保证性能在可接受范围延迟 100msQPS 数百级别1.2 核心组件组件选型用途短期记忆Redis单主或主从会话状态、滑动窗口对话、限流、缓存长期记忆PostgreSQL主从用户画像、偏好、业务数据、事务操作向量存储pgvector同库向量检索、RAG、用户记忆向量应用框架LangGraph / LangChain FastAPIAgent 编排选型思路不引入额外的向量数据库将 pgvector 直接部署在 PostgreSQL 中大幅降低运维复杂度。一套数据库同时承担业务数据和向量检索的职责百万级用户完全够用。1.3 部署架构[负载均衡] → [Agent 服务集群 (2-4 节点)] ↓ ┌────────┴────────┐ ↓ ↓ Redis 主从 PostgreSQL 主从 (会话缓存) (长期数据 向量)各组件配置说明Redis单主一从内存 16-32GB持久化开启 AOF保证宕机不丢数据PostgreSQL主库读写 从库读分流16 核 64GB 实例SSD 云盘 500GB-1TBpgvector创建 HNSW 索引向量表与用户表关联单表承载上限约 2000 万行1.4 数据量估算100 万用户数据类型单用户数据量总量结构化数据用户档案、偏好~1KB~1GB向量数据20 条 × 1536 维~120KB~120GB索引—~80GB合计—~200GB活跃会话5% 并发5 万会话~50KB/会话~2.5GBRedis可以看到百万级用户的数据量对于单机 PostgreSQL 来说完全在可控范围内无需过度设计。1.5 关键设计要点1. 读写分离读密集型查询向量检索、用户画像走从库写操作走主库有效分散数据库压力。2. 向量索引优化使用 HNSW 索引推荐参数配置m 16ef_construction 64查询时ef_search 40这一组参数在召回率和查询速度之间取得了较好的平衡。3. Redis TTL 策略会话数据设置 30 分钟过期时间自动清理无效数据避免内存持续增长。4. 冷热分离超过 30 天未登录用户的非活跃向量数据可归档到对象存储可选进一步降低主库存储压力。5. 扩展性预留当向量行数超过 2000 万或 QPS 超过 1000 时可平滑将向量检索从 pgvector 拆出至独立的 Milvus 服务架构升级路径清晰。1.6 运维要点每日全量备份 WAL 归档确保数据可恢复监控慢查询、连接数、缓存命中率等关键指标使用pgBouncer管理数据库连接池防止连接数暴涨二、千万 / 亿级用户架构分布式高性能型2.1 设计目标当用户规模增长至千万甚至上亿级别时单机架构已无法满足需求。此阶段的核心目标是支撑1000 万 ~ 1 亿用户QPS5000向量检索规模达到亿级 ~ 十亿级高可用、延迟可控2.2 核心组件层级组件用途接入层负载均衡LVS/Nginx API 网关流量分发、鉴权、限流短期记忆Redis Cluster≥12 节点会话状态、分布式缓存、计数器长期记忆PostgreSQL 分片集群如 Citus或TiDB用户画像、业务事务、关系数据向量存储Milvus 集群或 Qdrant / Weaviate十亿级向量检索、混合搜索同步管道Debezium Kafka数据变更捕获PG → Milvus 异步同步对象存储MinIO / S3向量冷备、模型文件、日志存储2.3 数据流向用户请求 → API 网关 → Agent 服务多 AZ 容器化 ↓ ┌────────────────┼────────────────┐ ↓ ↓ ↓ Redis Cluster PostgreSQL Milvus Cluster (短期记忆) (长期元数据) (向量检索) ↕ (CDC via Kafka) └── 异步同步 ──┘引入 Kafka Debezium 是这一架构的关键变化。用户画像的变更先写入 PostgreSQL再通过 CDCChange Data Capture异步同步到 Milvus实现最终一致性避免应用层的双写复杂度和不一致风险。2.4 数据量估算1 亿用户数据类型计算过程总量向量数据20 条/用户 × 1536 维20 亿条 × 6KB~120TB向量索引—~80TB向量存储合计—~200TBPostgreSQL 结构化数据1 亿 × 1KB~100GBRedis 活跃会话5% 并发500 万会话 × 50KB~250GB此时向量数据的存储量已经远超单机承载能力分布式存储和检索成为必选项。2.5 关键设计要点2.5.1 数据库分片策略组件分片方式说明PostgreSQL按user_id哈希分片16-32 片使用 Citus 或自建分片中间件Redis Cluster按 slot 分片每节点负责部分哈希槽内置高可用Milvus按 collection 分区按用户群或时间范围分 partition2.5.2 向量检索优化使用IVF_PQ或HNSW索引根据内存与性能需求灵活选择多副本负载均衡读 QPS 可水平扩展标量过滤前置先通过 PostgreSQL 过滤 user_id 范围再在 Milvus 中做向量检索大幅减少向量检索的候选集传统方式Milvus 全量检索 → 标量过滤 → 返回结果 慢 优化方式PostgreSQL 标量过滤 → Milvus 小范围向量检索 → 返回结果 快2.5.3 数据一致性策略在分布式系统中强一致性往往以牺牲性能和可用性为代价。我们采用分层策略最终一致性用户画像更新 → 先写 PostgreSQL → CDC 异步同步到 Milvus延迟秒级短期记忆强一致Redis Cluster 使用WAIT命令确保主从同步关键事务如支付不经过缓存直接读写 PostgreSQL 主库2.5.4 多级缓存架构L1: 本地进程缓存 (Caffeine) ↓ 未命中 L2: Redis Cluster ↓ 未命中 L3: PostgreSQL MilvusL1热点用户画像缓存在应用进程内延迟最低L2频繁访问的短期记忆和用户偏好命中率高L3持久化存储保证数据完整性和最终一致性2.6 高可用与容灾同城双活两个可用区各部署完整组件流量按比例分发单 AZ 故障不影响服务跨地域备份PostgreSQL 物理备份到 S3Milvus 定期快照备份故障切换Redis Cluster 自动故障转移PostgreSQL 使用 Patroni etcd 实现主从自动切换2.7 成本估算月度组件配置月成本约Milvus 集群10 台 32C128G$8,000 - $12,000PostgreSQL 分片4 台 16C64G 高可用$2,000Redis Cluster6 台 16C32G$2,500Kafka Debezium3 台 8C32G$800合计—$14,000 - $18,000以上为云服务参考价格不含流量费用实际成本可按需调整。三、架构演进路径架构不是一蹴而就的而是随着业务增长逐步演进的初期百万级 └─ PG pgvector Redis 主从 │ 中期千万级 └─ PG 分区 读写分离 Redis 主从 引入 Milvus │ 成熟期亿级 └─ Citus 分片 PG Redis 集群 Milvus 集群 Kafka CDC每一步都有明确的触发条件和迁移路径避免过早优化带来的资源浪费。四、总结对比维度百万级方案千万/亿级方案Redis主从集群≥12 节点PostgreSQL主从Citus 分片 / TiDB向量数据库pgvectorMilvus / Qdrant 集群同步机制应用双写CDC Kafka部署节点数5-8 台30-50 台月成本$500 - $1,000$15,000 - $30,000运维复杂度低高需专职团队结语架构设计的核心原则是够用就好适度前瞻。在百万用户阶段pgvector PostgreSQL 的组合足以应对绝大多数场景过度设计只会增加不必要的复杂度和成本。而当数据量和并发真正增长到临界点时分层分片、异步同步、多级缓存等分布式架构手段便可以依次引入。希望本文能为正在规划 AI 应用架构的你提供一份实用的参考。记住从简单开始按需扩展。