架构：一个数据库由两个不同的服务器使用

Question

免责声明：这篇文章的作者对 Web 应用程序的软件架构只有理论知识，几乎没有实践知识。

假设我想构建一个具有以下架构大纲的网络应用程序：

1. 一个典型的 Web 前端，允许用户创建/编辑/删除帐户并在...中创建/更新/删除帐户记录
2. ...数据库，存储所有用户的账户；
3. 和一个 Jabber 机器人（一个单独的服务，可能在单独的物理机器上）与用户对话，但需要在同一数据库中查找和更新有关用户的资料 (2)。

所以，基本上我有两个应用程序使用同一个数据库。由于数据完整性、竞争条件和其他问题，我不确定这是一个好的解决方案。

我的典型用例可能是：User1 正在与 Jabber bot (3) 交互，bot 需要在数据库中查找和更新数据，而在同一时刻 User2 通过 (1) 创建了一个帐户，这需要与数据库进行一些交互 (2)。

如何在保留所需功能的同时避免这种类型的架构？或者，我如何设计架构以消除从两个不同服务查询一个数据库的需要？

（遗憾的是，此应用的“商业模式”不允许在一个 Web 服务中包含“帐户管理”(1) 和“Jabber bot”(2) 逻辑）。

附：所讨论的系统最重要的要求是高可用性（也许它会以某种方式影响答案）。

Answer 1

从两个不同的服务查询或更新数据库没有问题。数据库的设计目的是同时处理多个不同的请求，这些并发请求是来自同一个应用程序还是来自不同的应用程序，对于数据库来说是无关紧要的。

即使我们删除了 Jabber 服务 (3)，您仍然可以让 Web 应用程序 (1) 处理多个并发 Web 请求，这将创建并行数据库查询。

没有问题，直到你达到一定的限制。 一旦您的增长超过某个限制（假设 1000 个并发请求，但实际数量取决于不同的情况），您可能需要集群您的数据库。

但在达到此目标之前，您将面临其他性能瓶颈。例如。正确设置缓存可以让您使用单个数据库服务器实例为更多用户提供服务。