1. 项目背景
第 29 章我们从单机 20 QPS 优化到了 500 QPS。但如果你的 Dify 需要支撑日活 100 万用户、峰值 10000 QPS——单机优化已经到天花板了。你需要从架构层面重新设计。
本章围绕五个极端场景给出生产级解决方案：
- 场景一：Message 表 5000 万行，查询越来越慢，单表扛不住了
- 场景二：知识库 100 万篇文档，全量索引耗时 3 天，增量更新怎么做？
- 场景三：10000 QPS 并发，单实例 500 QPS 不够用
- 场景四：LLM Provider 全量限流，所有请求返回 429
- 场景五：某个 AZ 机房断电，服务不能中断
每个场景不仅有代码方案，更有背后的架构思想。
2. 项目设计
小胖：（看着数据库慢查询日志）“大师！Message 表突破 5000 万行，SELECT * FROM messages WHERE conversation_id = 'xxx' ORDER BY created_at DESC LIMIT 20跑了 8 秒。索引已经加了，还是慢。单表扛不住了。”
大师：“索引能优化查询，但不能缩小扫描范围。你要的是<
