Coze 并发扛不住？从扩容、限流到压测的一套实战方案

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

Coze 高并发解决方案｜附完整命令

在企业内部落地 Coze、Coze Studio 或基于 Coze 能力构建智能体平台时，很多团队一开始关注的是“能不能跑起来”，但当业务真正上线后，问题很快会变成：“并发上来以后，系统能不能稳定扛住？”

尤其是以下场景非常常见：

多个业务部门同时调用智能体；
Web 端、企微、飞书、钉钉、小程序等多个入口同时接入；
高峰期大量用户同时发起对话；
智能体中包含知识库检索、插件调用、工作流编排；
接入大模型后，单次请求耗时较长，导致连接长期占用；
后端服务、数据库、Redis、网关、模型接口任一环节成为瓶颈。

因此，Coze 的高并发优化不能只看某一个点，而应该从架构设计、服务扩容、网关限流、缓存优化、数据库调优、队列削峰、系统参数、监控压测等多个维度一起处理。

本文将给出一套相对完整的 Coze 高并发解决方案，并附带常用命令，便于在测试环境和生产环境中逐步落地。

一、Coze 高并发的核心瓶颈在哪里？

在正式优化之前，必须先理解 Coze 类平台在高并发下容易出现的瓶颈。

一个典型请求链路如下：

用户请求
  ↓
Nginx / API Gateway
  ↓
Coze Web / API 服务
  ↓
鉴权、会话、智能体编排
  ↓
知识库检索 / 工作流 / 插件调用
  ↓
Redis / 数据库 / 向量库
  ↓
大模型 API 或本地模型服务
  ↓
结果流式返回

高并发下常见问题包括：

瓶颈位置	典型表现
Nginx	连接数打满、请求排队、502/504
Coze 服务	CPU 高、内存上涨、接口响应变慢
数据库	慢查询、连接数耗尽、锁等待
Redis	QPS 过高、内存不足、命中率低
大模型服务	响应慢、限流、超时
知识库检索	向量检索耗时高、召回慢
插件/工作流	第三方接口拖慢整体响应
系统资源	文件句柄不足、端口耗尽、线程阻塞

所以，高并发方案的目标不是简单“加机器”，而是做到：

入口层可控：能限流、能熔断、能降级；
服务层可横向扩展：Coze 服务可以多副本部署；
状态层外置：会话、缓存、任务状态放到 Redis 或数据库；
慢任务异步化：耗时操作通过队列削峰；
数据库可承压：连接池、索引、读写分离、慢查询治理；
模型调用可治理：超时、重试、并发控制、流式输出；
可观测性完善：有监控、有日志、有压测数据。

二、推荐高并发架构

推荐的生产架构如下：

                 ┌────────────────────┐
                 │   用户 / 业务系统    │
                 └─────────┬──────────┘
                           │
                           ▼
                 ┌────────────────────┐
                 │ Nginx / SLB / 网关   │
                 │ 限流 / 负载均衡 / TLS │
                 └─────────┬──────────┘
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
 ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
 │ Coze API 实例 1 │ │ Coze API 实例 2 │ │ Coze API 实例 N │
 └───────┬────────┘ └───────┬────────┘ └───────┬────────┘
         │                  │                  │
         └──────────────────┼──────────────────┘
                            ▼
                  ┌──────────────────┐
                  │ Redis Cluster     │
                  │ 缓存 / 会话 / 限流 │
                  └──────────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ PostgreSQL/MySQL  │
                  │ 主从 / 连接池      │
                  └──────────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ 向量库 / ES / MQ   │
                  │ 检索 / 异步任务     │
                  └──────────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ LLM 服务 / API     │
                  └──────────────────┘

这套架构的关键点是：

Nginx 负责入口层负载均衡、超时控制、限流；
Coze 服务多实例部署，支持横向扩容；
Redis 作为共享缓存、会话和限流组件；
数据库独立部署，并进行连接数和索引优化；
模型调用设置超时和最大并发；
知识库检索、插件调用、长耗时任务尽量异步化；
全链路加监控和压测。

