Java 应用程序设计：Spring集成中的数百个文件轮询

我和同事讨论了我们在Weblogic中构建的应用程序的体系结构。应用程序的要点如下。文件被放置在网络驱动器上，完成一些处理，文件被移出。这些文件属于称为事务的类别。争论的焦点是，最好将不同事务的所有文件放在一个文件夹中，并让一个入站文件适配器查看该文件夹，还是按事务将文件夹分开，并让每个事务有一个入站文件适配器

该系统可以有几百个事务，因此如果是1:1的比例，将有数百个轮询器。也可以对它们进行分组，但我们仍然可能有50多个目录

并非所有事务都具有相同的吞吐量要求。有些需要近实时地获取，有些，每天只需查看一次文件夹，然后获取。有些事务每天可能有数万个文件

第一个组件从一个目录获取文件名，将文件移动到下一个文件夹，并在队列上放置一条消息，提醒下一个下游组件处理该文件

1目录的优点：

• 您只有一个线程在运行

缺点：

• 你需要不断地快速投票。您将在稳定性方面趋于平稳，因为一个入站适配器每秒只能在每个目录中拾取一定数量的文件。如果使用多个JVM，轮询者将争夺谁可以锁定某个文件并移动它

许多目录的优点：

• 您可以更好地控制如何提取事务。事务XYZ可能只需要计划每天运行一次，而ABC每5分钟运行一次。XYZ不会妨碍ABC。因此，如果有10000个XYZ文件和1个ABC文件，ABC将很快被接收
• 可伸缩性。若我有100个目录，但我发现并没有足够的资源，我可以部署5个“文件接收者”，让每个人查看20个不同的目录（顺便说一句，我的同事想构建一个整体……而我想将每个组件分解为每个可部署组件，但理论上，如果分解，我相信它更具可扩展性，因为我们可以增加接收器的数量）

缺点：许多入站适配器线程轮询（但并不总是主动轮询）

我向社区提出的问题是——就Spring Integration而言，在应用程序中启动数百个入站文件适配器有多可怕？可能会出现什么问题？我假设当入站文件适配器没有列出目录时，它相当空闲，并且不消耗任何资源

我们使用Weblogic作为应用服务器，我的同事还建议使用Work Manager来管理系统其他部分的线程资源。这也可以用来处理数百个入站适配器吗

---

谢谢！

轮询器共享一个任务计划程序，默认池有10个线程，但可以增加。因此，这不是一个真正的问题-是的，轮询之间不消耗任何资源

第一个组件从一个目录获取文件名，将文件移动到下一个文件夹，并在队列上放置一条消息，提醒下一个下游组件处理该文件

由于轮询器所做的工作很少（移动文件并将消息发送到队列），因此我不认为拥有单个实例（可能具有热备用）是一个限制因素

我的同事想构建一个整体……而我想将每个组件分解成它的每个可部署组件

---

我同意你的方法。使用中间件（JMS、RabbitMQ）要分配工作，您可以增加每个实例中的使用者线程，并根据需要添加更多实例。

轮询器共享一个任务计划程序，默认池有10个线程，但可以增加。因此，这不是一个真正的问题-是的，轮询之间不消耗任何资源

第一个组件从一个目录获取文件名，将文件移动到下一个文件夹，并在队列上放置一条消息，提醒下一个下游组件处理该文件

由于轮询器所做的工作很少（移动文件并将消息发送到队列），因此我不认为拥有单个实例（可能具有热备用）是一个限制因素

我的同事想构建一个整体……而我想将每个组件分解成它的每个可部署组件

---

我同意你的方法。使用中间件（JMS、RabbitMQ）要分配工作，您可以增加每个实例中的使用者线程，并根据需要添加更多实例。

嗨，Gary，谢谢您的回复。我正在阅读附录F.3节。您对10个线程的引用是默认的TaskScheduler？因此，这10个线程将跨整个应用程序？例如如果应用程序有一个文件出站适配器，该适配器将共享10个线程？或者只有计划任务共享这10个线程。如果是后者，出站适配器从何处获取资源？因为我们也有许多出站适配器。附录还说，对于JEE容器，我们应该使用TimerManager任务调度器，因为我们正在使用WebLogic，我们应该这样做。出站适配器（通常）是被动的，在调用线程上执行。每个轮询都是提交给

taskScheduler

bean的计划任务。下一个轮询在下游流完成时计划

a）

，或者在任务移交给另一个线程时计划

b）

（例如，如果轮询器有一个

任务执行器

）。因此出站端点的数量并不重要-只有轮询器（和某些其他计划任务）竞争调度器。如果您有队列通道中流，则他们的轮询器