第 15 章 红帽构建的 Quarkus 上的 OptaPlanner 构建： vaccination appointment 调度程序快速启动指南

Red Hat build of OptaPlanner vaccination appointment 调度程序限制是 hard, medium, 或 soft:

硬约束会根据其他硬限制来加权。软限制是针对其他软限制的权重。但是，硬限制总是优先于中型和软限制。如果硬约束被破坏，则计划不可行。但是，如果没有硬约束问题，则软和中等约束会被考虑以确定优先级。因为用户通常比可用的单点插槽更多，所以您必须优先选择。第二天首先被分配为始终分配点数，以避免创建稍后给您的系统造成放大的积压。之后，会根据优先级评级来分配人员。每个人都以优先级评级开头，即其年龄。这样做会优先选择较早的人。之后，位于特定优先级组的人员收到，例如，几百个额外的点。这因组的优先级而异。例如，nurses 可能会收到额外的 1000 个点。这样，较早的 nurses 优先考虑不久的人。下表描述了这个概念：

在 OptaPlanner 的核心是 solver，引擎会获取问题数据集并覆盖规划限制和配置。问题数据集包含有关人员、vaccines 和 vaccination 数据中心的所有信息。解决者通过各种数据组合工作，最终确定了特定中心分配给 vaccination appointments 的人员的优化情况。下图显示了 solver 创建的调度：

View larger image

持续规划是同时管理一个或多个即将推出的规划周期的技术，并重复这个过程每月、每周、每天、每小时甚至更频繁地重复该过程。规划窗口以指定间隔逐步推进。下图显示了每天更新的两周规划窗口：

View larger image

两周规划窗口将划分成一半。第一周处于 published 状态，第二周处于草案状态。人们在规划窗口的出版和草案部分中都分配到了一场点。但是，只有发布了计划窗口一部分的人员才会获得他们的意见通知。在下一次运行中，其他 appoints 仍然可以变化。这样做可让 OptaPlanner 在您再次运行解决方案时，灵活地更改草案中的点子部分。例如，如果需要第二天的个人准备日期为 Monday，并且理想的日期为 Wednesday，OptaPlanner 不必为他们留出一场点，如果您可以证明 OptaPlanner 可以演示它以后可以于周的草案。

您可以确定 planning 窗口的大小，但只了解问题空间的大小。问题空间是创建计划的各种元素。您提前规划的天数越大，问题空间越大。

如果您每天都要不断规划，那么在已经分配给了人的两周期间，将有点数。为确保 appointments 没有双书，OptaPlanner 将现有的 appointments 标记为固定它们所分配的。固定用于分配一个或多个特定分配，并强制 OptaPlanner 根据这些固定分配进行调度。固定计划实体（如 appointment）在解决过程中不会改变。

实体是固定的，是否由 appointment 状态决定。Appointment 可以有五种状态： Open、Invited、Accepted、Rejected 或 Rescheduled。

您需要规划已计划的一个点数。已固定带有 Invited 或 Accepted 状态的 appointment。带有 Open、Reschedule 和 Rejected 状态的点数不会被固定，并可用于调度。

在本例中，当 solver 运行它在发布和草案范围内的整个双周规划窗口时，除了未计划输入数据外，该方案还考虑了任何未固定的实体，以及 开放、重新排期 或拒绝状态的任何非固定实体，以找到最佳解决方案。如果解析器每天运行，您将在运行 solver 前看到添加到计划的新日期。

请注意，新日的点数已被分配，并且之前在规划窗口草案中的 Amy 和 Edna 调度到该窗口的发布部分。这是因为 Gus 和 Hugo 请求重新调度。这不会造成混淆，因为 Amy 和 Edna 永远不会收到其草案日期的通知。现在，因为它们在计划窗口的公布的部分中有点，因此它们会被通知并要求接受或拒绝其 Appointments，现在被固定。