多租户：每个租户拥有独立的数据库

Question

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

我们通过保持公共连接池来解决这个问题。为了在不同的数据库之间维护单个连接池，我们创建了一个名为“App-master”的新数据库。现在，我们始终首先连接到“App-master”数据库，然后将数据库更改为特定于租户的数据库。这解决了我们的连接池问题。

这个解决方案在本地数据库服务器上完美运行。但在Azure Sql上无法运行，因为它不支持更改数据库。

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

- Hitesh

---

池是根据不同的连接字符串设置的。这意味着如果您有5000个租户，则池大小为5000 * 100个连接（每个连接字符串中的池中有100个连接）。我想知道您所谈论的问题是什么。我们维护几个多租户应用程序，拥有数千个租户，并且没有观察到任何与池相关的问题，这些问题会导致我们进行自定义池实现。 - Wiktor Zychla

我们在Azure中有一个类似的系统，与现有的池化连接相比，初始连接到数据库的时间明显较慢。 - knightpfhor

快速问题：您是直接从云外连接到数据库，还是（大提示）使用Web服务将连接问题牢牢地保持在Azure端？ - SeanCocteau

@WiktorZychla，我们想要澄清一些问题：1. 您的应用程序是否为每个租户维护单独的数据库？2. 您是否在Azure上托管您的应用程序并使用Azure SQL？3. 当您说您有2000个租户时，在最坏的情况下，您的应用程序服务器会打开2000个连接池（这意味着2000x100=200,000个连接）来为所有租户提供服务吗？4. 您看到的峰值内存利用率是多少，每个连接的内存利用率是多少（如果您有这样的数字）？ - Hitesh

@Hitesh：1）是的 2）不是 3）最坏情况下是，但由于有一批服务器，我怀疑池子会达到极限 3）没有数字。 - Wiktor Zychla

Answer 1

我之前在使用多租户的方案和独立数据库时遇到过这个问题。存在两个重叠的问题：每个租户的Web服务器数量和总租户数量。第一个问题更加严重 - 如果你使用ADO.net连接池缓存数据库连接，那么任何特定客户端连接进入已经打开与其数据库的Web服务器的可能性与你拥有的Web服务器数量成反比。你越扩展，任何给定客户端在 Web 服务器为其代表与数据库建立初始连接时会发现单次调用（而不是首次登录）延迟越长。每个通过非粘性高度扩展的 Web 服务器层所做出的调用将逐渐不太可能找到可以重复使用的现有开放数据库连接。

第二个问题只涉及到在连接池中拥有太多连接，并且这样可能会导致内存压力或性能下降。

你可以通过建立一定数量的数据库应用程序服务器（简单的WCF端点）来“解决”第一个问题，以代表Web服务器执行数据库通信。每个WCF数据库应用程序服务器服务于已知的一组客户连接池（东部地区去A服务器，西部地区去B服务器），这意味着任何给定请求的连接池命中率非常高。这还允许你将对数据库的访问与对 HTML 渲染 Web 服务器的访问分开扩展（数据库是最关键的性能瓶颈，所以这可能不是一件坏事）。

第二种解决方案是通过NLB路由使用特定内容的路由。这些根据内容路由流量，并允许你通过客户分组（西部地区，东部地区等）对Web服务器层进行分段，因此每个Web服务器集合具有更少数量的活动连接，相应地增加了获取已打开和未使用连接的可能性。

这两个问题都与缓存有关，你越扩展一个完全“非粘性”的架构，任何调用命中缓存数据的可能性就越小 - 无论是缓存的数据库连接还是读取缓存的数据。管理用户连接以实现最大缓存命中率将有助于保持高性能。

- PhillipH

Answer 2

限制每个应用服务器连接池数量的另一种方法是使用应用程序请求路由（ARR）将您的租户分成子集并将它们分配给 Web 层的子集。这适用于更可扩展的“Pod”架构，其中“Pod”是一小组 Web/App 服务器，与数据库的子集相耦合。关于这种方法的好文章在这里：http://azure.microsoft.com/blog/2013/10/31/application-request-routing-in-csf/

如果您正在构建一个多租户 DB 应用程序 Azure，则还应该查看新的弹性比例客户端库，这些库简化了数据相关路由，并促进了跨 Shard 查询和管理操作。http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-documentation-map/

- Stuart Ozer