三、系统基础优化

高并发部署前，建议先对 Linux 系统做基础参数优化。

1. 查看当前系统限制

ulimit -a

重点关注：

open files
max user processes

如果文件句柄太小，高并发连接下容易出现：

too many open files

2. 临时提高文件句柄限制

ulimit -n 65535

该命令只对当前 shell 生效，重启后会失效。

3. 永久修改 limits.conf

sudo vim /etc/security/limits.conf

追加：

* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535

4. 修改 systemd 默认限制

sudo vim /etc/systemd/system.conf

增加或修改：

DefaultLimitNOFILE=65535
DefaultLimitNPROC=65535

继续修改：

sudo vim /etc/systemd/user.conf

增加：

DefaultLimitNOFILE=65535
DefaultLimitNPROC=65535

重新加载：

sudo systemctl daemon-reexec

5. 内核网络参数优化

编辑 sysctl 配置：

sudo vim /etc/sysctl.conf

追加：

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535

net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_tw_reuse = 1

net.ipv4.ip_local_port_range = 1024 65535

fs.file-max = 1048576

使配置生效：

sudo sysctl -p

查看是否生效：

sysctl net.core.somaxconn
sysctl fs.file-max

四、使用 Docker Compose 部署并扩容 Coze 服务

很多团队会采用 Docker Compose 方式部署 Coze 或 Coze Studio。下面以 Docker Compose 为例，说明如何做高并发扩容。

注意：不同 Coze 版本的服务名称可能不同，例如 coze-server、coze-api、coze-web、backend 等。实际操作时请以你的 docker-compose.yml 中服务名为准。

1. 查看服务

docker compose ps

或旧版本 Docker：

docker-compose ps

查看当前容器资源占用：

docker stats

2. 查看 compose 服务名称

docker compose config --services

示例输出：

coze-web
coze-api
redis
postgres
nginx

3. 扩容 API 服务实例

假设服务名为 coze-api，可以执行：

docker compose up -d --scale coze-api=3

如果需要扩容到 5 个实例：

docker compose up -d --scale coze-api=5

查看扩容结果：

docker compose ps

4. 扩容后查看日志

docker compose logs -f coze-api

查看最近 200 行：

docker compose logs --tail=200 coze-api

5. 重启指定服务

docker compose restart coze-api

6. 完整重启

docker compose down
docker compose up -d

7. 清理异常容器

docker ps -a
docker rm

8. 清理无用镜像和缓存

docker system prune -f

如果需要清理未使用镜像：

docker image prune -a -f

五、Nginx 负载均衡配置

当 Coze API 扩容为多个实例后，需要通过 Nginx 做负载均衡。

1. 示例 Nginx 配置

编辑配置文件：

sudo vim /etc/nginx/conf.d/coze.conf

示例：

upstream coze_api {
    least_conn;
    server 127.0.0.1:8001 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8002 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8003 max_fails=3 fail_timeout=30s;
    keepalive 128;
}

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

    client_max_body_size 50m;

    access_log /var/log/nginx/coze_access.log;
    error_log  /var/log/nginx/coze_error.log;

    location / {
        proxy_pass http://coze_api;

        proxy_http_version 1.1;
        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;

        proxy_connect_timeout 10s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;

        proxy_buffering off;
    }
}

说明：

least_conn：优先把请求转发给连接数较少的实例；
keepalive 128：开启 upstream 长连接；
proxy_read_timeout 300s：适合大模型流式响应；
proxy_buffering off：适合 SSE / 流式输出。

2. 检查 Nginx 配置

sudo nginx -t

3. 重新加载 Nginx

sudo systemctl reload nginx

4. 查看 Nginx 状态

sudo systemctl status nginx

5. 查看访问日志

tail -f /var/log/nginx/coze_access.log

6. 查看错误日志

tail -f /var/log/nginx/coze_error.log

六、Nginx 限流与熔断配置

高并发系统不能只追求“无限接收请求”，还要保护后端。入口层限流非常重要。

