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

我有一个类似于经典生产者消费者问题的应用程序。只想查看实现它的所有可能的实现。问题是- 进程A:在数据库(生产者)的表中插入一行 进程B:从表中读取M行,在处理后删除读取的M行。 流程B中的任务: 1.读M行 2.处理这些行 3.删除这些行 进程A的N1个实例, 进程B的N2实例同时运行。 每个实例都在不同的盒子上运行。 一些要求: 如果进程p1正在读取(0,M-1)行。进程p2不应等待p1直到它释放这些行上的锁,而应该读取(M,2M-1)行。     
已邀请:
我敢打赌,与使用DB作为生产者和消费者之间的肇事者相比,有更好的并行处理方式。为什么不排队?您是否检查过为Map / Reduce设计的工具/框架。 Hadoop,GridGain,JPPF都可以做到这一点。     
类似的概念正在Java.15的ConcurrentHashMap中使用。 应单独维护正在处理的行列表。当任何进程需要与DB交互时,它应检查该行是否正由另一个进程处理。如果是这样,它应该等待那个条件,否则它可以处理。在这种情况下维护索引可能会有所帮助     
我认为如果实现这个应用程序,它实际上使用手工制作的队列。我相信在这种情况下JMS要好得多。有很多JMS实现可用。其中大多数是开源的。 在您的情况下,进程A应该将任务插入队列中。应该在
receive()
上阻止进程B,获取N个消息然后处理它们。您可能有理由从队列中获取大量任务,但如果您将实现更改为基于JMS,则可能根本不需要它,因此您可以立即监听队列并处理消息。实现变得几乎无足轻重,非常灵活和可扩展。您可以根据需要运行任意数量的进程A和B,并将它们分配到不同的框中。     
您可能还想了解Amazon Elastic Map Reduce http://aws.amazon.com/elasticmapreduce/     

要回复问题请先登录注册