问题:我有一个进程请求开始,分解成多个级别的队列/ MDB以加速并行处理。问题是,什么是最好的方式知道什么时候每个处理级别完成了一个关闭过程?请记住,我正在处理大量的消息,因此必须考虑性能。JMS - 异步处理 - 处理父/子进程依赖关系
技术堆栈:
- EJB 3.0 MDB的
- 休眠4.2.11()
- 春4.0.1
- 的WebSphere MQ的
- 的Oracle 11g数据库。
解决方案1尝试:父进程轮询子进程,直到它在每个子级完成为止。这意味着一个开放的MDB会话将持续轮询每个级别的消息的响应队列,以完成其子进程。
优点:您可以避免不断地对数据库进行调用以确定“我是否已完成”。
缺点:
- 该解决方案保持一致的开放输入连接到MQ在等待和过程投票来完成。在缩放时,连接数量会增加。
- 如果有任何消息丢失,它将抛出轮询机制的计数。不是很可靠。
- 如果您打开了持久性(您应该最多次),它将重新处理初始请求,因为它仍然会打开,重新执行整个请求。
解决方案2的提案:
- 代替使用轮询机制,使用更多的MDB的每个处理级绑定到响应队列。一切工作都是孤立的。
如何确定过程是否完成?由于每条消息都会响应MDB,因此可以检查数据库状态表以确定其是否完整。
优势:
列表项
所有消息孤立地起作用。
- 更适合支持高可用性和持久性消息。
- 防止针对MQ的任何长时间运行的打开进程。
缺点:这可能意味着很多调用数据库来确定完整性。随着消息数量的增加,我认为这将是一个主要的可扩展性问题。
我没有使用Spring批处理和Spring集成很多,但也许这是我应该寻找解决方案。希望在消息流的MDB和MQ方面拥有丰富经验的人员可以在缩放/确定流程完成时给予我一些指导。
我认为JMS总线是一个必然的可扩展性。只是为了解决MQ的tcp/ip连接限制。唯一的解决办法是我需要为每个子级别的处理设置一个主题。还有如何解决相同的问题知道...什么时候该过程实际完成? mdb不会知道最后一条消息。我想我可以添加标题信息,以便跟踪它完成的消息数量,就像它正在轮询一样。不过,我认为同样的问题可能会导致打破这一过程的“丢失信息”情景。但它确实解决了一些问题,是一个有效的选择。 – haju 2014-09-08 12:53:49
无论如何,必须为正向路径处理丢失的消息问题。同样的解决方案也可以用于此目的。而且,这不仅仅适用于“任务完成”消息。您可以将JMS总线用于子任务的“生命符号”消息,以了解它们是否存在。 – 2014-09-08 15:45:16
我想给人们一些时间来看看我的问题。不过,我认为最好的解决方案是在流程中使用分散的经理。像Spring Integration或Camel一样。这允许连续过程独立工作,但允许您根据整个过程允许自定义执行。像电线水龙头,计数器和状态。 – haju 2014-09-15 18:55:34