标签: distributed-computing

我想开展一个长达2-3个月的项目(全职),涉及用C++编码,并与网络(协议栈)相关.我正在考虑编写自己的网络堆栈,但这看起来并不那么有趣.很高兴找到一个为分布式系统/ GPU实现类似tcp/ip的堆栈的想法,就网络性能而言更好.我一直在谷歌搜索3个小时,但没有看到任何看起来值得花2个月的东西.像netperf这样的开源项目似乎超出了我的范围.我真的很喜欢一个相对较小的独立项目,我可以按照自己的步调进行工作.这个项目的目的是利用我的项目空闲时间(我可能稍后在开源许可下发布),并获得C++,网络,并行编程,GPU,分布式系统等方面的专业知识和实践经验.

我似乎在找到想法时遇到了障碍(或者我可能不太清楚我究竟该做什么).所以任何建议都会非常感激.谢谢!

Backgound:

在第3节,名为实施状态机,Lamport的论文Paxos Made Simple,Multi-Paxos被描述.Multi Paxos用于Google Paxos Made Live.(Multi-Paxos用于Apache ZooKeeper).在Multi-Paxos中,可能会出现差距:

通常,假设领导者可以?提前获得命令 - 也就是说,它可以在选择命令1到之后i + 1通过i + ?命令提出命令i.? - 1然后可能出现高达命令的差距.

现在考虑以下场景:

整个系统使用主从架构.只有主服务器提供客户端命令.Master和Slaves通过Multi-Paxos就命令序列达成共识.Master是Multi-Paxos实例的领导者.现在假设主服务器及其两个从服务器具有下图所示的状态(已选择命令):

.

请注意,主状态中存在多个间隙.由于不同步,这两个奴隶落后了.这时,主人失败了.

问题:

1. 在检测到主设备故障后,从设备应该做什么(例如,通过心跳机制)？

2. 特别是,如何处理与旧主人的差距和缺失的命令？

关于Zab的更新:

正如@sbridges指出的那样,ZooKeeper使用Zab而不是Paxos.报价,

Zab主要用于主备份(即主从)系统,如ZooKeeper,而不是用于状态机复制.

似乎Zab与我上面列出的问题密切相关.根据Zab的简短概述文件,Zab协议包括两种模式:恢复和广播.在恢复模式下,会做出两个特定的保证:永远不会忘记已提交的消息并放弃跳过的消息.我对Zab的困惑是:

3. 在恢复模式下Zab是否也存在缺口问题？如果是这样,扎布做什么？

什么是使分布式队列打勾的架构模式/解决方案？

请分享订购和非订购类型.

MPI_IN_PLACE当作为参数给出MPI_Scatter以及如何使用它时究竟做了什么？我无法理解man MPI_Scatter:

当通信器是一个内部通信器时,您可以就地执行收集操作(输出缓冲区用作输入缓冲区).使用变量MPI_IN_PLACE作为根进程recvbuf的值.在这种情况下,将忽略recvcount和recvtype,并且根进程不会向其自身发送任何数据.由于就地选项将接收缓冲区转换为发送和接收缓冲区,因此包含INTENT的Fortran绑定必须将这些标记为INOUT,而不是OUT.

我想要做的是使用包含根数据的相同缓冲区作为每个其他进程的接收缓冲区(如in MPI_Bcast).将MPI_Scatter有MPI_IN_PLACE让我做到这一点？

我有以下格式的 JSON 数据：

{
     "date": 100
     "userId": 1
     "data": [
         {
             "timeStamp": 101,
             "reading": 1
         },
         {
             "timeStamp": 102,
             "reading": 2
         }
     ]
 }
 {
     "date": 200
     "userId": 1
     "data": [
         {
             "timeStamp": 201,
             "reading": 3
         },
         {
             "timeStamp": 202,
             "reading": 4
         }
     ]
 }

我将其读入 Spark SQL：

