我想向社区提出一个问题，尽可能多地收集关于我一直在思考的策略的反馈，以解决我项目中的一些性能问题。
背景信息：
我们有一个执行4个步骤的重要流程。
步骤1和2是相互关联的，它们是关键的。
步骤3和4并不重要。甚至不关心它们是否成功结束。
1-2的性能很好，但在某些情况下3-4的速度非常慢。主要是导致第3步。
如果我们将所有步骤作为序列执行，则有时步骤3会导致超时。客户没有得到关于步骤1和2（重要的）的任何回复，用户不知道最新情况。
这个案例让我想到了JMS队列，以便将最后两个步骤委托给另一个应用程序/进程。从业务逻辑中解除分配通知。第二次出口和邮寄将在可能时并且可能并行处理。我也可以将它分成2个队列：导出，邮件通知。
我们的webapp会运行到WebLogic 11群集中，因此我可以使用它的实现。
您如何看待该策略？ WebLogic JMS实现有什么好处吗？我应该检查另一个实现吗？ ActiveMQ，RabbitMQ，......
我还考虑过使用spring-tasks来实现tiketing系统的实现。
此时我必须指向春季批次。它的用途有限。我们已经有很多工作专注于重要的数据整合流程，而且分配更多工作的时间窗口有限。加上一次性大规模处理所有物品的影响。
如果我们找到一种方法来使用春季批次的多线程，我们可以做到，但我们还没有找到适合这种策略的方法。
提前谢谢你，原谅我的英语。我保证会继续努力： - ）。
答案 0 :(得分：0)
需要考虑的一个问题是数据完整性。如果步骤n失败，步骤n-1是否需要反转？您需要注意哪些排序依赖项？你在写相同或不同的CSV吗？如果相同，则可能存在争用问题。
现在，回到原来的问题。我会考虑Java执行器，使用4个固定大小的池，并在成功发生时将任务移动到池中：
池本身虽然是固定大小的，但对于池1/2来说可能更大以获得最大吞吐量（并尽可能快地返回到客户端）并且池3/4可能更小但仍然足够大以获得已完成的工作。
您可以使用JMS执行类似的操作，但问题类似：您需要为每个侦听器设置多个侦听器或多个线程，以便您可以以适当的速度进行处理。您可以在没有池的情况下同步执行1/2步骤，但是您没有得到执行程序为您提供的一些线程管理。您仍然需要通过将它们放在JMS队列上来“安排”步骤3/4，并且仍然有侦听器来处理它们。
从服务器关闭恢复的能力是关键，但Executors / ExecutorService没有持久性，所以我肯定会关注JMS（然后我会排队绝对一切，甚至前两步）但根据您的使用情况，它可能有点矫枉过正。
答案 1 :(得分：0)
是的，一种事件驱动的方法，消息总线使集成听起来很好。他们是异步的，所以你不会超时。当然，您需要使用主题。当服务器中有太多消息时，WLS会出现一些内存问题，也许不同的服务器可以更好地分离关注点和资源。