1

我正在为我的网站后端构建一个可扩展的数据库解决方案。我最近一直在阅读有关数据库设计的内容，我似乎自己提出了一个可行的想法。我认为这是一种用同步数据维护 n 个数据库的新颖方法，但我可能错了。所以我要求 SO 评估这个想法并告诉我它是否疯狂。（或者如果它已经存在并已实施）

在这个方案中有一组服务器节点。一个节点运行一个查询负载均衡器（我们称之为A），其余节点运行一个典型的 dbms，我们将这些节点统称为N 。

每个 N 都与其他 N 断开连接。即）N中的节点不需要与任何其他节点进行通信。每个N只与A有一个连接。

这个过程是这样的

  • 所有数据库查询都通过A传递。（假设现在A具有无限的吞吐量和处理能力）
  • A检查每个查询 ( Q ) 并确定它是将从数据库读取的操作还是将写入数据库的查询。（在 sql 中，读是选择，写是更新）
  • 如果Q是读操作，转发给N中的一个节点
  • 如果Q是写操作，则将其转发给N中的所有节点

假设它实施得当，这会导致N中的所有节点都具有同步的数据库内容。只读取数据的查询需要发送到一个节点。

这个想法似乎对我特别有效，因为在我的系统中写入操作很少，不到 1%。

所以关于这个想法的几个问题

  • 从理论的角度来看，这样的方案是否有意义？
  • 如果这确实有意义，是否已经实施了商业或免费的解决方案？
4

3 回答 3

7

多读少写的典型设置是有一个读/写主数据库和 n 个复制的只读从属数据库。复制由 RBDMS 处理。只读查询可以在所有 n 个只读节点上进行负载平衡，如果您的读/写主节点暂时关闭，至少您的应用程序将能够为读取操作提供服务。您不需要中央“A”代理来决定查询是读取还是写入。发出查询的客户端应该足够聪明，可以知道它是在读还是在写。这样您就不会在“A”服务器上遇到瓶颈。

您提出的设置有一个明显的缺陷，即如果您同时写入 n 个节点，如果其中一个或多个写入失败怎么办？

于 2009-09-15T23:58:29.633 回答
1

您的方案仅适用于无限可用的节点。您将如何处理节点停机？如果一个节点由于任何原因而关闭并且错过了更新，它将在下次被询问时提供脏数据。

于 2009-09-15T23:55:07.130 回答
1

不是对您的问题的直接回答，但 SQL Server 2008 已经支持与您所描述的内容等效的内容。它称为对等事务复制。我相信其他 RDBMS 也一样。我认为 MySQL 将其称为主-主复制。

于 2009-09-16T00:37:11.277 回答