用于分布式事务和/或在集群中共享数据的 Java 解决方案

集群/分发 Java 服务器应用程序的最佳方法是什么？我正在寻找一种方法，允许您通过添加更多应用程序服务器和更多数据库服务器来水平扩展。

• 您建议使用什么技术（软件工程技术或特定技术）来解决此类问题？
• 使用什么技术来设计持久性层以扩展到许多读取器/写入器 缩放应用程序事务并扩展对共享数据的访问（最好的方法是消除共享数据;可以应用哪些技术来消除共享数据）。
• 根据您的事务是读取还是写入繁重，似乎需要不同的方法，但我觉得如果您可以优化“写入”繁重的应用程序，那么对于“读取”来说也是有效的。

“最佳”解决方案将允许您为单个节点编写Java应用程序，并希望“隐藏”访问/锁定共享数据的大部分细节。

在分布式环境中，最困难的问题总是归结为让多个事务访问共享数据。似乎有2种常见的并发交易方法。

1. 显式锁（在分布式系统中的多个节点之间协调非常容易出错且速度很慢）
2. 软件事务内存 （STM） 又名乐观并发，如果事务在提交期间发现共享状态已更改（并且以后可以重试事务），则会在提交期间回滚事务。哪种方法的扩展性更好，分布式系统中有哪些权衡取舍？

我一直在研究扩展解决方案（以及在提供如何扩展示例的一般应用程序中），例如：

1. Terracotta - 通过使用Java的并发锁定机制（同步，ReentrantReadWriteLocks）扩展Java内存模型来包括分布式共享内存，从而提供“透明”扩展。
2. Google App Engine Java - 允许您编写Java（或python）应用程序，这些应用程序将分布在“云”服务器中，您可以在其中分发处理事务的服务器，并使用BigTable来存储持久性数据（不确定如何访问共享数据或处理锁争用的事务，以便能够有效地扩展）
3. Darkstar MMO服务器 - Darkstar是Sun的开源MMO（大型多人在线）游戏服务器，它们以线程事务方式扩展事务，允许给定事务仅以一定数量和提交的速度运行，如果它需要很长时间，它将回滚（有点像软件事务内存）。他们一直在研究支持多节点服务器设置以进行扩展。
4. Hibernate的乐观锁定 - 如果您使用的是Hibernate，则可以使用其乐观并发支持来支持软件事务内存类型行为
5. Apache CouchDB应该自然地在网格配置中“扩展”到许多读/写器数据库。（有没有一个很好的例子来说明你如何管理锁定数据或确保事务隔离？
6. JCache - 通过将结果缓存为常见查询来扩展“读取”密集型应用，您可以在Google appengine中使用访问memcached并缓存其他经常读取的数据。

Terracotta似乎是最完整的解决方案，因为您可以“轻松”修改现有的服务器应用程序以支持扩展（在定义了@Root对象并@AutoLockRead/Write方法之后）。麻烦的是要真正从分布式应用程序中获得最佳性能，分布式系统的优化并不是一个事后的想法，你必须在设计它时知道对象访问可能会被网络I / O阻止。

为了正确扩展，它似乎总是归结为对数据进行分区和负载平衡事务，以便给定的“执行单元”（cpu core ->线程 ->分布式应用程序节点 -> DB 主节点）

似乎要通过群集使任何应用程序正确扩展，您需要能够根据数据访问读取/写入对事务进行分区。人们想出了什么解决方案来分发他们的应用程序数据（Oracle，Google BigTable，MySQL，数据仓库），以及通常如何管理分区数据（许多写入主数据，还有更多的读取数据库等）。

在扩展数据持久层方面，哪种类型的配置在将数据分区到许多读取器/许多写入器方面最能横向扩展（通常我会根据给定用户（或任何核心实体，通常是您的“根”对象实体）对数据进行分区，这些用户由单个主数据库拥有）