分布式算法设计

9
我一直在阅读《算法导论》,开始在脑海中涌现出一些想法和问题。其中最困扰我的是如何设计一个分布式队列调度算法。
我的思路引导我浏览了维基百科上的一些主题,例如排序、消息队列、调度、分布式哈希表等等。
场景如下:假设你想要拥有一个排队系统,用于排列消息(例如字符串或某些序列化对象)。此系统的一个关键特性是避免任何单点故障。该系统必须分布在某个集群内的多个节点上,并且必须始终尽可能平衡集群内每个节点的工作负载,以避免热点。
您希望避免使用主/从复制和扩展的设计(没有单点故障)。该系统完全避免写入磁盘,并维护内存数据结构。
由于这是一个队列,因此该系统应能够使用各种调度算法(FIFO、最早截止时间、轮询等)来确定哪个消息应在下一个请求上返回,而不管请求是在集群中的哪个节点上发起的。
我的初始想法是,我可以想象这在单个机器上如何工作,但当我开始考虑如何分发这样的东西时,就会产生一些问题,比如:
如何对每个消息进行哈希?
如何知道消息发送到了哪个节点?
如何安排每个项目,以便我可以确定下一个应返回哪个节点的哪个消息?
我开始阅读有关分布式哈希表的内容,以及像Apache Cassandra这样的项目如何使用某种一致性哈希来分发数据,但后来我想,由于查询不会提供密钥,我需要知道下一个项在哪里,然后才能提供它...
这进一步引导我阅读点对点协议以及它们如何跨节点处理同步问题。
所以我的问题是,你会如何解决上述描述的问题,或者这太牵强附会了,只是一个愚蠢的想法...?
简要概述、指针、不同的方法、各自的优缺点。可能适用的技术/概念/设计/理论。基本上任何有助于理解这样的东西如何工作的东西。
如果你想知道,不,我并不打算实现任何类似的东西,只是在阅读时突然想到的(这种情况经常发生,当我读一本好书时会被狂野的想法分心)。

更新

另一个有趣的问题是分布式删除。我知道像Cassandra这样的系统通过实现HintedHandoffRead RepairAntiEntropy来解决这个问题,而且似乎效果很好,但还有其他(可行且有效)的解决方法吗?


我有点不知所措,但我会喝杯咖啡,很快再看一遍。非常感谢。 - Caffeinated
1
你期望/愿意有多少工作重复?我的意思是,你安排了一些工作,两台或更多不同的计算机开始计算它。如果你不想有任何重复,那将很难实现。如果你想在单台计算机上执行类似的操作,你需要一个单独的工作队列,即使这样,你通常也需要使用锁定。 - svick
我觉得你误解了我的意思。我所说的问题是,如果你不想要任何工作复制。我认为在你的去中心化设置中做到这一点会非常困难。 - svick
@svick:有一些可以简化的可能性,请看下面我的答案。 - DaveFar
@svick 抱歉,我确实误解了。我不确定,但我认为可以采用DaveBall建议的领导选举算法之一,例如,接收写请求的节点有更好的机会成为领导者,除非它处于高负载状态。然后,领导者协调该消息的工作以及其被选为领导者的任何其他消息。这样做,其他节点需要做的唯一工作就是存储消息的副本,并知道其选定的领导者。 - zcourts
显示剩余2条评论
1个回答

4

概述,如您所需

有一些流行的分布式算法技术,例如使用时钟通用路由算法

您可以在优秀的分布式算法书籍 《Introduction to distributed algorithms》 by Tel《Distributed Algorithms》 by Lynch 中找到这些技术。

简化

特别是对于复杂的一般分布式算法,简化很有用。您可能能够将其简化为更简单、更具体的情况。

例如,如果您想避免单点故障,但对称分布式算法太过复杂,您可以使用标准的(leader) election分布式算法,然后使用更简单的非对称算法,即可以利用主节点的算法。

同样地,您可以使用 同步器 将同步网络模型转换为异步网络模型。
您可以使用 快照 来进行离线分析,而不必处理在线进程状态的变化。

Tel的《分布式算法简介》看起来很有趣。我喜欢使用领导者选举算法的想法,我可以想象它如何使复制更容易,但对于快照,我不太确定。在系统具有极高的读/写速率的情况下,快照算法是否会导致某些项目过时,因为它已从读取请求的队列中推出,但复制需要太长时间才能传播?另一件事是我刚想到的,分布式删除将如何处理?我会更新我的问题。 - zcourts

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接