Dify 扛不住并发？从 API 到 Worker 的生产级优化方案附配置示例

发布人：慈云数据-客服中心发布时间：13小时前阅读量：6

Dify 高并发解决方案｜附配置文件

随着大模型应用从“Demo 验证”走向“生产落地”，Dify 这类 LLMOps 平台的并发能力越来越受到关注。很多团队在本地或单机环境中部署 Dify 时，前期使用非常顺畅，但一旦接入真实业务流量，例如企业知识库问答、客服机器人、内部 Copilot、工作流自动化等场景，就可能遇到响应变慢、任务堆积、接口超时、Worker 消费不及时、数据库连接被打满等问题。

本文将围绕 Dify 高并发部署与优化方案 展开，结合实际生产环境中的常见瓶颈，给出一套相对完整的优化思路，并附上可参考的配置文件示例，帮助你从单机部署逐步过渡到更适合生产使用的高并发架构。

一、Dify 高并发场景下的常见问题

在讨论解决方案之前，我们先明确 Dify 在高并发场景下可能出现的问题。只有知道瓶颈在哪里，才能有针对性地优化。

1. API 响应变慢

当用户请求数量增加时，最直接的表现就是接口响应时间变长。尤其是 Chat App、Workflow App、Agent App 等调用大模型的接口，如果后端处理能力不足，就容易出现请求排队。

常见表现包括：

页面等待时间明显增加；
API 请求偶发超时；
流式输出卡顿；
前端显示“正在思考”时间过长；
多用户同时访问时整体体验下降。

2. Celery Worker 任务堆积

Dify 中很多任务会通过异步任务队列处理，例如：

文档解析；
知识库索引构建；
向量化处理；
数据集导入；
一些工作流后台任务。

如果 Celery Worker 数量不足，或者单个 Worker 并发配置太低，就会导致任务不断堆积，最终表现为文档上传后长时间不完成、知识库更新延迟等问题。

3. Redis 压力过大

Redis 在 Dify 中通常承担缓存、任务队列中间件、状态管理等职责。如果并发请求较多，Redis 连接数、内存、网络吞吐都可能成为瓶颈。

常见问题包括：

Redis 连接数被打满；
队列消息积压；
Redis 内存持续增长；
响应时间变慢。

4. PostgreSQL 数据库连接不足

Dify 的主要业务数据通常存储在 PostgreSQL 中。高并发访问下，如果 API 服务、Worker 服务都频繁连接数据库，可能会出现数据库连接数不足的问题。

常见报错类似：

remaining connection slots are reserved for non-replication superuser connections
too many clients already

这说明数据库连接数已经被耗尽，需要优化连接池和数据库参数。

5. 向量数据库压力增加

如果使用 Dify 的知识库能力，就离不开向量数据库，例如 Weaviate、Qdrant、Milvus、PgVector 等。高并发问答场景下，每次请求都可能触发向量检索，因此向量数据库的查询性能也非常关键。

二、Dify 高并发优化的整体思路

Dify 的高并发优化不能只靠“把某个参数调大”，而应该从整体架构层面进行设计。通常可以从以下几个方向入手：

API 服务横向扩容
Worker 服务独立扩容
Redis、PostgreSQL、向量数据库独立部署
使用 Nginx 或云负载均衡分发流量
合理配置 Gunicorn、Celery 并发参数
增加数据库连接池
拆分大任务与实时请求
限制单用户或单应用并发
开启监控与日志分析
对大模型调用做限流、缓存与降级

一个比较推荐的生产部署架构如下：

用户请求
   │
   ▼
Nginx / SLB / Ingress
   │
   ├── Dify API 实例 1
   ├── Dify API 实例 2
   ├── Dify API 实例 3
   │
   └── Dify Web 前端服务
        │
        ▼
 Redis / PostgreSQL / Vector DB / Object Storage
        ▲
        │
   Celery Worker 集群

这里要注意：API 服务和 Worker 服务应该分开扩容。API 服务主要处理用户实时请求，Worker 服务主要处理异步任务。如果两者混在一起，当大量文档导入或索引任务出现时，很容易影响用户的正常问答体验。

三、核心组件优化建议

1. API 服务优化

