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

时间:2012-05-07 11:33:54

标签: database web-services architecture database-connection race-condition

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

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

  1. 典型的网络前端,可让用户创建/编辑/删除帐户,并在...中创建/更新/删除帐户记录。
  2. ...数据库,存储所有用户的帐户;
  3. 和一个Jabber bot(一个单独的服务,可能在一个单独的物理机器上),它与用户说话,但需要在同一个数据库中查找并更新有关用户的内容(2)。
  4. 因此,基本上我有两个使用相同数据库的应用程序。由于数据完整性,竞争条件和其他问题,我不确定这是一个很好的解决方案。

    我的典型用例可能是:User1正在与Jabber bot(3)交互,并且机器人需要在数据库中查找和更新数据,并且在完全相同的时刻User2通过(1)创建一个帐户,需要与数据库进行一些交互(2)。

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

    (遗憾的是,此应用的“商业模式”不允许在一个网络服务中使用'帐户管理'(1)和'Jabber bot'(2)逻辑。

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

1 个答案:

答案 0 :(得分:1)

从两个不同的服务查询或更新数据库没有问题。数据库旨在同时处理多个不同的请求,无论这些并发请求来自同一个应用程序还是来自不同的应用程序,数据库都无关紧要。

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

在达到一定限度之前,没有任何问题。 一旦超过某个限制(假设1000个并发请求,但实际数量取决于不同的情况),您可能必须对数据库进行集群。

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