我们正在开发一个 Multi-Tenancy 应用程序。关于体系结构，我们设计了用于业务逻辑的共享中间层，并为每个租户设计了一个数据库用于数据持久性。也就是说，业务层将为每个租户与数据库服务器建立一组连接(连接池)。这意味着应用程序为每个租户维护一个单独的连接池。如果我们预期有大约5000个租户，则此解决方案需要较高的资源利用率(每个租户的应用程序服务器和数据库服务器之间的连接)，这会导致性能问题。
我们通过保留公共(public)连接池解决了这一问题。为了在不同数据库之间维护单个连接池，我们创建了一个名为“App-master”的新数据库。现在，我们始终先连接到“App-master”数据库，然后将其更改为租户特定的数据库。这就解决了我们的连接池问题。
该解决方案与本地数据库服务器完美配合。但是它不适用于Azure Sql，因为它不支持更改数据库。
预先提出建议，以建议如何维护连接池或更好的方法/最佳实践，以应对这种 Multi-Tenancy 方案。
最佳答案
在使用带有单独数据库的多个租用方案之前，我已经看到了此问题。有两个重叠的问题。每个租户的Web服务器数量，以及租户总数。第一个是更大的问题-如果您正在通过ADO.net连接池缓存数据库连接，则任何特定客户连接进入与其数据库建立开放连接的Web服务器的可能性与您的Web服务器数量成反比有。扩展越多，由于Web服务器代表他们建立与数据库的初始连接，每个给定的客户将看到更多的每次调用(而不是初始登录)延迟。对非粘性，高扩展性的Web服务器层的每次调用都将越来越不可能找到可重用的现有开放数据库连接。
第二个问题只是您的池中有这么多连接的问题之一，并且这可能造成内存压力或性能下降。
您可以通过建立数量有限的数据库应用程序服务器(简单的WCF端点)来“解决”第一个问题，该服务器代表您的Web服务器执行数据库通信。每个WCF数据库应用程序服务器均服务于一个已知的客户连接池(东部区域转到服务器A，西部区域转到服务器B)，这意味着对于任何给定请求，连接池命中的可能性非常高。这也使您可以分别扩展对数据库的访问以访问HTML呈现Web服务器(数据库是您最关键的性能瓶颈，因此这可能不是一件坏事)。
第二种解决方案是通过NLB路由器使用特定于内容的路由。这些基于内容路由流量，并允许您按客户分组(西部地区，东部地区等)分割Web服务器层，因此，每组Web服务器的事件连接数要少得多，并且获得连接的可能性也会相应增加。开放和未使用的连接。
这两个问题通常都是缓存问题，您将其扩展为完全“不粘手”的体系结构越多，则任何调用访问缓存数据的可能性就越小-无论是缓存数据库连接还是读取缓存数据。管理用户连接以最大可能地导致高速缓存命中将对保持高性能很有用。
关于c# - Multi-Tenancy : Individual database per tenant，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25369077/