避免在 FastAPI 中的请求之间保持内存状态答案

【问题标题】：avoid persisting memory state between requests in FastAPI避免在 FastAPI 中的请求之间保持内存状态
【发布时间】：2022-02-04 01:49:09
【问题描述】：

有没有办法部署FastAPI 应用程序，使内存状态不能在请求之间持久化？目标是避免在多租户应用程序中的请求之间泄露任何数据。

从头开始为每个请求启动应用程序似乎不可行，因为它需要很长时间。有没有一种方法可以为服务的每个实例启动应用程序，但单个请求由工作人员或线程处理，这些工作人员或线程在处理请求后被清除，以便销毁任何静态属性、单例实例等，并且下一个请求是用干净的内存处理？

【问题讨论】：

标签： multi-tenant fastapi worker

【解决方案1】：

FastAPI 默认情况下基本上是无状态的。实际上，通过连接池、从 Redis 读取值等方法跨请求持久化数据需要额外的工作。如果您将启动服务器、加载配置、设置路径重定向等事情视为“状态”，那么 FastAPI 将不适用于您的目的。

当您说“内存状态”时，听起来您正在尝试将 FastAPI 服务器的实例彼此分开，以便它们甚至不使用相同的内存。这不会是一个可行的解决方案，因为大多数 Web 服务器，包括 FastAPI，都不是为这种类型的隔离而设计的。默认情况下，来自一个租户的请求与来自另一个租户的请求没有任何关系，除非您编写额外的代码让它们变得相关；因此分离不同租户的关注点成为程序员的事情，而不是服务器的内存。

相反，如果您绝对不能让来自多个租户的请求驻留在同一内存中，那么您最好在 DNS 级别上为不同的租户提供自己的子域。为它们中的每一个启动一个 VPS 和您的 FastAPI 程序实例。这将真正防止来自一个租户的请求与其他租户共享任何内存或状态。

【讨论】：

与内存状态相关的问题是由 uvicorn 工作人员在重新创建之前被用于多个请求引起的。在后续请求中，单个工作人员可能具有一些内存状态，例如从先前请求中继承的静态或全局变量。这可以通过将 uvicorn 设置为每个请求一个工作人员来避免。由于大量进口，我们目前无法遵循这一点，因为启动工人需要太多时间，但解决方案可能是减少这一点。