如何使用数据库作为通信媒介来实现分布式应用程序的最大并发性答案

【问题标题】：How to achieve maximum concurrency for a distributed application using a database as medium of communication如何使用数据库作为通信媒介来实现分布式应用程序的最大并发性
【发布时间】：2011-01-24 07:24:29
【问题描述】：

我有一个类似于经典生产者消费者问题的应用程序。只是想检查所有可能的实现来实现它。问题是-

进程A：向数据库表中插入一行（生产者）

进程B：从表中读取M行，处理后删除读取的M行。

进程 B 中的任务： 1.读取M行 2.处理这些行 3. 删除这些行

进程 A 的 N1 个实例，进程 B 的 N2 个实例同时运行。

每个实例在不同的盒子上运行。

一些要求：如果进程 p1 正在读取 (0,M-1) 行。进程 p2 不应该等待 p1 直到它释放对这些行的锁定，而是应该读取 (M,2M-1) 行。

【问题讨论】：

标签： java oracle concurrency parallel-processing database-concurrency

【解决方案1】：

我敢打赌，有比使用 DB 作为生产者和消费者之间的交换器更好的并行处理方法。为什么不队列？您是否检查过为 Map/Reduce 设计的工具/框架。 Hadoop、GridGain、JPPF 都可以做到这一点。

【讨论】：

【解决方案2】：

Java.15 的 ConcurrentHashMap 中使用了类似的概念。应单独维护正在处理的行列表。当任何进程需要与 DB 交互时，它应该检查该行是否正在被另一个进程处理。如果是这样，它应该在那个条件下等待，否则它可以处理。在这种情况下维护索引可能会有所帮助

【讨论】：

【解决方案3】：

我认为如果实现了这个应用程序，它实际上使用了手工制作的队列。我相信 JMS 在这种情况下要好得多。有很多可用的 JMS 实现。其中大多数是开源的。

在您的情况下，流程 A 应该将任务插入队列。进程 B 应该在 receive() 上被阻塞，获取 N 条消息然后处理它们。您可能有理由从队列中获取大量任务，但如果您将实现更改为基于 JMS，您可能根本不需要它，因此您可以只听队列并立即处理消息。实现变得几乎微不足道，非常灵活和可扩展。您可以根据需要运行任意数量的进程 A 和 B，并将它们分布在不同的盒子中。

【讨论】：

【解决方案4】：

您可能还想了解一下 Amazon Elastic Map Reduce

http://aws.amazon.com/elasticmapreduce/

【讨论】：