问题标签 [job-scheduling]

我想使用 MySQL 作为作业队列。多台机器将生产和消耗工作。需要安排工作；有些可能每小时运行，有些每天运行，等等。

看起来相当简单：对于每个作业，都有一个“nextFireTime”列，让工作机器使用 nextFireTime 搜索作业，将记录的状态更改为“inProcess”，然后在作业结束时更新 nextFireTime。

当一个工人默默地死去时，问题就出现了。它将无法更新 nextFireTime 或将状态设置回“空闲”。

不幸的是，作业可能会长时间运行，因此无法选择寻找已在进程中时间过长的作业的 reaper 线程。没有超时值可以工作。

任何人都可以建议一种可以正确处理不可靠工作机器的设计模式吗？

如何在单个 UI 中显示多个连续作业？

我的用例如下：

1. 用户操作
2. 开始第一个作业（未知长度）
3. 等待第一个作业完成并开始第二个作业（已知长度）
4. 等待第二个作业完成并开始第三个作业（已知长度）

我想通过以下方式向用户展示：

1. 有一个没有全局进度条的主“用户操作”对话框（因为第一个作业未知并且在执行长度上确实可变，我无法获得准确的总长度）
2. 在此对话框中，每个作业有 3 个子部分，每个作业都有一个进度条，IProgressMonitor.UNKNOWN第一个作业的样式当然也有。
3. 在此对话框中，进度条将作为基础作业按顺序更新。

这将允许最终用户立即看到它的动作被分成了 3 个子任务（这些子任务对最终用户有意义）并且每次启动一个新的子任务时他都可以看到这个子任务的长度（当然第一个未知）。

经过多次搜索，我无法实现这一点，今天我将这 3 个子任务报告为 3 个单独的连续对话，其缺点是最终用户最初可能认为他的操作将在第一个未知子任务结束时完成-任务。

Quartz 可以将作业存储在数据库中，因此它不是易失性的。但是如果我有两个应用程序（网络应用程序和网络服务），我如何在应用程序之间共享这个商店。

也就是说，如果一个应用程序选择一个作业来运行通知其他应用程序。当一个应用程序失败时，它将继续运行

我是Hadoop的初学者。

据我了解，Hadoop 框架以 FIFO 顺序运行作业（默认调度）。

有没有办法告诉框架在特定时间运行作业？

即有没有什么方法可以配置为每天下午 3 点运行该作业？

对此的任何投入都非常感谢。

谢谢，R

我想建立一个作业调度系统，它可以在一个集群上调度作业，该集群将在几个隔离的租户之间共享。

每个租户都需要在这个共享集群上跟踪他们的工作。这样的事情是否已经存在？我很想知道这种调度系统的特点。从节流到安全的东西。非常感谢任何潜在客户。

我正在为以下用例寻找最佳设计。

我正在构建一个系统，用户可以在其中创建具有结束日期/时间的实体。一旦到达结束时间，我需要安排一个作业以将这些实体的状态更改为已过期。

这是我能想到的两个解决方案

• 作业每分钟运行一次并运行查询以检查过期实体（endTime > sysdate）。问题：加载数据库，每分钟运行一次此查询可能会给数据库增加负载。
• 创建实体后，立即为每个实体安排一个作业。 问题：系统中将创建太多工作，每天将创建 1000 个这样的实体。

有没有比上述两个更好的解决方案？人们通常如何做到这一点？

我即将创建一个小型应用程序，它将负责在不同的时间向不同的用户发送各种报告。我们可能会谈论 50 或 100 份不同的报告给不同的人。有些报告需要每天生成，有些需要每周生成，有些需要每月生成。

我之前一直在使用 Quartz 库来定期运行任务。然而，为了简单起见，我喜欢让一个 Quartz 线程处理所有报告的想法。也就是说，线程应该循环遍历所有报告，比如每 15 分钟一次，并确定是否是生成和发送一个或多个报告的时间。无论是在 12:00 还是 12:15 生成报告都没有关系。

我正在考虑是否有可能以某种方式为每个报告设置特定时间，例如“mon@12:00,wed@12:00”或“fri@09:30”。然后，基于此，线程将确定是否该发送报告。

我的问题是；有没有其他人做过这样的事情，是否存在任何可以轻松实现此任务的库？

从 gearman 的主页上，他们提到运行多个作业服务器，所以如果一个作业服务器死了，客户端可以选择一个新的作业服务器。鉴于下面的陈述和图表，作业服务器似乎不相互通信。

我们的问题是那些在死掉的作业服务器中排队的作业会发生什么？为这些服务器提供高可用性以确保作业不会因故障而中断的最佳实践是什么？

您可以运行多个作业服务器，并让客户端和工作人员连接到他们配置的第一个可用作业服务器。这样，如果一个作业服务器死机，客户端和工作人员会自动故障转移到另一台作业服务器。您可能不想运行太多的作业服务器，但拥有两三个是冗余的好主意。

资源

Play 框架的一大优点是它是完全无状态的，并且只面向请求/响应。这真的很好，因为它允许我将我的应用程序部署到云并扩展负载均衡器后面的播放实例的数量，而不必担心状态（会话）复制......

然而，最近，我需要在 HTTP 请求之外执行一些应用程序逻辑，并发现 Play 可以定义完全由框架管理的作业。听起来很棒，但它提出了一个问题：这些工作如何适应 Play 使用的无状态模型？

假设我有一个需要每小时运行的维护任务，我为此定义了一个计划作业。如果我随后在负载均衡器后面部署多个 Play 实例，该作业是否会在每个实例上同时启动？如果是这样，处理需要“独占”运行的作业的好方法是什么？

我正在考虑在非集群服务器上创建一个新的播放实例，重新使用现有（集群）实例的 JPA 模型（从而连接到同一个数据库）。这个新实例将仅包含维护作业，并且由于它托管在非集群服务器上，因此不存在同时运行作业的风险。同时，这将使我能够保持现有的集群实例完全无状态并且易于托管/负载平衡。这是一个好方法吗？

我有一个可以在另一个 11g 环境中编译的包。
当我尝试在带有 DBA 用户的 XE 10g 环境中编译它时，我收到 ORA-00942 错误。

当我在表上执行直接选择时没有问题。

错误文本：