1. 按 IP 限流

在 http 块中增加：

limit_req_zone $binary_remote_addr zone=coze_ip_limit:20m rate=10r/s;

在 server 或 location 中增加：

limit_req zone=coze_ip_limit burst=30 nodelay;

完整示例：

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

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

        location / {
            limit_req zone=coze_ip_limit burst=30 nodelay;

            proxy_pass http://coze_api;
        }
    }
}

含义：

单个 IP 平均每秒 10 个请求；
突发请求最多允许 30 个；
超过后直接限制，避免压垮后端。

2. 限制连接数

在 http 块中增加：

limit_conn_zone $binary_remote_addr zone=coze_conn_limit:20m;

在 location 中增加：

limit_conn coze_conn_limit 20;

示例：

location / {
    limit_conn coze_conn_limit 20;
    proxy_pass http://coze_api;
}

3. 对模型对话接口单独限流

如果对话接口路径为 /api/chat，可以单独配置：

location /api/chat {
    limit_req zone=coze_ip_limit burst=10 nodelay;
    limit_conn coze_conn_limit 5;

    proxy_pass http://coze_api;

    proxy_read_timeout 300s;
    proxy_buffering off;
}

这样可以避免单个用户或单个业务方疯狂调用大模型接口。

七、Redis 优化

Redis 通常用于缓存、会话、限流计数、任务状态等。高并发场景下 Redis 必须单独关注。

1. 查看 Redis 状态

如果 Redis 在 Docker 中：

docker compose exec redis redis-cli info

查看内存：

docker compose exec redis redis-cli info memory

查看连接数：

docker compose exec redis redis-cli info clients

查看慢日志：

docker compose exec redis redis-cli slowlog get 10

2. 设置最大内存与淘汰策略

进入 Redis：

docker compose exec redis redis-cli

执行：

CONFIG SET maxmemory 4gb
CONFIG SET maxmemory-policy allkeys-lru

持久化配置建议写入 redis.conf：

maxmemory 4gb
maxmemory-policy allkeys-lru

常用淘汰策略：

策略	说明
noeviction	内存满后拒绝写入
allkeys-lru	所有 key 中淘汰最近最少使用
volatile-lru	只在设置过过期时间的 key 中淘汰
allkeys-random	随机淘汰
volatile-ttl	优先淘汰快过期的 key

高并发缓存场景通常推荐：

maxmemory-policy allkeys-lru

3. Redis 连接数优化

查看最大连接数：

docker compose exec redis redis-cli CONFIG GET maxclients

设置最大连接数：

docker compose exec redis redis-cli CONFIG SET maxclients 10000

如果 Redis 报错：

max number of clients reached

说明客户端连接数打满，需要：

提高 maxclients；
优化服务端连接池；
避免频繁创建短连接；
做 Redis 集群或主从拆分。

八、数据库优化

Coze 后端通常会依赖 PostgreSQL 或 MySQL。数据库是高并发系统最常见的瓶颈之一。

下面以 PostgreSQL 为例。

1. 查看数据库连接数

进入容器：

docker compose exec postgres psql -U postgres

查看当前连接：

SELECT count(*) FROM pg_stat_activity;

查看各状态连接数：

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;

查看长时间运行 SQL：

SELECT pid, now() - pg_stat_activity.query_start AS duration, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

2. 查看最大连接数

SHOW max_connections;

3. 修改 PostgreSQL 最大连接数

找到配置文件位置：

SHOW config_file;

退出数据库：

\q

编辑配置文件，例如：

sudo vim /path/to/postgresql.conf

修改：

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

重启 PostgreSQL：

docker compose restart postgres

再次确认：

docker compose exec postgres psql -U postgres -c "SHOW max_connections;"

4. 查慢 SQL

SELECT
    query,
    calls,
    total_exec_time,
    mean_exec_time,
    rows
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 20;

如果没有 pg_stat_statements，需要启用扩展：

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

并在 postgresql.conf 中配置：

shared_preload_libraries = 'pg_stat_statements'

重启数据库后生效。

