我们正在开发一个多租户应用程序。在架构方面，我们设计了共享中间层用于业务逻辑，每个租户一个数据库用于数据持久化。也就是说，业务层将为每个租户与数据库服务器建立一组连接（连接池）。这意味着应用程序为每个租户维护单独的连接池。如果我们预计大约有 5000 个租户，那么该解决方案需要高资源利用率（每个租户的应用程序服务器和数据库服务器之间的连接），这会导致性能问题。
我们通过保留公共连接池解决了这个问题。为了跨不同数据库维护单个连接池，我们创建了一个名为“App-master”的新数据库。现在，我们总是先连接到“App-master”数据库，然后将数据库更改为租户特定数据库。这解决了我们的连接池问题。
该解决方案与本地数据库服务器完美配合。但它不适用于 Azure Sql，因为它不支持更改数据库。
提前感谢建议如何维护连接池或更好的方法/最佳实践来处理这种多租户场景。
我之前在具有单独数据库的多个租赁方案中见过这个问题。有两个重叠的问题；每个租户的 Web 服务器数量以及租户总数。第一个是更大的问题 - 如果您通过 ADO.net 连接池缓存数据库连接，那么任何特定客户连接进入与其数据库有开放连接的 Web 服务器的可能性与您的 Web 服务器数量成反比。有。扩展得越多，任何给定客户就越会注意到每次调用（而不是初始登录）延迟，因为 Web 服务器代表他们与数据库进行初始连接。对非粘性、高度扩展的 Web 服务器层进行的每次调用找到可重用的现有开放数据库连接的可能性将会降低。
第二个问题只是池中存在如此多的连接，以及这可能会造成内存压力或性能不佳的问题之一。
您可以通过建立有限数量的数据库应用程序服务器（简单的 WCF 端点）来“解决”第一个问题，这些服务器代表您的 Web 服务器执行数据库通信。每个 WCF 数据库应用程序服务器都提供已知的客户连接池（东部区域转到服务器 A，西部区域转到服务器 B），这意味着任何给定请求的连接池命中的可能性非常高。这还允许您单独扩展对数据库的访问以访问 HTML 渲染 Web 服务器（数据库是您最关键的性能瓶颈，因此这可能不是一件坏事）。
第二种解决方案是通过 NLB 路由器使用内容特定路由。这些基于内容路由流量，并允许您按客户分组（西部地区、东部地区等）对 Web 服务器层进行细分，因此每组 Web 服务器的活动连接数量要少得多，获得的可能性相应增加开放且未使用的连接。
这两个问题通常都是缓存问题，作为完全“不粘”的架构横向扩展得越多，任何调用命中缓存数据的可能性就越小 - 无论是缓存的数据库连接还是读取缓存的数据。管理用户连接以允许缓存命中的最大可能性对于保持高性能非常有用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
