先说重点：在Dify高并发场景下，PostgreSQL单节点写入瓶颈会直接拖垮API Server的响应速度。用户提交Prompt后长时间无返回、知识库同步卡死、会话历史查询超时——这些问题背后，根因往往只有一个：读写没有分离。
读请求（如会话列表、应用配置拉取、日志查询）与写请求（如新对话创建、Prompt保存、用户操作记录）必须物理分离到不同数据库实例。通过pgBouncer或应用层路由实现PostgreSQL读写分离，主库处理写请求，从库分担读负载，在同步延迟与权限配置修复到位后，即可解决上述高并发顽疾。
确认PostgreSQL主从集群已就绪
进入PostgreSQL主节点容器，执行一条简单命令：psql -U dify -d dify -c "SELECT pg_is_in_recovery();"。返回f表示主库，返回t表示从库。如果所有节点都返回f，说明流复制根本没生效——必须先修复Patroni或pg_basebackup的同步状态，否则后续配置全部白搭。
接下来检查从库延迟：SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;。延迟超过5秒，这台从库暂时不可用，别急着往里扔读流量。
权限方面也别忘了：主从节点的pg_hba.conf中，必须为Dify服务IP段配置trust或md5访问权限，否则连接都会被拒。
修改Dify服务连接策略
Dify并不原生支持多数据源路由。想实现读写分离，只能借助外部连接池层——推荐方案是pgBouncer加自定义规则，而不是直接改Dify源码。
方法一：pgBouncer配置读写分离规则
编辑pgbouncer.ini，在[databases]节下添加两条记录：
dify_ro = host=postgres-sla ve-1 port=5432 dbname=dify pool_mode=transaction
dify_rw = host=postgres-master port=5432 dbname=dify pool_mode=transaction
然后在[users]节中为Dify应用分配专用用户，格式类似"dify" "md5..."，密码哈希值必须与PostgreSQL中一致。
关键点在于：Dify的DATABASE_URL环境变量要指向pgBouncer监听地址，而不是直接连PostgreSQL。举个例子：postgresql://dify:secret@pgbouncer:6432/dify_rw——这样一来，所有连接默认走写库。
方法二：应用层动态路由（需少量代码注入）
在Dify API服务启动前，重写sqlalchemy.create_engine逻辑。定位到dify-api/app/core/db.py，在get_db函数中插入判断：
if request.endpoint in ["get_conversation_list", "list_applications", "get_logs"]:
return create_engine(os.getenv("DATABASE_URL_RO"))
else:
return create_engine(os.getenv("DATABASE_URL_RW"))
这种方式需要配合Nginx或Kubernetes Service做endpoint识别，同时DATABASE_URL_RO和DATABASE_URL_RW必须分别指向从库和主库地址。
强制Dify Worker使用只读连接
第一步，登录Dify Worker容器，执行env | grep DATABASE_URL确认当前连接串指向主库。
第二步，修改docker-compose.yml中dify-worker服务的环境变量：
environment:
- DATABASE_URL=postgresql://dify:secret@postgres-sla ve-1:5432/dify?sslmode=require
第三步，重启Worker服务：docker compose restart dify-worker。
这里有个细节要注意：Worker任务如文档解析、向量入库、邮件发送等绝不能写入从库，但读取用户配置、应用元数据等操作可以安全路由至从库。这一步操作，通常能把主库的读负载降低30%以上。
验证读写分离是否生效
配置完了，怎么确认真正生效？四个验证步骤依次走一遍：
① 在主库执行：SELECT pid, usename, client_addr, backend_start, state, query FROM pg_stat_activity WHERE state = 'active' AND query NOT LIKE '%pg_stat%';。观察活跃连接中，有没有来自dify-worker的INSERT/UPDATE语句——如果有，说明路由配置还有问题。
② 在从库执行同样命令，应该只看到SELECT语句，且client_addr包含Dify Web UI或API服务的IP。
③ 模拟高并发读请求：ab -n 1000 -c 50 "http://localhost/api/v1/applications?limit=20"。同时监控主库pg_stat_database中xact_commit的增速——理想情况下，主库增速应明显低于从库的blks_read增速。
④ 终极测试：故意中断主库网络，比如docker network disconnect docker_default postgres-master。观察Dify Web UI是否仍能加载应用列表——如果能，说明读流量已成功路由到从库；而新建对话接口返回503，说明主库不可用时写操作确实被阻断。
这套配置落地之后，Dify在高并发场景下的表现会有一个质的提升。从实践来看，读写分离带来的改善往往立竿见影，值得花时间把每一步都踩实。