用于队列处理的java API或框架
我需要一个开源 java API 或框架来处理队列中的项目。我可以自己开发一些东西，但不想重新发明轮子（而且我在多线程方面没有太多经验）。有这样的事吗？
我能想到的最接近的解决方案是业务流程管理（BPM）解决方案。
现在，我正在使用多个 Quartz 作业来处理队列中的项目。由于可扩展性和并发性问题，它并没有真正发挥作用。
i need an open-source java API or framework for processing items in a queue. i can develop something myself, but do not want to re-invent the wheel (and i don't have much experience in multi-threading). is there such a thing?
the closest solution that i can think of is a business process management (BPM) solution.
right now, i am using multiple Quartz jobs to process the items in my queue. it is not really working out because of scalability and concurrency issues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
听起来你想使用 执行者
Sounds like you'd want to use an Executor
什么样的队列？有多少项目？ Quartz 不工作是因为它太大或太小吗？
我会认真考虑在 OpenMQ 等中使用消息队列。
A queue of what sort? How many items? Is Quartz not working out because it's too big or too small?
I'd give some serious thought to using message queues in something like OpenMQ.
您可以将 JMS 与 ActiveMQ 结合使用，并可以创建优化的队列系统以及 ESB。如果想要管理基于工作流的系统，那么 tpdi 是正确的。使用 JBoss jbpm。
您还可以使用 ThreadPool 处理 JMS 消息。在这种情况下，您可以使用执行器。
You can use JMS with ActiveMQ and can create optimized queue system as well as ESB. And want to manage workflow based system then tpdi is right. Use JBoss jbpm.
You can process JMS messages with ThreadPool also. In this case, you can use Executors.
参与者模型适合您的流程吗？它基于在其他参与者之间异步传递消息的想法。因此，您可以设置一个简单的状态机来对流程进行建模，并同时处理所有转换。
Would the actor model fit your process? It's based around the idea of asynchronously passing messages between other actors. So you can set up a simple state machine to model your process and have all the transitions handled concurrently.
您需要确定问题是您正在使用的框架还是您的代码。我建议您测量应用程序的运行速度以及框架在不执行任何操作的情况下的运行速度。 （只是传递一些琐碎的任务）您应该能够使用进程内框架每秒执行 10 万到 100 万个任务。即使使用 JMS，您也应该能够实现每秒 10K 条消息。如果您需要每秒执行接近 1000 万个任务，我建议您尝试将任务分组在一起，以便每个任务完成更多工作。
如果您的框架是瓶颈，我会感到非常惊讶，在这种情况下我建议使用执行器。
如果框架不是导致可扩展性和并发问题（可能性更大）的原因，那么您需要重组代码，以便它可以运行更长时间而不存在相互依赖性。也就是说，你必须修复你的代码，框架不会为你做这件事。
You need to determine if the problem in is the framework you are using or your code. I suggest you measure how fast your application is running and how fast your framework will go if its not doing anything at all. (just passing trivial tasks around) You should be able to perform between 100K to 1 million tasks per second using your in process framework. Even using JMS you should be able to achieve 10K messages per second. If you need to do closer to 10 million tasks per second, I suggest you try grouping your tasks together so each task does more work.
I would be very surprised if your framework was the bottleneck in which case I would suggest using an Executor.
If the framework isn't the cause of your scalability and concurrency issues (which is more likely) you need to restructure your code so it can run for longer periods of time without inter dependencies. i.e. you have to fix your code, a framework won't do that for you.
我知道已经晚了 5 年，但这可能会对其他陷入这个问题的人有所帮助。
如今，有 http://queues.io，它包含大量排队（和消息传递）框架。 。
I know it is 5 years late, but this might help someone else that has been driven into this question.
Nowadays, there is http://queues.io and it contains a whole lot of queuing (and messaging) frameworks...