1

我一直致力于金融行业的解决方案。该应用程序的主要功能是能够加载大量输入文件、消化它们、更新持久存储中的状态以及根据请求从持久存储中生成提取。很简单。

输入文件是行业标准格式的 XML 大型（超过数百兆字节）消息，其中包含许多重复条目。持久存储是关系数据库。该引擎已实现为可部署在 J2EE 应用服务器上的基于 POJO（作为主干的 Spring 框架）Java 应用程序。

问题是关于解决方案的可扩展性和性能。如果应用程序按顺序处理来自 XML 的条目，则解决方案的可伸缩性相当差。没有办法让应用程序的多个实例参与单个文件的处理。这就是我为输入 XML 文件中的条目引入并行处理的原因。基本上，这个想法是为池中的工人分派处理单个条目。我决定使用 JMS 进行调度。加载文件的组件读取流并简单地提取单个条目并提供给调度队列。队列的另一端有许多并发消费者。每个人从队列中挑选一条消息并处理该条目，它可以立即用于处理其他条目。这与 Web 容器中的 servlet 非常相似。我发现这种方法特别强大的是，只要队列是共享的，工作人员就可以驻留在部署在远程服务器上的应用程序的不同实例中。不幸的是，所有工作人员都连接到维护持久性存储的同一个数据库，如果数据库服务器的功能不足以处理来自并发工作人员的负载，这可能是一个瓶颈。

您对这种架构有何看法？你有类似的应用程序设计吗？你当时的设计选择是什么？

4

7 回答 7

3

您还可以查看 Hadoop，这是一个非常方便的 Map/Reduce 作业平台。巨大的优势是，所有基础设施都由 Hadoop 提供，因此您只需应用新的硬件节点来扩展。实施 Map 和 Reduce 作业应该只执行一次，在此之后，您可以为集群提供大量负载。

于 2009-03-12T16:16:10.763 回答
2

我认为架构总体上是合理的。如果数据库在处理来自工作人员的大量并发更新时遇到问题，您可以在应用程序的另一“侧”引入第二个队列：当每个工作人员完成他们的任务时，他们将该任务的结果添加到队列。那么单个工作进程会定期从第二个队列中抓取结果对象并以大批量操作更新数据库吗？这将降低数据库并发性并可能提高更新效率。

于 2009-03-12T16:08:13.903 回答
1

我最近花了一些空闲时间研究 Spring Batch 2.0。这是基于 Spring 框架的新版 Java 批处理引擎。实施 Spring Batch 的人专注于此版本的并发和并行执行。我必须说它看起来很有希望！

于 2009-05-14T09:39:09.850 回答
1

另外，看看 Terracota 集群解决方案。

于 2009-03-13T18:46:21.520 回答
1

对于并行处理，正如 Mork0075 所说，hadoop 是一个很好的解决方案。实际上，许多公司都将它用于非常大的日志分析。一个有趣的项目 Hive 是基于 hadoop 构建的，用于数据仓库。

无论如何，我认为您当前的设计具有很大的可扩展性。至于您对所有工作人员访问数据库的担忧，您可以在工作人员和数据库之间放置另一个消息队列。工作人员将处理结果放入队列中，您构建另一个程序来订阅队列并更新数据库。缺点是两个队列可能会使系统过于复杂。当然，您可以在现有的 MQ 系统中添加另一个主题。这将使系统更简单。另一种方法是使用共享文件系统，如NFS，每台worker机器将相同的目录挂载在共享文件服务器上，每个worker将其处理结果写入共享文件服务器上的单独文件中。然后您构建一个程序来检查新文件以更新数据库。在这种方法中，您引入了另一种复杂性：共享文件服务器。

于 2009-05-13T17:51:07.120 回答
0

如果您已经在使用 Spring/Java EE，那么将 Spring Batch 作为“并发架构”的解决方案是很自然的。

蝙蝠的两个好处：

  1. Spring Batch（从 2.0 开始）实现了分区，这意味着框架将在单独的分区步骤（StepExecution）中为您处理分区数据，并将这些步骤的实际执行委托给多个线程或其他分布式系统（PartitionHandlers例如，TaskExecutorPartitionHandler或更加分散MessageChannelPartitionHandler，等等。）

  2. Spring 有一个很好的 OXM 包来处理 XML + Spring Batch 有一个StaxEventItemReader从输入 XML 文档中提取片段，这些片段对应于要处理的记录

试试 Spring Batch。如果您有任何问题，请告诉我，我很乐意为您提供帮助。

EDIT:

另请查看Scala/AKKA Actors和/或Scala parallel collections。如果您的任务适用于分片/分区/分布式 => 那就是 Actor 模型的用途。

如果您想考虑非 JVM 解决方案，请查看Erlang OTP=> 简单而优雅。

于 2009-11-17T12:00:20.007 回答
0

在回答您的问题时：

您对这种架构有何看法？你有类似的应用程序设计吗？你当时的设计选择是什么？

我认为这是一个很好的架构，你说得对，数据库是你的瓶颈。但是，设计足够灵活，您可以控制数据库的输入量。

我有跨节点的多线程工作。我不完全确定 Haddoop 或其他分布式处理系统会给你比你已经拥有的更多，因为你只是对数据库进行 I/O。

我已经使用 JMS 队列实现了一些类似的集中式日志记录，它工作得很好，对代码的影响较小，然后将日志写入磁盘。我认为它适用于您的应用程序。

于 2012-04-10T22:02:58.743 回答