公平分布式资源分配共识推荐算法

Posted 2023-03-24

【中文标题】公平分布式资源分配共识推荐算法

【英文标题】：Recommend algorithm of fair distributed resources allocation consensus

【发布时间】：2021-02-05 07:55:04

【问题描述】：

存在分布式计算节点，并且存在由数据库表中的行表示的一组计算任务（每个任务一行）：

一个节点没有其他节点的信息：不能和其他节点通话，甚至不知道有多少其他节点 可以添加和删除节点，节点可能会死亡并重新启动 仅连接到数据库的节点 每个节点的任务数没有限制 任务池不是有限的，新任务总会到来 节点通过使用某个时间戳标记该行来获取任务，以便在该时间戳之后经过某个超时之前其他节点不会考虑它（以防节点死亡且任务未完成）

目标是在节点之间平均分配任务。为此，我需要定义一些常见的任务获取算法：一个节点启动时，要接多少个任务？

如果一个节点承担所有可用任务，当一个节点总是忙而其他节点空闲时。所以这不是一个选择。

一个好的方法是让每个节点一个接一个地执行任务，但会有一些延迟。所以 每个节点定期（有时​​一次）检查是否有空闲任务并且只接受 1 个任务。这样，在启动后不久，所有节点都会获得或多或少均匀分布的所有任务。但是缺点是由于延迟，处理最后一个任务需要一些时间（假设有 10000 个任务，10 个节点，延迟为 1 秒：需要 10000 个任务 * 1 秒 / 10 个节点= 从开始到完成所有任务需要 1000 秒）。此外，分布是不确定的，可能存在偏差。

问题：哪种/类别的算法可以解决此类问题，允许使用某个同步点（在本例中为数据库）快速均匀地分配任务，无需选举领导者？

例如：节点使用某个表来宣布他们想要执行的任务，然后经过一些协调步骤后达成共识并开始处理等。

【参考方案1】：

所以这归结为需要考虑的几个因素。

目前总共有多少任务可用？ 目前总共接受了多少任务？ 节点在过去 X 分钟内接受了多少任务。 节点在过去 X 分钟内完成了多少任务。 可以修改行字段吗？ （添加了一个字段）。 节点可以在完成当前任务后请求更多任务还是必须立即分发所有任务？

我的倾向是做以下事情：

如果可行，将“节点标识符”字段 (UUID) 添加到包含行的表中。一个节点在运行时会生成一个 UUID 节点标识符。当它接受一个任务时，它会添加一个时间戳，它是 UUID。这很容易让其他节点能够确定有多少“活动”节点。 为了确定分配，节点确定有多少任务可用/接受。然后它会记录有多少唯一节点标识符（包括其自身）已接受任务。然后它使用这个公式来接受更多的任务（最好是随机的，以尽量减少与其他节点竞争的机会）。 2 * available_tasks / active_nodes - nodes_accepted_tasks。因此，如果有 100 个可用任务，10 个活动节点，并且该节点已经接受了 5 个任务。然后它会接受：100 / 10 - 5 = 5 任务。如果节点只是在没有任务时才寻找更多任务，那么您可以使用available_tasks / active_nodes。 为避免出现问题，应该有一个节点一次接受的最大任务数。

如果节点标识符不切实际。我只想说每个节点都应该以采取ceil(sqrt(N))随机任务为目标，其中N是可用任务的数量。如果有 100 个任务。第一个节点占用 10 个节点，第二个节点占用 10 个节点，第 3 个节点占用 9 个节点，第 4 个节点占用 9 个节点，第 5 个节点占用 8 个节点，以此类推。这不会一次均匀地分配所有任务，但会确保节点获得大致偶数的任务。任务数量的轻微错开意味着节点不会同时完成它们的任务（诚然，这可能是可取的，也可能不是可取的）。通过不完全分布它们（除非有 sqrt(N) 节点），它还降低了冲突的可能性（特别是如果任务是随机选择的）。如果节点出现故障，它还可以减少“失败”任务的数量。

这当然假设一个节点在它启动后可以请求更多任务，如果不是，它会变得更加棘手。

至于附加表，您实际上可以使用它来跟踪节点的当前状态。每个节点记录它有多少任务，它是唯一的 UUID 以及它最后一次完成任务的时间。尽管这可能会导致数据库流失的潜在问题。我认为仅记录哪个节点接受了任务以及接受任务的时间可能就足够了。如果节点可以在将来请求任务，这又会更加有用。