我有一个API，该API具有一系列端点，这些端点都执行非常长时间运行的作业，例如，可能需要48个小时才能完成的作业。
当然，我不能让客户等待48小时才能返回响应，因此我正在寻找解决这些情况的最佳解决方案。
我对应该做什么有一个想法，但是我不确定这是一个值得解决的解决方案还是在基于生产的应用程序中如何完成。此外，我想实现一种在需要时取消作业运行并更新/监视作业总体进度的方法。
我当前的设置如下：
API收到了开始长期工作的请求
作业信息条目存储在数据库中，并且作业状态设置为“待处理”
该作业信息被放置在Rabbit MQ消息中，并由RabbitMQ生产者发送出去
作业ID被重新调回到以202接受状态启动API调用的客户端
RabbitMQ使用者接收到带有作业信息的消息，并调用负责执行长时间运行的作业的类，作业状态已更新为“进行中”
现在，客户端可以通过另一个接受作业ID并返回当前状态/信息的端点来检查作业的状态
我认为这种方法可行，并且似乎可扩展，但是我担心可能有人会对我有所了解或帮助我解决：
A。我希望能够根据需要从另一个暴露的端点终止工作，完成这种事情的最佳方法是什么？我在想，当服务将状态更新为“进行中”并开始处理时，也许我还可以在步骤5中将线程ID与作业信息一起保留。然后，当我点击取消作业端点时，我可以给它作业ID，然后杀死相关的线程。这是可行的解决方案，还是有更好的解决方案？
B。我想实施一个更新策略，使我可以量化该工作的总体进度，因此，我不仅可以看到前端的“正在进行中”或“待处理”，还可以看到已完成工作的百分比。前端将是一个桌面应用程序，因此最终我想使用此信息来支持进度条。但是，我担心性能，因为每当进度增加时，我就需要不断地向作业表写入数据，并且当端点检查客户端的状态时，还需要不断地从表中读取数据（I'我每10秒左右思考一次）是否有更好的解决方案根据给定的信息进行处理？
如果有任何不同，一次只能处理一项工作...这是针对管理门户的，因此只有少数人可以使用此功能，并且如果特定的工作类型已经在进行中，则除非类型为COMPLETE，CANCELLED或FAILED，否则其他类型的
答案 0 :(得分：0)
可能的解决方案是当API收到启动作业的请求时，返回新创建作业的作业ID。
具有另一个端点来跟踪作业的状态并管理其生命周期。像
/Jobs/Status/<Job-ID>
GET将返回当前状态和完成百分比。 DEL可以停止杀死现有的正在运行的作业。
您可以每10分钟轮询一次提到的作业状态。