Dify API 服务通常基于 Python Web 服务运行。在 Docker 部署中，API 服务的并发能力与以下因素有关：

容器数量；
Gunicorn Worker 数量；
单个 Worker 的线程数；
CPU 核数；
内存大小；
数据库连接池配置；
上游大模型接口响应速度。

生产环境建议至少启动多个 API 实例，并通过 Nginx 或负载均衡进行分发。

如果是 4 核 8G 服务器，可以先从以下配置开始：

API 实例数：2
Gunicorn Workers：2 ~ 4
Threads：4 ~ 8

如果是 8 核 16G 服务器，可以考虑：

API 实例数：3 ~ 4
Gunicorn Workers：4
Threads：4 ~ 8

需要注意的是，Worker 数量并不是越多越好。过多的进程会导致 CPU 上下文切换变多，同时也会占用更多数据库连接。

2. Celery Worker 优化

Celery Worker 是 Dify 中处理后台任务的重要组件。高并发文档处理、知识库构建时，Worker 是否足够直接决定任务完成速度。

常见优化方式包括：

增加 Worker 容器数量；
调整 Celery 并发数；
区分不同队列；
给高优先级任务单独 Worker；
对文档处理任务设置资源限制；
避免大量大文件同时导入。

例如，可以将 Worker 分为普通任务 Worker 和高负载任务 Worker：

worker-default：处理默认异步任务
worker-indexing：处理文档解析、向量化、索引构建
worker-mail：处理通知类任务

如果机器资源允许，可以为索引任务单独配置更高内存的 Worker，避免文档解析时占用过多内存导致其他服务异常。

3. Redis 优化

Redis 在高并发场景下建议独立部署，不建议长期使用与 Dify 服务混合在同一台小规格机器上。

推荐配置：

Redis 内存：至少 2GB，生产建议 4GB 以上
maxclients：10000 以上
持久化：根据业务要求开启 AOF 或 RDB
淘汰策略：allkeys-lru 或 noeviction，视业务而定

如果 Redis 主要作为队列和缓存使用，可以开启 AOF everysec，兼顾性能和可靠性。

4. PostgreSQL 优化

PostgreSQL 是高并发部署中的关键。很多 Dify 性能问题最终都会表现为数据库连接不足或慢查询。

建议从以下几个方面优化：

增加最大连接数

max_connections = 300

但不要盲目设置过大，因为每个连接都会占用内存。更推荐搭配 PgBouncer 做连接池。

使用 PgBouncer

PgBouncer 可以显著降低 PostgreSQL 的连接压力。API 和 Worker 不直接连接 PostgreSQL，而是连接 PgBouncer，由 PgBouncer 复用数据库连接。

推荐模式：

pool_mode = transaction
default_pool_size = 50
max_client_conn = 1000

调整内存参数

如果数据库单独部署在 8G 内存机器上，可以参考：

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB

这些参数需要结合机器规格调整，不能直接照搬到所有环境。

5. 向量数据库优化

如果你的 Dify 应用大量依赖知识库问答，那么向量数据库的性能非常重要。优化建议包括：

向量数据库独立部署；
使用 SSD 磁盘；
根据数据量选择合适的向量库；
控制 top_k 参数；
对知识库进行合理分片；
避免单个知识库无限膨胀；
定期清理无效数据；
对高频问题做缓存。

很多人以为大模型响应慢，其实真正慢的是检索阶段。例如一次问答包含：

问题改写 → 向量检索 → rerank → prompt 组装 → LLM 调用 → 流式输出

其中向量检索和 rerank 都可能产生明显延迟。因此，高并发知识库问答场景下，建议对 top_k、score_threshold、rerank 模型进行细致调优。

四、推荐的高并发 Docker Compose 配置

下面给出一份简化版 docker-compose.prod.yml 示例，用于说明如何通过横向扩展 API 和 Worker 来提升并发能力。实际生产环境中，你需要结合 Dify 官方版本的 compose 文件进行调整。

注意：以下配置为参考示例，不同 Dify 版本的环境变量可能存在差异，请以你当前版本的官方配置为准。

version: "3.9"

