我需要一个开源 Java API 或框架来处理队列中的项目。我可以自己开发一些东西,但不想重新发明轮子(而且我在多线程方面没有太多经验)。有这样的事吗?
我能想到的最接近的解决方案是业务流程管理 (BPM) 解决方案。
现在,我正在使用多个 Quartz 作业来处理队列中的项目。由于可扩展性和并发性问题,它并没有真正奏效。
我需要一个开源 Java API 或框架来处理队列中的项目。我可以自己开发一些东西,但不想重新发明轮子(而且我在多线程方面没有太多经验)。有这样的事吗?
我能想到的最接近的解决方案是业务流程管理 (BPM) 解决方案。
现在,我正在使用多个 Quartz 作业来处理队列中的项目。由于可扩展性和并发性问题,它并没有真正奏效。
听起来你想使用Executor
什么样的队列?有多少项?石英是不是因为它太大或太小而不能工作?
我会认真考虑在OpenMQ 之类的东西中使用消息队列。
您可以将 JMS 与 ActiveMQ 一起使用,并且可以创建优化的队列系统以及 ESB。并且想要管理基于工作流的系统,那么tpdi是正确的。使用 JBoss jbpm。
您也可以使用 ThreadPool 处理 JMS 消息。在这种情况下,您可以使用 Executors。
演员模型是否适合您的流程?它基于在其他参与者之间异步传递消息的想法。因此,您可以设置一个简单的状态机来为您的流程建模并同时处理所有转换。
您需要确定问题是您正在使用的框架还是您的代码。我建议你测量你的应用程序运行的速度以及如果它根本不做任何事情你的框架将运行多快。(只是传递琐碎的任务)您应该能够使用您的进程内框架每秒执行 100K 到 100 万个任务。即使使用 JMS,您也应该能够达到每秒 10K 条消息。如果您需要每秒执行接近 1000 万个任务,我建议您尝试将任务分组在一起,以便每个任务完成更多工作。
如果您的框架是瓶颈,我会感到非常惊讶,在这种情况下我会建议使用 Executor。
如果框架不是您的可伸缩性和并发问题(这更有可能)的原因,您需要重组您的代码,以便它可以运行更长的时间而没有相互依赖关系。即你必须修复你的代码,框架不会为你做到这一点。
我知道已经晚了 5 年,但这可能会帮助那些被驱赶到这个问题的人。
如今,有http://queues.io,它包含大量排队(和消息传递)框架......