聚类与复制

Question

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

1. 聚类使用terracotta并使用安装在node.
2. Replication /同步上的第二个服务器(被动)。我最初的想法是:允许节点在网络故障期间脱机，然后重新启动操作。

你有什么建议吗？

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

Answer 1

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

很抱歉，我的沟通能力很差，我还在学英语！

Answer 2

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

你并没有给出任何一个解决方案的细节，所以我不会试图去猜测你的想法。

对于应用程序的性质，您也不会说太多。如果(例如)完全是只读的，则没有数据库更新，那么复制就比较容易了。如果所有的写都是加性的，并且不能冲突(例如，某种民意测验，投票是/否)，那么再重复一次，也许有一点排队是比较容易的。

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

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

然而，即使这是棘手的，除非应用程序是预先设计的复制。你会发现，各种微妙的假设都是建立在应用程序的基础上的，它有某种意义，能够依赖于它以前对真理的看法。像Terracotta这样的产品(我从来没有尝试过，所以我不知道)可以帮助实现弹性设计，但是除非设计经过深思熟虑，否则它可能存在业务缺陷。

我将您的想法解释为运行多个应用程序和 db的并行副本，以及处理同步问题。只有您知道这对您的业务需求是否有意义。您将打开不一致的可能性，特别是在失败发生而重新同步尚未完成的时候。