多租户：每个租户的单个数据库

Question

我们正在开发一个多租户应用程序。在体系结构方面，我们为业务逻辑设计了共享中间层，为数据持久性设计了每个租户一个数据库。也就是说，业务层将与每个租户的数据库服务器建立一组连接（连接池）。这意味着应用程序为每个租户维护单独的连接池。如果我们预计约有5000个租户，那么这个解决方案需要高资源利用率（每个租户的应用服务器和数据库服务器之间的连接），这会导致性能问题。

我们已经通过保持公共连接池解决了这个问题。为了在不同的数据库中维护单个连接池，我们创建了一个名为App-master的新数据库。现在，我们总是先连接到App-master数据库，然后将数据库更改为租户特定数据库。这解决了我们的连接池问题。

这个解决方案在本地数据库服务器上工作得非常好。但它不适用于Azure Sql，因为它不支持更改数据库。

提前感谢建议如何维护连接池或更好的方法/最佳实践来处理这种多租户场景。

Answer 1

限制每个应用服务器的连接池数量的另一种方法是使用应用程序请求路由（ARR）来划分租户，并将他们分配到web层的子集。这有助于构建一个更具可扩展性的“pod”体系结构，其中“pod”是连接到数据库子集的一小部分web/app服务器的集合。下面是一篇关于这种方法的好文章：http://azure.microsoft.com/blog/2013/10/31/application-request-routing-in-csf/

如果要构建多租户DB应用程序Azure，还应查看新的Elastic Scale客户端库，这些库可简化依赖数据的路由，并促进跨分片查询和管理操作。http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-documentation-map/

Answer 2

我以前在具有独立数据库的多个租赁计划中见过这个问题。有两个重叠的问题；每个租户的网络服务器数量和租户总数。第一个是更大的问题——如果您通过ADO. net连池缓存数据库连接，那么任何特定客户连接进入与他们的数据库有开放连接的网络服务器的可能性与您拥有的网络服务器数量成反比。横向扩展越多，任何给定的客户都会注意到每次呼叫（而不是初始登录）的延迟，因为网络服务器代表他们与数据库进行初始连接。对非粘性、高度扩展的Web服务器层的每次调用都将减少找到可重用的现有开放数据库连接的可能性。

第二个问题只是池中有这么多连接，这可能会造成内存压力或性能差。

您可以通过建立数量有限的数据库应用服务器（简单的WCFendpoint）来“解决”第一个问题，这些服务器代表您的网络服务器进行数据库通信。每个WCF数据库应用程序服务器都服务于已知的客户连接池（东部地区转到服务器A，西部地区转到服务器B），这意味着任何给定请求都有很高的连接池命中可能性。这还允许您单独缩放对数据库的访问，以访问超文本标记语言渲染Web服务器（数据库是您最关键的性能瓶颈，因此这可能不是一件坏事）。

第二种解决方案是通过NLB路由器使用特定于内容的路由。这些服务基于内容路由流量，并允许您按客户分组（西部地区、东部地区等）划分web服务器层，因此每组web服务器的活动连接数要少得多，获得开放和未使用连接的可能性也相应增加。

这两个问题通常都是缓存的问题，作为一个完全“无粘性”的体系结构扩展得越多，任何调用命中缓存数据的可能性就越小——无论是缓存数据库连接还是读取缓存数据。管理用户连接以允许缓存命中的最大可能性对于保持高性能非常有用。