5. 建索引

查看某条 SQL 的执行计划：

EXPLAIN ANALYZE
SELECT * FROM your_table WHERE bot_id = 'xxx' AND created_at > now() - interval '7 days';

创建索引示例：

CREATE INDEX idx_your_table_bot_id_created_at
ON your_table(bot_id, created_at);

索引建议：

高频查询字段必须建索引；
组合查询优先考虑联合索引；
避免对索引字段使用函数；
定期清理无用索引；
避免一次查询返回过多数据。

九、连接池配置

在高并发环境中，数据库连接不能无限创建。建议使用连接池，例如 PgBouncer。

1. 安装 PgBouncer

Ubuntu / Debian：

sudo apt update
sudo apt install -y pgbouncer

CentOS / Rocky Linux：

sudo yum install -y pgbouncer

2. PgBouncer 配置示例

编辑：

sudo vim /etc/pgbouncer/pgbouncer.ini

示例：

[databases]
coze = host=127.0.0.1 port=5432 dbname=coze

[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 = 2000
default_pool_size = 50
reserve_pool_size = 20
reserve_pool_timeout = 5

server_idle_timeout = 60
server_lifetime = 3600

3. 配置用户

编辑：

sudo vim /etc/pgbouncer/userlist.txt

示例：

"coze_user" "md5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

4. 启动 PgBouncer

sudo systemctl enable pgbouncer
sudo systemctl restart pgbouncer
sudo systemctl status pgbouncer

5. Coze 数据库连接地址改为 PgBouncer

原来：

DATABASE_URL=postgres://coze_user:password@postgres:5432/coze

改为：

DATABASE_URL=postgres://coze_user:password@pgbouncer:6432/coze

然后重启 Coze 服务：

docker compose restart coze-api

十、模型调用并发控制

大模型调用是 Coze 高并发中最特殊的环节。因为模型请求通常具有：

单次响应时间长；
token 输出耗时高；
API 有 QPS 或 TPM 限制；
流式输出连接占用时间长；
失败重试可能放大流量。

因此建议做以下控制。

1. 设置超时时间

示例环境变量：

LLM_CONNECT_TIMEOUT=10
LLM_READ_TIMEOUT=300
LLM_WRITE_TIMEOUT=30

如果服务支持 HTTP 客户端连接池，可以配置：

LLM_MAX_IDLE_CONNECTIONS=200
LLM_MAX_CONNECTIONS=1000
LLM_KEEPALIVE_TIMEOUT=60

2. 控制模型并发

例如：

LLM_MAX_CONCURRENCY=100
LLM_QUEUE_SIZE=1000

含义：

同时最多 100 个请求进入模型调用；
超过后进入队列；
队列满后快速失败或返回排队提示。

3. 不建议无限重试

错误示例：

失败后立即重试 3 次

这会在高峰期进一步放大流量。

推荐策略：

首次失败：等待 200ms
第二次失败：等待 500ms
第三次失败：等待 1000ms
超过次数：返回失败或降级结果

4. 对不同模型设置不同并发

例如：

GPT4_MAX_CONCURRENCY=20
GPT4O_MINI_MAX_CONCURRENCY=200
LOCAL_MODEL_MAX_CONCURRENCY=50

昂贵或慢模型应限制更严格，轻量模型可承载更多并发。

十一、知识库检索优化

如果 Coze 智能体依赖知识库，知识库检索也会成为瓶颈。

1. 控制召回数量

不要盲目召回过多内容。例如：

KNOWLEDGE_TOP_K=5
KNOWLEDGE_MAX_CHUNK_SIZE=800
KNOWLEDGE_SCORE_THRESHOLD=0.65

如果召回 20 条，每条 2000 字，不仅检索慢，还会增加模型上下文长度，导致响应更慢、成本更高。

2. 使用缓存

对于高频问题，可以缓存检索结果：

cache_key = bot_id + query_hash + knowledge_version

缓存时间可以设置为：

KNOWLEDGE_CACHE_TTL=300

也就是 5 分钟。

3. 热点知识预加载

对于客服机器人、内部问答机器人，常见问题往往集中在少数主题。可以对热点问题提前做缓存。

示例 Redis 写入：

docker compose exec redis redis-cli SET "kb:hot:question:001" "cached result" EX 600

查询：

docker compose exec redis redis-cli GET "kb:hot:question:001"

十二、异步队列削峰

高并发场景下，并不是所有任务都适合同步处理。以下任务建议异步化：

知识库文档解析；
文件上传后的切片和向量化；
批量消息通知；
插件长耗时调用；
日志分析；
对话摘要生成；
离线报表统计。

可以使用 Redis Stream、RabbitMQ、Kafka 等。

1. Redis Stream 简单示例

创建任务：

docker compose exec redis redis-cli XADD coze:task:queue '*' type embedding doc_id 10001

读取任务：

docker compose exec redis redis-cli XREAD COUNT 10 BLOCK 5000 STREAMS coze:task:queue 0

创建消费者组：

docker compose exec redis redis-cli XGROUP CREATE coze:task:queue coze-workers 0 MKSTREAM

消费者读取：

docker compose exec redis redis-cli XREADGROUP GROUP coze-workers worker-1 COUNT 10 BLOCK 5000 STREAMS coze:task:queue '>'

确认任务完成：

docker compose exec redis redis-cli XACK coze:task:queue coze-workers

2. 队列削峰原则

前端请求只提交任务，不等待任务完成；
后台 Worker 按能力消费；
队列长度超过阈值时提示用户排队；
任务处理结果写入 Redis 或数据库；
长任务必须支持失败重试和幂等。

十三、Docker 资源限制与优化

高并发环境中，容器不能完全无限制使用宿主机资源，否则某个容器异常可能拖垮整台机器。

1. 查看容器资源

docker stats

2. Docker Compose 设置资源限制

示例：

services:
  coze-api:
    image: your-coze-api-image
    restart: always
    environment:
      - NODE_ENV=production
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 4G
        reservations:
          cpus: "1"
          memory: 2G

注意：deploy.resources 在普通 Docker Compose 和 Swarm 中行为可能不同。如果普通 Compose 不生效，可以使用：

services:
  coze-api:
    image: your-coze-api-image
    restart: always
    cpus: 2
    mem_limit: 4g

重启：

docker compose up -d

3. 查看容器日志大小

docker inspect  | grep LogPath

4. 限制日志大小

在 docker-compose.yml 中配置：

services:
  coze-api:
    image: your-coze-api-image
    logging:
      driver: json-file
      options:
        max-size: "500m"
        max-file: "3"

避免日志无限增长撑爆磁盘。

十四、监控与告警

没有监控的高并发系统，无法判断瓶颈在哪里。建议至少监控以下指标：

1. 系统指标

CPU 使用率；
内存使用率；
磁盘空间；
磁盘 IO；
网络流量；
文件句柄数量。

查看 CPU 和内存：

top

或：

htop

查看磁盘：

df -h

查看 IO：

iostat -x 1

安装工具：

sudo apt install -y htop sysstat

2. Docker 指标

docker stats

3. Nginx 指标

查看访问量：

awk '{print $1}' /var/log/nginx/coze_access.log | sort | uniq -c | sort -nr | head

查看状态码分布：

awk '{print $9}' /var/log/nginx/coze_access.log | sort | uniq -c | sort -nr

查看慢请求：

awk '$10 > 1000000 {print}' /var/log/nginx/coze_access.log | head

4. Redis 指标

docker compose exec redis redis-cli info

重点看：

used_memory
connected_clients
instantaneous_ops_per_sec
keyspace_hits
keyspace_misses
evicted_keys

5. PostgreSQL 指标

SELECT count(*) FROM pg_stat_activity;

查看慢查询、锁等待：

SELECT
    blocked_locks.pid AS blocked_pid,
    blocked_activity.query AS blocked_query,
    blocking_locks.pid AS blocking_pid,
    blocking_activity.query AS blocking_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity
    ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
    ON blocking_locks.locktype = blocked_locks.locktype
JOIN pg_catalog.pg_stat_activity blocking_activity
    ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;

十五、压测方案

优化完成后必须压测，不能凭感觉上线。

1. 使用 wrk 压测普通接口

安装：

sudo apt update
sudo apt install -y wrk

压测：

wrk -t4 -c200 -d60s http://coze.example.com/health

参数说明：

-t4：4 个线程；
-c200：200 个并发连接；
-d60s：持续 60 秒。

2. 压测 POST 接口

创建 Lua 脚本：

vim post.lua

内容：

wrk.method = "POST"
wrk.headers["Content-Type"] = "application/json"
wrk.body = '{"message":"你好，请简单介绍一下你自己"}'

执行：

wrk -t4 -c100 -d60s -s post.lua http://coze.example.com/api/chat

3. 使用 hey 压测

安装：

wget https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64
chmod +x hey_linux_amd64
sudo mv hey_linux_amd64 /usr/local/bin/hey

GET 压测：

hey -n 10000 -c 200 http://coze.example.com/health

POST 压测：

hey -n 1000 -c 50 \
  -m POST \
  -H "Content-Type: application/json" \
  -d '{"message":"你好"}' \
  http://coze.example.com/api/chat

4. 压测时观察指标

压测期间同时观察：

docker stats

tail -f /var/log/nginx/coze_error.log

docker compose exec redis redis-cli info clients

docker compose exec postgres psql -U postgres -c "SELECT count(*) FROM pg_stat_activity;"

重点关注：

P95 / P99 延迟；
QPS；
错误率；
CPU 是否打满；
内存是否持续增长；
数据库连接是否耗尽；
Redis 是否有大量 key 淘汰；
Nginx 是否出现 502、504。

十六、生产环境推荐参数

下面给出一组常见生产环境参考参数，实际需要根据机器配置和业务压测结果调整。

1. Nginx 推荐

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 65535;
    multi_accept on;
    use epoll;
}

