前言

随着 AI 应用的爆发式增长，如何设计一套既能支撑海量用户，又能控制运维复杂度的架构，成为每一位技术负责人必须面对的课题。本文将系统性地介绍两套方案：

• 轻量高效型：面向百万级用户，以最低成本快速落地

• 分布式高性能型：面向千万至亿级用户，支撑高并发和海量向量检索

无论你的产品处于哪个阶段，都能从中找到适合的架构参考。

---

一、百万级用户架构：轻量高效型

1.1 设计目标

用最低的运维成本和复杂度，支撑百万用户规模，同时保证性能在可接受范围：

• 延迟 < 100ms

• QPS 数百级别

1.2 核心组件

组件	选型	用途
短期记忆	Redis（单主或主从）	会话状态、滑动窗口对话、限流、缓存
长期记忆	PostgreSQL（主从）	用户画像、偏好、业务数据、事务操作
向量存储	pgvector（同库）	向量检索、RAG、用户记忆向量
应用框架	LangGraph / LangChain + FastAPI	Agent 编排

选型思路：不引入额外的向量数据库，将 pgvector 直接部署在 PostgreSQL 中，大幅降低运维复杂度。一套数据库同时承担业务数据和向量检索的职责，百万级用户完全够用。

1.3 部署架构

[负载均衡] → [Agent 服务集群 (2-4 节点)]
                 ↓
        ┌────────┴────────┐
        ↓                 ↓
    Redis 主从          PostgreSQL 主从
   (会话缓存)          (长期数据 + 向量)

各组件配置说明：

• Redis：单主一从，内存 16-32GB，持久化开启 AOF，保证宕机不丢数据

• PostgreSQL：主库（读写）+ 从库（读分流），16 核 64GB 实例，SSD 云盘 500GB-1TB

• pgvector：创建 HNSW 索引，向量表与用户表关联，单表承载上限约 2000 万行

1.4 数据量估算（100 万用户）

数据类型	单用户数据量	总量
结构化数据（用户档案、偏好）	~1KB	~1GB
向量数据（20 条 × 1536 维）	~120KB	~120GB
索引	—	~80GB
合计	—	~200GB
活跃会话（5% 并发，5 万会话）	~50KB/会话	~2.5GB（Redis）

可以看到，百万级用户的数据量对于单机 PostgreSQL 来说完全在可控范围内，无需过度设计。

1.5 关键设计要点

1. 读写分离 读密集型查询（向量检索、用户画像）走从库，写操作走主库，有效分散数据库压力。

2. 向量索引优化 使用 HNSW 索引，推荐参数配置：

• m = 16

• ef_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 亿+ 用户

• QPS 5000+

• 向量检索规模达到 亿级 ~ 十亿级

• 高可用、延迟可控

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，再通过 CDC（Change Data Capture）异步同步到 Milvus，实现最终一致性，避免应用层的双写复杂度和不一致风险。

2.4 数据量估算（1 亿用户）

数据类型	计算过程	总量
向量数据（20 条/用户 × 1536 维）	20 亿条 × 6KB	~120TB
向量索引	—	~80TB
向量存储合计	—	~200TB
PostgreSQL 结构化数据	1 亿 × 1KB	~100GB
Redis 活跃会话（5% 并发）	500 万会话 × 50KB	~250GB

此时向量数据的存储量已经远超单机承载能力，分布式存储和检索成为必选项。

2.5 关键设计要点

2.5.1 数据库分片策略

组件	分片方式	说明
PostgreSQL	按 user_id 哈希分片（16-32 片）	使用 Citus 或自建分片中间件
Redis Cluster	按 slot 分片	每节点负责部分哈希槽，内置高可用
Milvus	按 collection 分区	按用户群或时间范围分 partition

2.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 + Milvus

• L1：热点用户画像缓存在应用进程内，延迟最低

• L2：频繁访问的短期记忆和用户偏好，命中率高

• L3：持久化存储，保证数据完整性和最终一致性

2.6 高可用与容灾

• 同城双活：两个可用区各部署完整组件，流量按比例分发，单 AZ 故障不影响服务

• 跨地域备份：PostgreSQL 物理备份到 S3，Milvus 定期快照备份

• 故障切换：Redis Cluster 自动故障转移，PostgreSQL 使用 Patroni + etcd 实现主从自动切换

2.7 成本估算（月度）

组件	配置	月成本（约）
Milvus 集群	10 台 32C128G	$8,000 - $12,000
PostgreSQL 分片	4 台 16C64G 高可用	$2,000
Redis Cluster	6 台 16C32G	$2,500
Kafka + Debezium	3 台 8C32G	$800
合计	—	$14,000 - $18,000

以上为云服务参考价格，不含流量费用，实际成本可按需调整。

---

三、架构演进路径

架构不是一蹴而就的，而是随着业务增长逐步演进的：

初期（百万级）
  └─ PG + pgvector + Redis 主从
       │
中期（千万级）
  └─ PG 分区 + 读写分离 + Redis 主从 + 引入 Milvus
       │
成熟期（亿级）
  └─ Citus 分片 PG + Redis 集群 + Milvus 集群 + Kafka CDC

每一步都有明确的触发条件和迁移路径，避免过早优化带来的资源浪费。

---

四、总结对比

维度	百万级方案	千万/亿级方案
Redis	主从	集群（≥12 节点）
PostgreSQL	主从	Citus 分片 / TiDB
向量数据库	pgvector	Milvus / Qdrant 集群
同步机制	应用双写	CDC + Kafka
部署节点数	5-8 台	30-50 台
月成本	$500 - $1,000	$15,000 - $30,000
运维复杂度	低	高（需专职团队）

---

结语

架构设计的核心原则是 "够用就好，适度前瞻"。

在百万用户阶段，pgvector + PostgreSQL 的组合足以应对绝大多数场景，过度设计只会增加不必要的复杂度和成本。而当数据量和并发真正增长到临界点时，分层分片、异步同步、多级缓存等分布式架构手段便可以依次引入。

希望本文能为正在规划 AI 应用架构的你提供一份实用的参考。记住：从简单开始，按需扩展。