004. 安装 PostgreSQL、Milvus、Redis 与 Dify

学习目标

这一节继续补齐后端项目需要的基础服务。

学完后，你应该能理解：

• PostgreSQL 为什么用于 LangGraph 持久化；
• Milvus 为什么需要 etcd 和 MinIO；
• Redis 为什么适合做缓存；
• Docker Compose 和单条 docker run 的区别；
• .env 如何把后端项目和这些服务连接起来；
• Dify 在后续审批流项目里承担什么角色。

PostgreSQL 的定位

PostgreSQL 也是关系型数据库，但这里不是用它存报销单、用户这类业务数据。

课程里安装 PostgreSQL，主要是给 LangGraph 使用。

LangGraph 做 Agent 工作流时，需要保存：

• 对话历史；
• 执行状态；
• checkpoint；
• 长期记忆相关数据。

这些数据不建议混进业务 MySQL 里。PostgreSQL 更适合作为 LangGraph 官方推荐的持久化存储。

安装 PostgreSQL

PostgreSQL 同样用 Docker 安装。

需要重点理解几个配置：

配置	含义
容器名称	方便后续 docker ps、查看日志、重启服务
POSTGRES_USER	初始化数据库用户
POSTGRES_PASSWORD	初始化用户密码
POSTGRES_DB	初始化数据库名
端口映射	把服务器端口映射到容器内部的 5432
目录映射	把数据保存到服务器固定目录

PostgreSQL 容器启动后，可以用 PyCharm Database 工具连接。

连接成功后会看到 PostgreSQL 自带的默认库，也会看到给 LangGraph 准备的数据库。后续真正写入 LangGraph 数据时，表会在对应 schema 下创建。

PostgreSQL 的 schema

PostgreSQL 里有一个 MySQL 不太常见的概念：schema。

可以先把 schema 理解成数据库里的“文件夹”，用来给表分组。

例如同一个数据库里可以有：

• public schema；
• LangGraph 创建的 checkpoint 表；
• 其他业务或工具创建的表。

当前只要知道：PostgreSQL 的层级比 MySQL 多一层，很多表会放在某个 schema 下面。

初始化 LangGraph 表

后端项目里会有一个专门的接口或初始化逻辑，用来创建 LangGraph 需要的表。

调用后，可以在 PostgreSQL 里看到类似 checkpoint 的表被创建出来。

这些表不要手动改。它们属于 LangGraph 持久化机制的一部分，后面讲 LangGraph 时再深入理解。

Milvus 的定位

Milvus 是向量数据库。

后面做 RAG 时，会把文档切成片段，再用 Embedding 模型把文本片段转换成向量。向量要存起来，并且支持相似度检索，这就需要 Milvus。

可以这样理解：

• MySQL / MariaDB：适合查结构化业务数据；
• PostgreSQL：这里给 LangGraph 存状态；
• Redis：适合高速缓存；
• Milvus：适合查“语义上相似”的内容。

为什么 Milvus 不只是一个容器？

Milvus 单机版通常会配合多个组件：

组件	作用
etcd	服务协调、元数据管理
MinIO	对象存储，保存文件或索引相关数据
Milvus standalone	Milvus 主服务
Attu / Web UI	用来查看和管理 Milvus 数据

这些组件需要互相访问，所以 Docker Compose 里会把它们放进同一个网络。

同一个 Docker 网络可以理解成一个小局域网。网络里的容器可以用服务名互相访问，不一定要暴露到公网。

Docker Compose 的作用

当一个服务只需要一个容器时，一条 docker run 命令还能接受。

但 Milvus 这种服务需要多个容器协作，继续手写多条 docker run 会很难维护。

Docker Compose 的作用是把多个容器写进一个配置文件：

• 哪些服务要启动；
• 服务之间谁依赖谁；
• 每个服务使用什么镜像；
• 端口怎么映射；
• 目录怎么映射；
• 环境变量怎么设置；
• 它们放到哪个 Docker 网络里。

