关于Web服务:体系结构:两个不同服务器使用的一个数据库

Architecture: one database used by two distinct servers

免责声明:本文作者对Web应用程序的软件体系结构只有理论知识,几乎没有实际知识。

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

  • 典型的Web前端,允许用户创建/编辑/删除帐户,并在中创建/更新/删除帐户记录…
  • …存储所有用户帐户的数据库;
  • 以及一个JabberBot(一个单独的服务,可能在一个单独的物理机器上),它与用户对话,但需要查找和更新同一数据库中用户的相关信息(2)。
  • 所以,本质上我有两个应用程序使用同一个数据库。由于数据完整性、竞争条件和其他问题,我不确定它是否是一个好的解决方案。

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

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

    (不幸的是,此应用程序的"业务模型"不允许在一个Web服务中具有"帐户管理"(1)和"Jabber Bot"(2)逻辑)。

    P.S.系统最重要的要求是高可用性(可能会以某种方式影响答案)。


    从两个不同的服务查询或更新数据库没有问题。数据库被设计为同时服务几个不同的请求,无论这些并发请求来自同一个应用程序还是来自不同的应用程序,都与数据库无关。

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

    在你达到一定的极限之前,这是没有问题的。一旦您超过了某个限制(比如说1000个并发请求,但实际数量取决于不同的情况),您可能就必须对数据库进行集群。

    但在达到这一点之前,您将面临其他性能瓶颈。例如,正确设置缓存将允许您使用数据库服务器的单个实例为更多用户提供服务。