Java 集群与复制

有n个客户，主要关注的是，他们中的大多数都是在线的（越多越好）。由于预算和功耗的原因，只有一台服务器。 我从多个角度看到了这个问题，在这次讨论中，大多数人都暴露了这个问题，然后总结了我的选择

集群。使用terracotta和安装在节点上的第二台服务器（被动）

复制/同步。我最初的想法是：允许节点在网络故障期间脱机，然后重新启动操作

你推荐什么

---

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

我想你是说你有一台机器，上面有一个使用Hibernate的应用程序和一个MySql数据库。如果你失去了那台机器，你的用户就无法工作。您正在询问是否可能增加一些弹性，并相信您已经确定了两种解决方案

关于这两种解决方案，您都没有给出太多的细节，所以我不打算猜测您的想法

对于应用程序的性质，您也没有说太多。如果（例如）它是完全只读的，没有数据库更新，那么复制就相对容易。如果所有的写操作都是累加的，并且不会发生冲突（例如，某种民意调查，投赞成票/反对票），那么再重复一遍，可能需要一些排队，这相对比较容易

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

一种方法是将数据库分离到一个高弹性层，像Oracle RAC这样的产品具有非常聪明的弹性特征，我想你应该为聪明付出代价。一旦您拥有了一个弹性数据库，那么集群应用程序就变得容易多了。我经常看到很多便宜的盒子并行运行应用程序，因为决定性的“真相”是由DB管理的

然而，即使这样也很棘手，除非该应用程序是为复制而预先设计的。你会发现，所有微妙的假设都是基于应用程序做出的，能够依赖于它之前的真理观是有一定道理的。像Terracotta这样的产品很可能（我从未尝试过，所以我不知道）有助于实现弹性设计，但除非设计经过深思熟虑，否则可能存在业务缺陷

---

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

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

---

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

不，这不容易。您是说对运行hibernate的服务器进行集群/复制，还是对数据库本身进行集群/复制？您提到的这篇文章似乎是关于处理数据库的不可靠连接和数据库的不可靠性的。你说你只有一台服务器，那么你在哪里复制？你说“客户机”——什么客户机？如果他们是您的一台服务器的客户机，并且该服务器出现故障，那么他们都会经历停机（而世界上所有的集群/复制都不会有帮助）。如果事实上它们被配置为集群或其他什么，请不要称它们为“客户机”——它们也是服务器。如果我不清楚的话，很抱歉。这是当前的配置，我想做一些更改。事实上，今天如果唯一的服务器坏了，所有的系统都坏了，这就是问题所在。因此，我认为我可以实现一个集群解决方案或复制解决方案，在每个节点上都有一个本地数据库。谢谢你的关心，djna和Chris！此外，该系统的工作负载较低，完整的未压缩mysql数据库只有1.5 gb，包含18个月的数据。目前还不清楚实际问题是什么。只是“对于群集/复制/故障切换选项，您有什么建议？”