depends_on 表示服务启动依赖关系。例如 Milvus 要等 etcd 和 MinIO 先启动。

配置 Milvus 连接

Milvus 启动后，需要在后端 .env 里配置连接信息。

常见配置包括：

• Milvus 地址；
• Milvus 端口；
• 用户名；
• 密码；
• 数据库名。

课程里会先创建一个数据库，例如给 LlamaIndex / RAG 使用的数据库。集合 collection 和字段结构可以由后续代码自动创建，不需要手动提前建表。

Redis 的定位

Redis 是缓存数据库。

课程里 Redis 用来缓存高频读取的数据，例如：

• 用户信息；
• 登录认证相关信息；
• 后续 Dify 插件调用中需要缓存的数据。

为什么不每次都查 MySQL？

因为用户信息、认证信息这类数据读取频率很高。每次都查业务数据库，会给数据库带来不必要压力。把高频数据放进 Redis，读取速度更快，也能减轻数据库负担。

安装 Redis 与 Redis Commander

课程使用 Docker Compose 启动 Redis，并搭配 Redis Commander。

服务	作用
Redis	真正的缓存数据库
Redis Commander	Web UI，用来查看和管理 Redis 数据

Redis 自身只需要密码，不像 MySQL 那样创建多个命名数据库。

Redis 里的多数据库通常用数字表示：

• 0 表示第 0 个数据库；
• 1 表示第 1 个数据库；
• 后端配置里可以指定使用哪个编号。

更新后端 .env

PostgreSQL、Milvus、Redis 都启动后，要把 .env 里的连接配置补完整。

然后放开后端项目里对应的连接检查代码，重新启动服务。

看到类似下面的连接成功提示，说明基础服务已经接入：

• MySQL / MariaDB 连接成功；
• PostgreSQL 连接成功；
• Milvus 连接成功；
• Redis 连接成功。

这一步的目标不是写业务功能，而是确认后端项目能同时连上所有基础设施。

FastAPI 接口文档

后端跑起来后，可以打开 FastAPI 自动生成的接口文档页面。

这个页面会列出当前后端暴露的接口。后续调试时，可以通过它快速确认：

• 服务是否启动；
• 路由是否注册；
• 请求参数是什么；
• 返回结构是什么。

等后面正式讲 FastAPI 时，再从零解释这个文档如何生成、如何使用。

Dify 的定位

Dify 是一个工作流平台。

在后续报销审批项目里，它不是替代后端，而是作为流程编排的一部分存在。

例如报销审批可以有这样的规则：

• 金额较小，只需要直属领导审批；
• 金额较大，需要继续往上审批；
• 金额超过某个阈值，需要审批到总经理或老板；
• 当前审批人通过后，要判断流程是否结束，还是继续流转。

这类“下一步该找谁审批”的判断，可以通过工作流平台来控制。后端负责调用工作流，拿到判断结果后继续执行业务逻辑。

部署 Dify

Dify 部署也使用 Docker Compose，因为它本身包含多个服务：

• Web；
• API；
• Worker；
• 插件服务；
• PostgreSQL；
• Redis；
• 沙箱环境；
• 反向代理相关服务。

所以 Dify 启动后会多出很多容器，内存占用也会明显上升。前面买服务器时强调 4GB 内存，就是因为后续会同时跑很多服务。

配置 Dify 插件和模型

Dify 启动后，还需要安装模型供应商插件并配置 API Key。

课程里涉及：

• 火山方舟 / 豆包相关模型；
• 通义千问相关模型；
• 后续可能按需要接入其他模型供应商。

如果插件安装很慢，通常和网络、Python 包下载源、插件执行超时时间有关。Dify 插件很多依赖 Python 包，下载源设置不合适时会非常慢。

当前阶段先把 Dify 基础环境搭起来，具体怎么设计工作流、怎么接入报销业务，后面再展开。