应用层分片

Question

我正在设计一个多租户系统，考虑在应用程序层面上按租户进行分片，而不是在数据库层面上。理论上，这样应该工作的方式是：对于传入请求，路由器进程具有全局租户集合，其中包含主要属性以确定此请求的租户以及虚拟分片ID。这个虚拟分片ID进一步映射到一个实际的分片。

实际的分片包含了应用程序的代码以及此租户的所有数据。这些分片将是LNMP（Linux、Nginx、MySQL/MongoDB、PHP）服务器。

路由器进程应该充当代理。它应该能够运行一些代码，根据存储在某些本地数据库或文件中的集合来确定传入请求的目标分片。为了更好地扩展这个系统，我考虑让这些分片本身也充当路由器，以便它们可以运行反向代理，将请求转发到适当的分片。也许运行在分片上的nginx实例也可以充当这个反向代理。但是，它将如何执行所需的应用程序逻辑，以将请求与适当的分片匹配起来？

我将感激任何关于这个路由器实现的想法和建议。

谢谢！

- msingla

Answer 1

另一个选择是使用像dbShards这样的产品。 dbShards是唯一在应用程序级别进行分片的分片产品。 这样，您可以使用任何RDMS（Postgres，MySQL等），而无需在中间放置某种代理即可分片数据库。 许多其他分片产品依赖于代理将事务指向正确的分片，但是dbShards知道去哪里而不必“询问”任何其他人。

非常棒的产品。 dbshards

- chantheman

---

dbShards知道去哪里，而不必“询问”任何其他人。它是如何做到的？它是否保留了一个全局集合，例如所有可能的“用户ID->分片实例ID”映射？顺便说一句，链接不再指向网站，因此我猜想截至2020年有其他可用的解决方案，你能推荐哪一个吗？谢谢！ - tonix

Answer 2

除非你期望你的租户生成大致相等的数据量，否则按租户分片将不会非常有效。

至于一般的应用程序级别分片，让我分享一下我的经验：

我们高容量SaaS产品的第1版在应用程序级别上进行了分片。随着业务增长，你会发现如果你在应用程序级别上针对SQL类型的解决方案进行分片，重新分片将是一个主要的头疼问题，或者你将不得不编写重要的工具来自动化这个过程。

我们转向MongoDB（在考虑了多种替代方案包括Cassandra之后）,其中一个很重要的原因是所有内置的支持数据增长时的重新分片/重新平衡。

如果你的应用程序不需要MySQL的关系能力，我建议你把精力集中在MongoDB上（因为你已经确定它作为可能的数据平台），如果你预计数据增长超过适度，请允许MongoDB处理数据分片。

- Eric J.

---

应用程序级别的分片可以潜在地成为一个具有单个分片MongoDB的服务器农场。我仍然希望构建将租户分离出来以控制卷入租户的能力。我同意您关于需要复杂工具来进行重新分片的观点。 - msingla