为每秒甚至不到一秒安排简单的 GET 批处理 - 应选择 Spring Cloud Task、Spring Batch 或 springframework.scheduling
Schedule simple GET batch for each second or even less than one second - Should opt for Spring Cloud Task, Spring Batch or springframework.scheduling
上下文：在我的国家/地区，将在 11 月预览一种新的即时付款方式。基本上，中央银行将提供两个端点：(1) 一个 POST 端点，我们 post 一次汇款和 (2) 一个 GET 端点，我们在其中获取之前发送的汇款结果和它可能完全失灵。它将仅在汇款结果上回复，并且在其 header 中将通知我们是否必须获取另一个结果。它从不告知有多少结果可用。如果有结果，它会返回 Get 响应，并且只通知它是否是最后一个或是否有剩余的结果用于下一个 GET。
最高限制：从最终用户点击 his/her 移动应用程序中的“传输”按钮到最终结果显示在他的移动屏幕上（成功或失败）为 10 秒。
策略：我想要一个每秒或什至不到一秒触发 Get to Central Bank 的时间表。 Scheduler 基本上会调用一个简单的函数
- 调用 Get 端点
- 将其推送到 Kafka 或持久保存在数据库中并且
- 如果在答案 header 中通知有更多结果可用，请再次启动相同的功能。
问题：由于我们是 Spring users/followers，我虽然我的决定是在 Spring 批处理与 org.springframework.scheduling.annotation.SchedulingConfigurer/TaskScheduler 之间。我已经成功地使用了 Spring Batch 一段时间，但从未使用过如此短的时间触发（从未使用过 1 秒时间）。我偶然发现了讨论，这促使我思考如果在我的情况下，一个非常简单但周期很短的任务，我应该考虑 Spring Cloud Data Flow 或 Spring Cloud Task 而不是 Spring批量.
根据 “... Spring 批处理是...专为构建复杂的计算问题而设计...您可以使用 Spring 调度程序，如果你愿意的话”。基于此，我似乎不应该使用 Spring Batch 因为我的情况并不复杂。挑战设计决策更多地考虑短期触发并从当前批次触发另一个批次，而不是转换、计算或 ETL 过程。尽管如此，据我所知，Spring Batch with its tasklet 是 well-designed 用于重新启动、恢复和重试，并且非常适合永远不会完成的场景，而 org.springframework.scheduling 似乎只是一种方法根据周期配置触发事件。嗯，这是我根据个人使用和研究的补充。
根据对有人询问组合任务编排的回答this answer“...您可以使用 Spring 云数据流和 Spring 云来实现您的设计目标Task/Spring 批次...”。就我而言，我没有看到组合任务。在我的例子中，第二个触发器不依赖于前一个触发器的结果。这听起来更像是“链接”任务而不是“组合”任务。我从未使用过 Spring 云数据流，但它似乎是 Manage/View/Console/Dashboards 触发任务的不错选择。尽管如此，我没有在任何地方找到关于短期触发器和“链式”触发器的限制或经验法则。
所以我的直截了当的问题是：目前推荐 Spring 成员的触发时间这么短是什么？假设 Spring Cloud Data Flow 用于 manager/dashboard 在如此短的触发场景中推荐的 Spring 中的触发器成员是什么？ Spring Cloud Task 似乎是为调用复杂函数而设计的，Spring Batch 似乎添加的内容超出了我的需要，org.springframework.scheduling。* 缺少与 Spring Cloud Data Flow 的集成。作为类比而不是比较，在 AWS 中，文档明确表示“不要使用 CloudWatch 少于一分钟。如果您想要少于一分钟，请每分钟启动 CloudWatch，每秒启动另一个 scheduler/cron ”。对于需要每秒或什至少于一秒触发的简单任务，可能有 well-know 经验法则，并利用 Spring 家族 approach/concerns/experience.
这可能是个愚蠢的答案。为什么这里需要调度程序？永无止境的工作不就可以实现这里的目标吗？
- 你开始一个工作，它做了一个
GET请求，将结果推送到kafka，
- 如果
GET 响应表明，它有更多结果，它立即再次执行 GET，将结果推送到 kafka
- 如果
GET 响应指示，没有更多结果，sleep for 1 second，再次执行 GET 请求。
上下文：在我的国家/地区，将在 11 月预览一种新的即时付款方式。基本上，中央银行将提供两个端点：(1) 一个 POST 端点，我们 post 一次汇款和 (2) 一个 GET 端点，我们在其中获取之前发送的汇款结果和它可能完全失灵。它将仅在汇款结果上回复，并且在其 header 中将通知我们是否必须获取另一个结果。它从不告知有多少结果可用。如果有结果，它会返回 Get 响应，并且只通知它是否是最后一个或是否有剩余的结果用于下一个 GET。
最高限制：从最终用户点击 his/her 移动应用程序中的“传输”按钮到最终结果显示在他的移动屏幕上（成功或失败）为 10 秒。
策略：我想要一个每秒或什至不到一秒触发 Get to Central Bank 的时间表。 Scheduler 基本上会调用一个简单的函数
- 调用 Get 端点
- 将其推送到 Kafka 或持久保存在数据库中并且
- 如果在答案 header 中通知有更多结果可用，请再次启动相同的功能。
问题：由于我们是 Spring users/followers，我虽然我的决定是在 Spring 批处理与 org.springframework.scheduling.annotation.SchedulingConfigurer/TaskScheduler 之间。我已经成功地使用了 Spring Batch 一段时间，但从未使用过如此短的时间触发（从未使用过 1 秒时间）。我偶然发现了讨论，这促使我思考如果在我的情况下，一个非常简单但周期很短的任务，我应该考虑 Spring Cloud Data Flow 或 Spring Cloud Task 而不是 Spring批量.
根据
根据对有人询问组合任务编排的回答this answer“...您可以使用 Spring 云数据流和 Spring 云来实现您的设计目标Task/Spring 批次...”。就我而言，我没有看到组合任务。在我的例子中，第二个触发器不依赖于前一个触发器的结果。这听起来更像是“链接”任务而不是“组合”任务。我从未使用过 Spring 云数据流，但它似乎是 Manage/View/Console/Dashboards 触发任务的不错选择。尽管如此，我没有在任何地方找到关于短期触发器和“链式”触发器的限制或经验法则。
所以我的直截了当的问题是：目前推荐 Spring 成员的触发时间这么短是什么？假设 Spring Cloud Data Flow 用于 manager/dashboard 在如此短的触发场景中推荐的 Spring 中的触发器成员是什么？ Spring Cloud Task 似乎是为调用复杂函数而设计的，Spring Batch 似乎添加的内容超出了我的需要，org.springframework.scheduling。* 缺少与 Spring Cloud Data Flow 的集成。作为类比而不是比较，在 AWS 中，文档明确表示“不要使用 CloudWatch 少于一分钟。如果您想要少于一分钟，请每分钟启动 CloudWatch，每秒启动另一个 scheduler/cron ”。对于需要每秒或什至少于一秒触发的简单任务，可能有 well-know 经验法则，并利用 Spring 家族 approach/concerns/experience.
这可能是个愚蠢的答案。为什么这里需要调度程序？永无止境的工作不就可以实现这里的目标吗？
- 你开始一个工作，它做了一个
GET请求，将结果推送到kafka， - 如果
GET响应表明，它有更多结果，它立即再次执行GET，将结果推送到kafka - 如果
GET响应指示，没有更多结果，sleep for 1 second，再次执行GET请求。