第39章：百万级请求优化与极端场景处理

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 秒。索引已经加了，还是慢。单表扛不住了。”大师：“索引能优化查询，但不能缩小扫描范围。你要的是