services:
  nginx:
    image: nginx:1.25
    container_name: dify-nginx
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d
      - ./nginx/certs:/etc/nginx/certs
    depends_on:
      - web
      - api-1
      - api-2
      - api-3
    networks:
      - dify

  web:
    image: langgenius/dify-web:latest
    container_name: dify-web
    restart: always
    environment:
      CONSOLE_API_URL: https://dify.example.com
      APP_API_URL: https://dify.example.com
    networks:
      - dify

  api-1:
    image: langgenius/dify-api:latest
    container_name: dify-api-1
    restart: always
    env_file:
      - .env.prod
    command: >
      gunicorn
      --bind 0.0.0.0:5001
      --workers 4
      --threads 8
      --timeout 300
      --keep-alive 5
      app:app
    depends_on:
      - redis
      - db
    networks:
      - dify

  api-2:
    image: langgenius/dify-api:latest
    container_name: dify-api-2
    restart: always
    env_file:
      - .env.prod
    command: >
      gunicorn
      --bind 0.0.0.0:5001
      --workers 4
      --threads 8
      --timeout 300
      --keep-alive 5
      app:app
    depends_on:
      - redis
      - db
    networks:
      - dify

  api-3:
    image: langgenius/dify-api:latest
    container_name: dify-api-3
    restart: always
    env_file:
      - .env.prod
    command: >
      gunicorn
      --bind 0.0.0.0:5001
      --workers 4
      --threads 8
      --timeout 300
      --keep-alive 5
      app:app
    depends_on:
      - redis
      - db
    networks:
      - dify

  worker-default:
    image: langgenius/dify-api:latest
    container_name: dify-worker-default
    restart: always
    env_file:
      - .env.prod
    command: >
      celery
      -A app.celery
      worker
      -Q default
      --loglevel=INFO
      --concurrency=8
      --max-tasks-per-child=200
    depends_on:
      - redis
      - db
    networks:
      - dify

  worker-indexing-1:
    image: langgenius/dify-api:latest
    container_name: dify-worker-indexing-1
    restart: always
    env_file:
      - .env.prod
    command: >
      celery
      -A app.celery
      worker
      -Q indexing
      --loglevel=INFO
      --concurrency=4
      --max-tasks-per-child=50
    depends_on:
      - redis
      - db
    networks:
      - dify

  worker-indexing-2:
    image: langgenius/dify-api:latest
    container_name: dify-worker-indexing-2
    restart: always
    env_file:
      - .env.prod
    command: >
      celery
      -A app.celery
      worker
      -Q indexing
      --loglevel=INFO
      --concurrency=4
      --max-tasks-per-child=50
    depends_on:
      - redis
      - db
    networks:
      - dify

  redis:
    image: redis:7.2
    container_name: dify-redis
    restart: always
    command: >
      redis-server
      /usr/local/etc/redis/redis.conf
    volumes:
      - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
      - redis_data:/data
    networks:
      - dify

  db:
    image: postgres:15
    container_name: dify-postgres
    restart: always
    environment:
      POSTGRES_USER: dify
      POSTGRES_PASSWORD: dify_secure_password
      POSTGRES_DB: dify
    volumes:
      - pg_data:/var/lib/postgresql/data
      - ./postgres/postgresql.conf:/etc/postgresql/postgresql.conf
    command: >
      postgres
      -c config_file=/etc/postgresql/postgresql.conf
    networks:
      - dify

networks:
  dify:
    driver: bridge

volumes:
  pg_data:
  redis_data:

五、Nginx 负载均衡配置

下面是一个简单的 Nginx 配置示例，将请求分发到多个 API 实例，同时代理前端 Web 服务。

文件路径：

./nginx/conf.d/dify.conf

配置内容：

upstream dify_api {
    least_conn;
    server dify-api-1:5001 max_fails=3 fail_timeout=30s;
    server dify-api-2:5001 max_fails=3 fail_timeout=30s;
    server dify-api-3:5001 max_fails=3 fail_timeout=30s;
}

upstream dify_web {
    server dify-web:3000;
}