http {
    keepalive_timeout 65;
    client_max_body_size 50m;

    proxy_connect_timeout 10s;
    proxy_send_timeout 300s;
    proxy_read_timeout 300s;

    limit_req_zone $binary_remote_addr zone=coze_ip_limit:20m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=coze_conn_limit:20m;
}

2. Redis 推荐

maxclients 10000
maxmemory 4gb
maxmemory-policy allkeys-lru
timeout 0
tcp-keepalive 300

3. PostgreSQL 推荐

max_connections = 300
shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
checkpoint_completion_target = 0.9

4. Coze API 推荐

APP_ENV=production
LOG_LEVEL=info

DB_POOL_MIN=10
DB_POOL_MAX=50
REDIS_POOL_SIZE=100

LLM_CONNECT_TIMEOUT=10
LLM_READ_TIMEOUT=300
LLM_MAX_CONCURRENCY=100
LLM_QUEUE_SIZE=1000

KNOWLEDGE_TOP_K=5
KNOWLEDGE_CACHE_TTL=300

十七、上线前检查清单

上线前建议逐项确认：

[ ] Coze API 至少 2 个实例；
[ ] Nginx 已配置 upstream 负载均衡；
[ ] Nginx 已配置超时、限流、连接数限制；
[ ] Redis 设置了最大内存和淘汰策略；
[ ] 数据库连接数合理；
[ ] 数据库高频查询已建索引；
[ ] 模型调用设置了超时和最大并发；
[ ] 长耗时任务已异步化；
[ ] Docker 日志已限制大小；
[ ] Linux 文件句柄已调整；
[ ] 已完成压测；
[ ] 已配置监控和告警；
[ ] 已准备回滚方案。

十八、常见故障与处理

1. 出现 502

可能原因：

Coze API 容器挂了；
Nginx upstream 地址错误；
后端端口未监听；
服务启动慢。

排查命令：

docker compose ps
docker compose logs --tail=100 coze-api
sudo tail -f /var/log/nginx/coze_error.log

2. 出现 504