【问题标题】:Clustering vs Replication集群与复制
【发布时间】:2012-01-15 20:19:30
【问题描述】:

有n个客户,主要关心的是他们中的大多数是在线(越多越好)的时间。由于预算和功耗的原因,只有一台服务器。 我从多个角度看到了这个问题,大部分暴露在这个讨论中Strategies for Java ORM with Unreliable Network and Low Bandwidth然后总结了我的选择。

  1. 集群。使用 terracotta 并使用安装在节点上的第二台服务器(被动)。
  2. 复制/同步。我最初的想法:让节点在网络故障时下线,然后重新启动操作。

你有什么推荐的?

PS 如果我的推理有问题,请告诉我

【问题讨论】:

  • 不,这并不容易。您是在谈论集群/复制运行休眠的服务器还是集群/复制数据库本身?您所指的文章似乎是关于处理与数据库的不可靠连接和数据库的不可靠性。你说的只有一台服务器,所以你在哪里复制?
  • 你说“客户”——什么客户?如果他们是您的 one 服务器的客户端并且它出现故障,他们将全部经历停机时间(并且世界上所有的集群/复制都无济于事)。如果实际上它们被配置为集群或其他东西,请不要称它们为“客户端”——它们也是服务器。
  • 对不起,如果我不清楚。这就是我想要进行一些更改的当前配置。事实上,今天如果唯一的服务器出现故障,所有系统都出现故障,这就是问题所在。所以我认为我可以在每个节点中使用本地数据库实现集群解决方案或复制解决方案。感谢 djna 和 Chris 的关注!
  • 另外系统工作量小,全解压mysql数据库18个月数据只有1.5gb。
  • 目前还不清楚这里的实际问题是什么。仅仅是“您对集群/复制/故障转移选项有什么建议?”

标签: java hibernate network-programming replication cluster-computing


【解决方案1】:

感谢您的这些想法。该应用程序是一个简单的销售点。在思考和分析您的答案后,我将尝试将用户、产品和销售额存储在 DSO 中(同时使用一些盒子作为服务器和节点)。有一次,带有数据库的服务器可用,根据生产者-消费者模式倾倒销售。

为我短暂的沟通技巧道歉,我还在学习英语!。

【讨论】:

    【解决方案2】:

    我想你是说你有一台机器,在它上面你有一个使用 Hibernate 的应用程序和一个 MySql 数据库。如果您丢失了那台机器,您的用户将无法工作。您是在询问是否有可能获得一些额外的弹性,并认为您已经确定了两种解决方案。

    你没有提供关于这两种解决方案的太多细节,所以我不会试图猜测你的想法。

    您也没有过多地谈论应用程序的性质。如果(例如)它是完全只读的,没有数据库更新,那么复制相对容易。如果所有写入都是相加的并且不会发生冲突(例如某种民意调查,投票是/否),那么再次复制可能会相对容易一些排队。

    但是,在用户更新共享数据的传统应用程序中,一致的视图是 重要(例如,我们不想两次出售最后一个可用的酒店房间)然后复制变得很棘手。

    一种方法是将数据库分离到一个高弹性层,Oracle RAC 等产品具有非常聪明的弹性特性,我猜你要为聪明付出代价。一旦您拥有一个弹性数据库,那么集群您的应用程序就会变得更加容易。我经常看到很多廉价的盒子并行运行应用程序,因为确定的“真相”由数据库管理。

    但是,除非应用程序是为复制而预先设计的,否则即使这样也很棘手。你会发现各种微妙的假设都是在应用程序的基础上做出的,这在一定程度上能够依赖于它以前对事实的看法。像 Terracotta 这样的产品(我从未尝试过,所以我不知道)可能有助于实现弹性设计,但除非设计经过深思熟虑,否则它可能存在业务缺陷。

    我将您的想法理解为运行应用程序和数据库的多个并行副本以及处理同步问题。只有您知道这对您的业务需求是否有意义。您将打开不一致的可能性,尤其是在发生故障且重新同步尚未完成的时候。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-11-28
      • 2019-07-12
      • 1970-01-01
      • 2021-05-12
      • 1970-01-01
      • 2011-09-12
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多