server {
    listen 80;
    server_name dify.example.com;

    client_max_body_size 100M;

    proxy_connect_timeout 60s;
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;

    location /console/api/ {
        proxy_pass http://dify_api;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /api/ {
        proxy_pass http://dify_api;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_cache off;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /v1/ {
        proxy_pass http://dify_api;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_cache off;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        proxy_pass http://dify_web;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里有几个关键点：

least_conn 适合长连接或流式输出场景，可以优先把请求转发给当前连接数较少的 API 实例。
proxy_buffering off 对流式输出很重要，否则用户可能无法实时看到模型输出。
proxy_read_timeout 300s 可以减少长时间大模型调用导致的 Nginx 超时。
client_max_body_size 100M 可以避免上传知识库文档时被 Nginx 拦截。

六、Redis 配置文件示例

文件路径：

./redis/redis.conf

配置内容：

bind 0.0.0.0
protected-mode yes
port 6379

tcp-backlog 511
timeout 0
tcp-keepalive 300

daemonize no
supervised no

databases 16

save 900 1
save 300 10
save 60 10000

appendonly yes
appendfsync everysec

maxmemory 4gb
maxmemory-policy allkeys-lru

maxclients 10000

slowlog-log-slower-than 10000
slowlog-max-len 256

dir /data

如果 Redis 部署在公网环境，一定要配置密码、防火墙和安全组，避免暴露在互联网中。生产环境建议 Redis 只允许内网访问。

七、PostgreSQL 配置文件示例

文件路径：

./postgres/postgresql.conf

配置内容：

listen_addresses = '*'
port = 5432

max_connections = 300

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB

checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100

random_page_cost = 1.1
effective_io_concurrency = 200

log_min_duration_statement = 1000
log_connections = on
log_disconnections = on

timezone = 'Asia/Shanghai'

需要注意，PostgreSQL 参数必须结合服务器规格调整。例如，如果你的数据库机器只有 4G 内存，就不应该设置 shared_buffers = 2GB，否则可能导致系统内存紧张。

八、环境变量配置示例

下面是一份 .env.prod 参考配置，只展示和高并发相关的重点参数，实际部署时需要合并 Dify 官方 .env 中的完整变量。

# 基础配置
EDITION=SELF_HOSTED
DEPLOY_ENV=PRODUCTION
LOG_LEVEL=INFO

# API 服务
SERVER_WORKER_AMOUNT=4
SERVER_WORKER_CLASS=gthread
SERVER_WORKER_CONNECTIONS=100
GUNICORN_TIMEOUT=300

# 数据库
DB_USERNAME=dify
DB_PASSWORD=dify_secure_password
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

SQLALCHEMY_POOL_SIZE=50
SQLALCHEMY_MAX_OVERFLOW=100
SQLALCHEMY_POOL_RECYCLE=3600
SQLALCHEMY_POOL_PRE_PING=true

# Redis
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_DB=0
CELERY_BROKER_URL=redis://redis:6379/1

# Celery
CELERY_WORKER_AMOUNT=8
CELERY_AUTO_SCALE=false

# 上传限制
UPLOAD_FILE_SIZE_LIMIT=100
NGINX_CLIENT_MAX_BODY_SIZE=100M

# 向量数据库示例
VECTOR_STORE=qdrant
QDRANT_URL=http://qdrant:6333
QDRANT_API_KEY=

# 站点地址
CONSOLE_WEB_URL=https://dify.example.com
CONSOLE_API_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com
APP_API_URL=https://dify.example.com

如果你使用 PgBouncer，数据库连接地址应该指向 PgBouncer，而不是 PostgreSQL 本身。例如：

DB_HOST=pgbouncer
DB_PORT=6432

九、PgBouncer 配置示例

在高并发环境中，强烈建议增加 PgBouncer。下面是一份简化配置示例。

`pgbouncer.ini`

[databases]
dify = host=db port=5432 dbname=dify user=dify password=dify_secure_password

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432

auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt

pool_mode = transaction
max_client_conn = 1000
default_pool_size = 50
min_pool_size = 10
reserve_pool_size = 20
reserve_pool_timeout = 5

server_idle_timeout = 600
server_lifetime = 3600
query_timeout = 300
idle_transaction_timeout = 300

admin_users = dify
stats_users = dify

log_connections = 1
log_disconnections = 1
log_pooler_errors = 1

`userlist.txt`

"dify" "dify_secure_password"

实际生产中，userlist.txt 建议使用 md5 加密密码，而不是明文密码。

十、限流与保护策略

高并发不等于无限制放开请求。对于 Dify 这类依赖大模型接口的平台来说，合理限流非常重要。

1. Nginx 限流

可以在 Nginx 中增加限流策略：

http {
    limit_req_zone $binary_remote_addr zone=dify_api_limit:10m rate=10r/s;

    server {
        location /v1/ {
            limit_req zone=dify_api_limit burst=20 nodelay;
            proxy_pass http://dify_api;
        }
    }
}

这表示单个 IP 平均每秒最多 10 个请求，允许短时间突发 20 个请求。

2. 应用层限流

对于面向外部客户的 Dify 应用，建议按以下维度做限制：

按用户限流；
按 API Key 限流；
按应用限流；
按租户限流；
按模型调用次数限流；
按 Token 消耗量限流。

这样可以防止某个用户或某个应用消耗过多资源，影响整体服务稳定性。

3. 大模型接口限流

很多大模型服务商本身就有 QPS、TPM、RPM 限制。例如 OpenAI、Azure OpenAI、通义千问、DeepSeek、Claude 等都会对调用频率进行限制。Dify 的并发能力再强，如果上游模型接口限速，也会导致请求等待或失败。

建议做以下处理：

多模型供应商冗余；
同模型多 Key 轮询；
请求失败自动重试；
对非核心场景使用更便宜、更快的模型；
设置超时时间和降级回复；
对高频固定问题做缓存。

十一、知识库问答场景的专项优化

Dify 的高并发往往集中在知识库问答场景。下面给出几个非常实用的优化建议。

1. 控制分段大小

文档分段过小，会导致向量数量暴增，检索成本增加；分段过大，又会影响召回质量。一般建议从以下范围开始测试：

chunk_size：500 ~ 1000 tokens
chunk_overlap：50 ~ 150 tokens

2. 控制 top_k

top_k 越大，召回内容越多，但检索和 rerank 成本也越高。生产环境可以从：

top_k = 3 ~ 5

开始测试，不建议无脑设置为 10、20 甚至更高。

3. 谨慎使用 Rerank

Rerank 可以提升知识库召回质量，但也会增加一次模型调用或额外计算。如果你的并发压力较大，可以：

只在重要应用中开启 rerank；
对小知识库关闭 rerank；
使用本地轻量级 rerank 模型；
对检索结果做缓存。

4. 做热点问题缓存

企业知识库问答中，很多问题其实是重复的，例如：

如何申请报销？
VPN 怎么配置？
忘记密码怎么办？
发票抬头是什么？
请假流程是什么？

对于这类问题，可以在业务层增加缓存，将问题标准化后缓存回答结果，减少大模型调用和向量检索压力。

十二、监控指标建议

没有监控，就无法判断优化是否有效。建议至少监控以下指标：

1. API 服务指标

请求 QPS；
平均响应时间；
P95 / P99 响应时间；
HTTP 4xx / 5xx 数量；
Gunicorn Worker 使用情况；
容器 CPU / 内存。

2. Celery 指标

队列长度；
任务成功数；
任务失败数；
任务平均耗时；
Worker 存活数量；
Worker CPU / 内存。

3. Redis 指标

used_memory；
connected_clients；
instantaneous_ops_per_sec；
blocked_clients；
keyspace_hits / keyspace_misses；
evicted_keys。

4. PostgreSQL 指标

当前连接数；
慢查询；
TPS；
锁等待；
缓存命中率；
表膨胀情况；
CPU、IO、磁盘空间。

5. 模型调用指标

模型请求数；
模型平均响应时间；
Token 消耗；
模型错误率；
限流次数；
超时次数。

推荐使用 Prometheus + Grafana，也可以结合云厂商监控、ELK、Loki、OpenTelemetry 等方案。

十三、压测方法与容量评估

在上线前，建议对 Dify 应用进行压测。压测不只是看 QPS，还要关注完整链路耗时。

可以使用以下工具：

JMeter；
Locust；
k6；
wrk；
hey。

对于 Chat API，建议模拟真实用户行为，而不是简单请求一个健康检查接口。例如：

1. 用户发起问题；
2. Dify 执行知识库检索；
3. 调用大模型；
4. 返回流式结果；
5. 用户间隔数秒后继续提问。

容量评估时可以关注：

最大并发用户数
平均响应时间
P95 响应时间
错误率
Worker 队列堆积速度
数据库连接数
Redis 内存增长
模型接口限流情况

一个常见的经验是：Dify 平台本身的 API 层通常不是唯一瓶颈，真正的瓶颈往往在大模型接口、知识库检索、数据库连接和异步任务队列。

十四、推荐落地方案

如果你的团队刚开始生产化使用 Dify，可以按以下阶段推进。

阶段一：小规模生产环境

适合内部几十人使用。

服务器：8 核 16G
API 实例：2 个
Worker：1 ~ 2 个
Redis：单实例
PostgreSQL：单实例
向量库：单实例
Nginx：单实例

阶段二：中等并发环境

适合企业内部数百人或外部中小流量应用。

API 实例：3 ~ 5 个
Worker：3 ~ 6 个
Redis：独立部署
PostgreSQL：独立部署 + PgBouncer
向量库：独立部署
对象存储：S3 / MinIO
Nginx 或云负载均衡

阶段三：高并发生产环境

适合公开服务、客服系统、大规模知识库问答。

Kubernetes 部署
API 自动扩缩容
Worker 按队列拆分
Redis Sentinel / Redis Cluster
PostgreSQL 主从 + PgBouncer
向量数据库集群
对象存储独立化
Prometheus + Grafana 监控
日志集中采集
多模型供应商容灾

十五、总结

Dify 高并发优化的核心不是简单地“调大并发参数”，而是要从架构层面拆解瓶颈：实时 API 请求、异步任务处理、数据库连接、Redis 队列、向量检索、大模型调用，每一层都可能成为影响系统稳定性的关键因素。

对于生产环境，建议优先做到以下几点：

API 多实例部署，通过 Nginx 或负载均衡分发请求；
Worker 独立扩容，避免后台任务影响实时请求；
Redis、PostgreSQL、向量数据库独立部署；
使用 PgBouncer 缓解数据库连接压力；
合理配置 Gunicorn、Celery、数据库连接池；
针对知识库问答优化 top_k、分段、rerank；
增加限流、缓存、降级机制；
建立完善的监控和压测体系。

只要按照以上思路逐步优化，Dify 完全可以支撑从内部工具到企业级 AI 应用平台的生产使用需求。真正稳定的高并发系统，依赖的不是某一个“神奇参数”，而是一套可观测、可扩展、可治理的完整工程体系。

文章标签： Dify高并发横向扩容数据库连接池负载均衡

上一篇：Dify 扛不住并发？这套异步队列方案直接落地，源码也给你了

下一篇：用 Docker 把复杂 AI 应用打包上线：从私有大模型到知识库的一键部署实践

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们

Dify 扛不住并发？从 API 到 Worker 的生产级优化方案附配置示例

Dify 高并发解决方案｜附配置文件

一、Dify 高并发场景下的常见问题

1. API 响应变慢

2. Celery Worker 任务堆积

3. Redis 压力过大

4. PostgreSQL 数据库连接不足

5. 向量数据库压力增加

二、Dify 高并发优化的整体思路

三、核心组件优化建议

1. API 服务优化

2. Celery Worker 优化

3. Redis 优化

4. PostgreSQL 优化

增加最大连接数

使用 PgBouncer

调整内存参数

5. 向量数据库优化

四、推荐的高并发 Docker Compose 配置

五、Nginx 负载均衡配置

六、Redis 配置文件示例

七、PostgreSQL 配置文件示例

八、环境变量配置示例

九、PgBouncer 配置示例

pgbouncer.ini

userlist.txt

十、限流与保护策略

1. Nginx 限流

2. 应用层限流

3. 大模型接口限流

十一、知识库问答场景的专项优化

1. 控制分段大小

2. 控制 top_k

3. 谨慎使用 Rerank

4. 做热点问题缓存

十二、监控指标建议

1. API 服务指标

2. Celery 指标

3. Redis 指标

4. PostgreSQL 指标

5. 模型调用指标

十三、压测方法与容量评估

十四、推荐落地方案

阶段一：小规模生产环境

阶段二：中等并发环境

阶段三：高并发生产环境

十五、总结

`pgbouncer.ini`

`userlist.txt`