必须通过pgBouncer或应用层路由实现PostgreSQL读写分离，主库处理写请求，从库分担读负载，修复同步延迟与权限配置后，可解决Dify高并发下的响应慢、同步卡死等问题。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在Dify高并发场景下，PostgreSQL单节点写入瓶颈会直接拖垮API Server响应速度，用户提交Prompt后长时间无返回、知识库同步卡死、会话历史查询超时等问题频发。必须将读请求（如会话列表、应用配置拉取、日志查询）与写请求（如新对话创建、Prompt保存、用户操作记录）物理分离到不同数据库实例。
确认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-slave-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-slave-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（主库不可用）。
