集群与复制
有n个客户，主要关心的是他们中的大多数人在线（越多越好）的时间越多。出于预算和功耗的原因，只有一台服务器。 我从很多角度看到了这个问题，最暴露在这个讨论Strategies for Java ORM with Unreliable Network and Low Bandwidth然后总结我的选择。
- 聚类。使用 terracotta 并使用安装在节点上的第二个服务器（被动）。
- 复制/同步。我最初的想法：允许节点在网络故障时离线，然后重新启动运行。
你有什么建议吗？
PS如果我的推理有问题请告诉我
There are n clients, the main concern is that is most of them is online (the more the better) as much time. There is only one server, for reasons of budget and power consumption.
I have seen this problem from many angles, most exposed in this discussion Strategies for Java ORM with Unreliable Network and Low Bandwidth then summarized my options.
- Clustering. Using terracotta and using a second server (passive) installed on a node.
- Replication / Synchronization. My original idea: Allow nodes to be offline during network failures and then restart operations.
What do you recommend?
PS if there is something wrong in my reasoning please tell me
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
谢谢你的这些想法。该应用程序是一个简单的销售点。在思考和分析你的答案之后，我将尝试将用户、产品和销售存储在 DSO 中（同时使用一些盒子作为服务器和节点）。同时，带有数据库的服务器可以根据生产者-消费者模式进行销售。
并对我的沟通能力较差表示歉意，我还在学习英语！
Thanks for those thoughts. The application is a simple point of sale. After thinking and analyzing your answer I will try to store users, products and sales in DSO's (using some boxes as servers and nodes at the same time). At one time the server with the database is available pour the sales according to the producer-consumer pattern.
And an apology for my short communication skills, I'm still learning English!.
我认为你是说你有一台机器，上面有一个使用 Hibernate 的应用程序和一个 MySql 数据库。如果您丢失了该机器，您的用户将无法工作。您询问是否可以增加一些额外的弹性，并相信您已经确定了两种解决方案。
您没有提供有关这两种解决方案的详细信息，因此我不会尝试再次猜测您的想法。
您也没有过多谈论应用程序的性质。如果（例如）它完全是只读的，没有数据库更新，那么复制相对容易。如果所有写入都是附加的并且不会发生冲突（例如某种民意调查，投票是/否），那么再次进行复制可能会相对容易一点，排队也比较容易。
然而，用户更新共享数据的传统应用程序，其中一致的视图是
重要（例如，我们不想将最后一个可用的酒店房间出售两次），那么复制就会变得很棘手。
一种方法是将数据库分离到高弹性层，Oracle RAC 等产品具有非常聪明的弹性特性，我想您会为聪明付出代价。一旦您拥有了弹性数据库，那么对应用程序进行集群就会变得更加容易。我经常看到许多廉价的盒子并行运行该应用程序，因为最终的“真相”是由数据库管理的。
然而，即使这也很棘手，除非应用程序是预先设计用于复制的。您会发现各种微妙的假设都是在应用程序的基础上做出的，在某种程度上能够依赖它之前的事实观点。像 Terracotta 这样的产品很可能（我从未尝试过，所以我不知道）有助于实现弹性设计，但除非设计经过深思熟虑，否则可能会存在业务缺陷。
我将您的想法解释为运行应用程序和数据库的多个并行副本并处理同步问题。只有您知道这是否适合您的业务需求。您将打开不一致的可能性，尤其是在发生故障且重新同步尚未完成的情况下。
I think you are saying that you have a single machine, on it you have both an application using Hibernate and a MySql database. If you lose that machine your users cannot work. You are asking whether some additional resilience is possible and believe that you have identified two solutions.
You don't give much detail about either solution, so I'm not going to try to second guess what you have in mind.
You also don't say much about about the nature of the application. If (for example) it was entirely read-only, no database updates then replication is comparatively easy. If all writes are additive and cannot conflict (for example some kind of opinion poll, vote yes/no) then again replication with perhaps a bit of queueing is comparatively easy.
However a traditional application with users updating shared data, where a consistent view is
important (for example we don't want to sell the last available hotel room twice) then replicating gets tricky.
One approach is to separate the database to a highly resilient tier, products such as Oracle RAC have very clever resilient characteristics, and I guess you pay for cleverness. Once you have a resilient database then clustering your application becomes much easier. I often see lots of cheap boxes running the app in parallel because the definitive "truth" is managed by the DB.
However, even this is tricky unless the app was designed up-front for replication. You find all manner of subtle assumptions are made on the basis of the App is some sense being able to rely on it's previous view of truth. Products like Terracotta may well (I've never tried, so I don't know) help to implement a resilient design but unless the design is well thought through it may have business flaws.
I interpret your idea as being to run multiple parallel copies of the app and db and the deal with synchronisation issues. Only you know whether this makes sense for your business requirements. You would be opening up the possibility of inconsistency, especially in the times when failures have occurred and resynchronisation has not completed.