val df = SQLContext.read.json(...)
df.printSchema
// root
//  |-- date: double (nullable = true)
//  |-- userId: long (nullable = true)
//  |-- data: array (nullable = true)
//  |     |-- element: …

我正在尝试构建一个分布式系统来运行一些性能密集型计算.一个计算可以在多个工作节点处并行完成.问题是,随着数据源实时变化,我们希望每个工作节点(在单次计算期间)对相同的"版本"数据进行操作,即数据库的时间点快照.这是为了避免不一致的结果.

另一个问题是,每次计算的整个输入数据集可能非常大,因此目前我们在每个工作节点保留一个本地缓存,通过向数据源询问当前本地缓存版本的"差异"来定期刷新内容.将差异应用于本地缓存.

有哪些设计策略可以满足每个工作节点看到相同"数据"数据的要求(同时仍然有相当新鲜的数据)？我已经考虑过下面的解决方案,但想看看这是否是一个已经解决的常见模式:

• 构建一个"版本控制"服务,定期查询数据源的差异,并将每个差异存储为数据"版本".工作节点的缓存与版本控制服务同步,并且还将其缓存数据保留在多个版本中.对于一个计算,我们确保工作节点使用相同版本的输入数据来实现一致性.此版本控制服务还应保留工作节点的整个数据集的最新副本,以便最初加载其缓存,并在工作节点关闭并重新启动时恢复本地缓存内容.

一些估计的系统参数:

• 工人人数:10

• 平均工作时间:显然我们希望这个尽可能快,但是假设应该不到2分钟

• 输入作业数据(所有工人的总体数据):~100GB

• 数据库大小:~1TB

我正在寻找分布式计时器服务。多个远程客户端服务应该能够在指定的时间间隔后注册回调（通过 REST api）。间隔的长度可以是 1 分钟。我可以忍受大约 1 分钟的误差。此类回调的数量目前可以达到 100,000，但我以后需要扩大规模。我一直在寻找类似的调度程序，Quartz但我不确定它们是否适合这个问题。使用Quartz，我可能不得不将回调请求保存在数据库中，并每分钟轮询 100,000 行的过期请求。我不确定这会扩大规模。是否有任何开箱即用的解决方案？否则，我该如何建造一个？

我在网上找到了两个定义：

顺序一致性——任何执行的结果都是一样的，就好像所有处理器的操作都是按某种顺序执行的，每个处理器的操作都按照其程序指定的顺序出现在这个序列中。

最终一致性——如果没有对给定数据项进行新的更新，最终对该项目的所有访问都将返回最后更新的值。

这些定义对我来说很清楚。但是，当最终一致性不是连续的时，我不明白。一个例子：mem 中的初始值是 0。横轴是时间。

P1:      write 1             (x)
P2:  read 0    read 0 read 0     read 1   read 1    read 1

因此，有一些顺序顺序，如果我们在 (x) 槽中放置“写入 1”，这就是顺序一致性的定义。我哪里错了？

我一直无法找到适合Vector Clocks和Version Vectors 的用例以及它们可能有何不同的示例。我知道它们在很大程度上以相同的方式工作，向量时钟使用receive和send函数，版本向量使用sync函数，但我不明白这两个选项之间的区别。它只是表达同一事物的两种不同方式，还是它们之间的用例存在真正的差异？

我只能找到一个有点相关的问题：“我什么时候使用像 Paxos 这样的共识算法与使用像 Vector Clock 这样的算法？”

尽管链接的答案陈述了以下内容并引用了一篇短文，但我仍然不清楚这些差异。

您可能希望将版本向量用于无领导分布式存储。您可能会为此使用矢量时钟（尽管它更适合；本文还建议您将其用于一致的快照，用于在一般分布式系统中实现因果排序等）。

在云计算的上下文中，后端开发人员经常提到构建（或使用）“服务网格”，但我并不完全理解它是什么。你能说更多吗？