分布式事务和/或集群中共享数据的 Java 解决方案 [英] Java Solutions for Distributed Transactions and/or Data Shared in Cluster
问题描述
集群/分发 Java 服务器应用程序的最佳方法是什么?我正在寻找一种方法，让您可以通过添加更多应用服务器和更多数据库服务器来进行水平扩展.
What are the best approaches to clustering/distributing a Java server application ? I'm looking for an approach that allows you to scale horizontally by adding more application servers, and more database servers.
- 您建议使用哪些技术(软件工程技术或特定技术)来解决此类问题?
- 您使用什么技术来设计持久层以扩展到许多读者/作者扩展应用事务并扩展对共享数据的访问(最好的方法是消除共享数据；您可以应用哪些技术来消除共享数据).
- 似乎需要不同的方法，具体取决于您的事务是读重读还是重写，但我觉得如果您可以优化一个写"重的应用程序，它对读"也很有效
最佳"解决方案将允许您为单个节点编写 Java 应用程序，并希望隐藏"访问/锁定共享数据的大部分细节.
The "best" solution would allow you to write a Java application for a single node and hopefully "hide" most of the details of accessing/locking shared data.
在分布式环境中，最困难的问题始终归结为多个事务访问共享数据.似乎有两种常见的并发事务方法.
In a distributed environment the most difficult issue always comes down to having multiple transactions accessing shared data. There seems like there's 2 common approaches to concurrent transactions.
- 显式锁(极易出错且跨多个协调缓慢分布式系统中的节点)
- 软件事务内存 (STM) AKA 乐观并发，其中事务在提交期间回滚如果它发现共享状态已更改(并且稍后可以重试事务).哪种方法的扩展性更好?分布式系统中的权衡是什么?
- Explicit locks (which is extremely error prone and slow to coordinate across multiple nodes in a distributed system)
- Software transactional memory (STM) AKA optimistic concurrency where a transaction is rolled back during a commit if it discovers that shared state has changed (and the transaction can later be retried). Which approach scales better and what are the trade-offs in a distributed system?
我一直在研究扩展解决方案(以及提供如何扩展示例的一般应用程序)，例如:
I've been researching scaling solutions (and in general applications that provide an example of how to scale) such as:
- Terracotta - 通过扩展 Java 内存模型以包括使用 Java 的并发锁定机制的分布式共享内存来提供透明"缩放(同步，ReentrantReadWriteLocks).
- Google App Engine Java - 允许您编写 Java(或 python)应用程序，这些应用程序将分布在云"服务器之间，您可以在其中分发处理事务的服务器，并使用 BigTable 存储持久数据(不确定您如何访问共享数据的事务或处理锁争用以有效扩展)
- Darkstar MMO 服务器 - Darkstar 是 Sun 的开源 MMO(大型多人在线)游戏服务器，它们在线程中扩展交易事务方式允许给定事务仅运行一定数量并提交，如果需要很长时间它将回滚(有点像软件事务内存).他们一直在研究支持多节点服务器设置以进行扩展.
- Hibernate 的乐观锁 - 如果您正在使用Hibernate 你可以使用它们的乐观并发支持来支持软件事务内存类型行为
- Apache CouchDB 应该自然地扩展"到网格配置中的许多读写器数据库.(是否有一个很好的示例来说明您如何管理锁定数据或确保事务隔离?):
- JCache - 通过缓存扩展读取"大量应用您可以在 Google Appengine 中使用的常见查询结果来访问 memcached 和缓存其他经常读取的数据.
- Terracotta - provides "transparent" scaling by extending the Java memory model to include distributed shared memory using Java's concurrency locking mechanism (synchronized, ReentrantReadWriteLocks).
- Google App Engine Java - Allows you to write Java (or python) applications that will be distributed amongst "cloud" servers where you distribute what server handles a transaction and you use BigTable to store your persistent data (not sure how you transactions that access shared data or handle lock contentions to be able to scale effectively)
- Darkstar MMO Server - Darkstar is Sun's open source MMO (massively multiplayer online) game server they scale transactions in a thread transactional manner allowing a given transaction to only run for a certain amount and committing and if it takes to long it will rollback (kinda like software transactional memory). They've been doing research into supporting a multi-node server setup for scaling.
- Hibernate's optimistic locking - if you are using Hibernate you can use their optimistic concurrency support to support software transactional memory type behavior
- Apache CouchDB is supposed to "scale" to many reader/writer DB's in a mesh configuration naturally. (is there a good example of how you manage locking data or ensuring transaction isolation?):
- JCache - Scaling "read" heavy apps by caching results to common queries you can use in Google appengine to access memcached and to cache other frequently read data.
Terracotta 似乎是最完整的解决方案，因为您可以轻松"修改现有服务器应用程序以支持扩展(在定义 @Root 对象和 @AutoLockRead/Write 方法之后).问题是真正从分布式应用程序中获得最大性能，分布式系统的优化并不是真正的事后想法，您必须在设计它时知道对象访问可能会被网络 I/O 阻塞.
Terracotta seems to be the most complete solution in that you can "easily" modify an existing server application to support scaling (after defining @Root objects and @AutoLockRead/Write methods). The trouble is to really get the most performance out of a distributed application, optimization for distributed systems isn't really an after thought you kinda have to design it with the knowledge that object access could potentially be blocked by network I/O.
为了正确扩展，似乎总是归结为分区数据和负载平衡事务，以便给定的执行单元"(cpu 核心 -> 线程 -> 分布式应用程序节点 -> DB 主节点)
To scale properly it seems like it always comes down to partitioning data and load balancing transactions such that a given "execution unit" (cpu core -> thread -> distributed application node -> DB master node)
似乎通过集群使任何应用程序正确扩展，您需要能够根据数据访问读取/写入对事务进行分区.人们提出了哪些解决方案来分发他们的应用程序数据(Oracle、Google BigTable、MySQL、数据仓库)，以及您通常如何管理分区数据(许多写入主机，以及更多读取 DB 等).
It seems like though to make any app scale properly by clustering you need to be able to partition your transactions in terms of their data access reads/writes. What solutions have people come up with to distribute their applications data (Oracle, Google BigTable, MySQL, Data warehousing), and generally how do you manage partitioning data (many write masters, with many more read DBs etc).
就扩展数据持久层而言，在将数据分区给许多读者/许多作者方面，哪种类型的配置扩展得最好(通常我会根据给定的用户(或任何核心实体)对我的数据进行分区通常是您的根"对象实体)由单个主数据库拥有)
In terms of scaling your data persistence layer what type of configuration scales out the best in terms of partitioning your data to many readers/many writers (generally I'd partition my data based on a given user (or whatever core entity that generally is your "root" object entity) being owned by a single master DB)
推荐答案
觉得我找到了一个很棒的 Java Clustering/Distributed 平台，想重新打开这个-
Thought I found a great Java Clustering/Distributed platform, wanted to reopen this-
我运行了测试程序，它非常酷、非常轻巧且易于使用.它会自动检测点对点配置中的集群成员.机会是无限的.
I ran the test programs, it is very cool, very light-weight and simple to use. It automatically detects the Cluster Members in a Peer-to-Peer configuration. The opportunities are limitless.
这篇关于分布式事务和/或集群中共享数据的 Java 解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
