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

Dou*_*kem 21 java concurrency scalability transactions optimistic-locking

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

  • 您会建议采用哪些技术(软件工程技术或特定技术)来解决此类问题?
  • 您使用什么技术设计持久层以扩展到许多读取器/写入器扩展应用程序事务并扩展对共享数据的访问(最佳方法是消除共享数据;您可以应用哪些技术来消除共享数据).
  • 似乎需要使用不同的方法,具体取决于您的事务是读取还是写入繁重,但我觉得如果您可以优化"写入"繁重的应用程序,这对于"读取"也是有效的

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

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

  1. 显式锁(在分布式系统中的多个节点之间极易出错并且协调速度很慢)
  2. 软件事务内存(STM)AKA乐观并发,如果事务发现共享状态已更改(并且稍后可以重试事务),则在提交期间回滚事务.哪种方法可以更好地扩展,在分布式系统中有哪些权衡取舍?

我一直在研究扩展解决方案(以及提供如何扩展的示例的一般应用程序),例如:

  1. Terracotta - 通过使用Java的并发锁定机制(synchronized,ReentrantReadWriteLocks)扩展Java内存模型以包含分布式共享内存,提供"透明"扩展.
  2. 谷歌应用程序引擎的Java -让您可以在您分发哪个服务器处理事务写,将当中的"云"服务器进行分布式Java(或Python)的应用程序和使用BigTable的存储持久性数据(不知道你的交易是如何访问共享数据或处理锁定争用,以便能够有效扩展)
  3. 暗星MMO服务器 -暗星是Sun的开源MMO(大型多人在线),他们规模在一个线程事务的方式交易,允许一个给定的事务,只进行了一定的运行,并承诺,如果它需要长期将回滚游戏服务器(有点像软件事务内存).他们一直在研究支持多节点服务器设置以进行扩展.
  4. Hibernate的乐观锁定 - 如果你使用的是Hibernate,你可以使用它们的乐观并发支持来支持软件事务内存类型的行为
  5. Apache CouchDB应该自然地以网状配置"扩展"到许多读写器DB.(有一个很好的例子,说明如何管理锁定数据或确保事务隔离?):
  6. JCache - 通过将结果缓存到可以在Google appengine中使用的常见查询来扩展"读取"繁重的应用程序,以访问memcached并缓存其他经常读取的数据.

Terracotta似乎是最完整的解决方案,因为您可以"轻松"修改现有服务器应用程序以支持扩展(在定义@Root对象和@AutoLockRead/Write方法之后).问题是要真正从分布式应用程序中获得最大的性能,分布式系统的优化实际上并不是一个想法,你必须设计它,知道对象访问可能被网络I/O阻止.

为了正确扩展,似乎总是归结为分区数据和负载平衡事务,例如给定的"执行单元"(cpu core - > thread - >分布式应用程序节点 - > DB主节点)

似乎通过群集使任何应用程序可以正确扩展,您需要能够根据数据访问读/写对事务进行分区.人们提出了哪些解决方案来分发他们的应用程序数据(Oracle,Google BigTable,MySQL,数据仓库),以及一般如何管理分区数据(许多写入主数据库,以及更多读取数据库等).

在扩展数据持久层方面,在将数据划分给许多读者/多个编写者方面,哪种类型的配置最佳扩展(通常我会基于给定用户(或通常是您的任何核心实体)对数据进行分区"root"对象实体)由单个主DB拥有

sri*_*lla 2

感谢您在一个地方很好地总结了所有可能性。

但这里缺少一项技术。它就是MapReduce-Hadoop。如果可以将问题纳入 MapReduce 范式,那么它可能是最广泛使用的解决方案。我还想知道 Actor 框架模式(JetLang、Kilim 等)是否可以扩展到集群。