💡 灵感来源 (Inspiration)

在构建基于大语言模型（LLM）的应用时，我们发现真正的性能瓶颈往往不在于模型本身，而在于后端系统如何应对海量、高并发的 API 请求。我们希望构建一个 AI 驱动的中间件网关系统，它不仅能智能分配请求，还能高效地处理高并发、缓存常用结果，并保证系统在极端负载下的高可用性。

🏗️ 我们是如何构建项目的 (How we built it)

系统核心架构围绕高并发处理展开，深度结合了多项后端技术方案：

• 流量削峰与异步处理：引入了消息队列（Message Queue）。当用户发起耗时较长的 OpenAI API 请求时，系统将其投入队列进行异步处理，避免阻塞主线程，保障了系统的可靠性与高吞吐量。
• 高并发缓存：使用 Redis 作为核心缓存层。针对频繁查询的相同 Prompt 结果进行缓存，并利用 Redis 的并发模型实现了分布式的限流器（Rate Limiter），有效防止接口被恶意滥用。
• 持久化与查询优化：底层采用 MySQL 存储用户会话与元数据。针对海量历史记录查询，我们对 InnoDB 存储引擎 的联合索引进行了深度优化，避免了全表扫描，将大规模数据检索的延迟降到了最低。
• 内存数据预处理：在内存层面，对流式数据进行清洗时，大量使用了 Map 结构和数组操作。例如，设计了时间复杂度为 $\mathcal{O}(n)$ 的核心算法来快速检索 Map 中的极小值，以及计算数组元素的特征乘积，以最快速度完成传入数据的过滤。

⚠️ 遇到的挑战 (Challenges we ran into)

• 缓存击穿与并发控制：在早期压测中，极端并发下 Redis 的读写出现竞争。我们通过调整锁机制和深入挖掘 Redis 的底层并发处理逻辑，确保了限流状态的绝对一致性。
• 数据库死锁与索引失效：复杂的并发插入导致 InnoDB 偶尔出现死锁。通过重新梳理事务隔离级别和优化 B+ 树的索引命中率，成功排除了隐患。

🧠 学到了什么 (What we learned)

通过这个项目，我们将理论上的后端架构知识真正落地。从 MySQL 的底层索引机制、Redis 的并发模型，到消息队列的容灾保证。这让我们不仅停留在调用 OpenAI API 的应用层，而是更深入地理解了如何为 AI 应用搭建一个坚如磐石的底层分布式系统。

Built With

• docker
• mysql
• openai-api
• python
• rabbitmq
• redis