spring - 每秒甚至不到一秒安排简单的 GET 批处理 - 应该选择 Spring Cloud Task、Spring Batch 或 springframework.scheduling

Question

背景：在我的国家，11 月将有一种新的即时付款方式预览。基本上，中央银行将提供两个端点：(1) 一个 POST 端点，我们发布单笔汇款；(2) 一个 GET 端点，我们可以在其中获取之前发送的汇款结果，它可能完全无序。它只会回复汇款结果，并在其标题中通知我们是否必须获取另一个结果。它从不告知有多少结果可用。如果有结果，它会在 Get 响应中返回，并且只通知它是最后一个还是有剩余的用于下一个 GET。

最高限制：从最终用户点击其移动应用程序中的“转移”按钮到最终结果显示在其移动屏幕上（成功或失败）的时间为 10 秒。

策略：我想要一个时间表，该时间表每秒触发一次，甚至不到一秒触发一次到达中央银行。调度程序基本上会调用一个简单的函数

1. 调用 Get 端点
2. 将其推送到 Kafka 或持久保存在数据库中
3. 如果在答案标题中通知有更多结果可用，请再次启动相同的功能。

问题：由于我们是 Spring 用户/追随者，我认为我的决定是在 Spring Batch 与 org.springframework.scheduling.annotation.SchedulingConfigurer/TaskScheduler 之间。我已经成功使用了 Spring Batch 一段时间，但从未使用过这么短的触发器（从未使用过 1 秒）。我在讨论中偶然发现，这促使我思考，如果就我而言，这是一项非常简单但时间很短的任务，我应该考虑使用 Spring Cloud Data Flow 或 Spring Cloud Task 而不是 Spring Batch。

根据这个答案“...... Spring Batch ......设计用于构建复杂的计算问题......如果需要，您可以使用 Spring Scheduler 编排 Spring Batch 作业”。基于此，我似乎不应该使用 Spring Batch，因为我的情况并不复杂。挑战设计决策更多地考虑短期触发并从当前批次触发另一个批次，而不是转换，计算或ETL过程。尽管如此，据我所见，Spring Batch 及其 tasklet 是为重启、恢复和重试而精心设计的，并且非常适合永远不会完成的场景，而 org.springframework.scheduling 似乎只是基于时间段触发事件的一种方式配置。嗯，这是我根据个人使用和学习的填充。

根据有人询问有关组合任务的编排的答案，这个答案“......您可以使用 Spring Cloud Data Flow 以及 Spring Cloud Task/Spring Batch 来实现您的设计目标......”。就我而言，我没有看到组合任务。就我而言，第二个触发器不依赖于前一个触发器的结果。这听起来更像是“链式”任务，而不是“组合式”。我从未使用过 Spring Cloud Data Flow，但它似乎是 Manage/View/Console/Dashboards 触发任务的不错选择。尽管如此，我没有找到任何地方通知短期触发器和“链接”触发器的限制或经验法则。

所以我的直截了当的问题是：在这么短的时间内触发当前推荐的 Spring 成员是什么？假设 Spring Cloud Data Flow 用于管理器/仪表板，那么在这么短的触发场景中推荐 Spring 的触发成员是什么？似乎 Spring Cloud Task 是为调用复杂的函数而设计的，而 Spring Batch 似乎添加的内容超出了我的需要，而 org.springframework.scheduling.* 缺少与 Spring Cloud Data Flow 的集成。作为一个类比而不是比较，在 AWS 中，文档明确表示“不要使用 CloudWatch 少于一分钟。如果您想要少于一分钟，请在每分钟启动 CloudWatch，然后每秒启动另一个调度程序/cron”。

标签： springspring-batchspring-cloud-dataflowspring-cloud-task

Answer 1

这可能是愚蠢的答案。为什么在这里需要调度程序？永无止境的工作不会在这里实现目标吗？

• 您开始一项工作，它会发出GET请求，然后将结果推送到kafka，
• 如果GET响应表明，它有更多的结果，它会立即GET再次执行，将结果推送到kafka
• 如果GET响应指示，没有更多结果，请再次sleep for 1 second执行GET请求。