标签: distributed

我正在用C++编写分布式应用程序框架.其中一个要求是提供分布式共享内存.我不是从头开始写自己的(并且可能重新发明轮子),我想我会看看是否有任何预先存在的开源库 - 快速谷歌搜索没有产生任何有用的东西.

这里有没有人有他们可以推荐的优秀C++ DSM库的经验？

理想情况下,该库将支持MRMW(多个读取器/多个写入器),但如果需要,我可以使用MRSW(多个读取器,单个写入器).我在Linux上开发.

我是一个具有UNIX SCCS和Microsoft Visual SourceSafe经验的Git newbee.我只是在学习Git,它似乎有一个巨大而痛苦的学习曲线.我已经看到Git吹走了我没有提交的所有数据文件,这让我很担心.(实用程序如何在没有警告的情况下删除数据文件超出我的范围).

Linus Torvalds在他关于Git的视频中声称Git是分发的,吹嘘分发的好处,但除了拥有源代码副本(克隆)的人之外,并没有真正解释分发是如何工作的.

Git如何帮助分发？Git如何帮助恢复丢失的文件？Git发行如何运作？我可以找到分发文件的位置吗？有Git分发教程吗？

提前致谢!

我正在寻找有关如何最好地考虑设计高级应用程序协议以在最终用户设备和服务器之间同步元数据的指导.

我的目标:用户可以在任何设备或网络上与应用程序数据进行交互.此协议的目的是通过服务器将在一个端点上进行的更改传达给其他端点,并确保所有设备都保持应用程序数据的一致性.如果用户在一台设备或Web上进行更改,协议会将数据推送到中央存储库,其他设备可以从中央存储库中提取数据.

其他一些设计思路:

• 我将其称为"元数据同步",因为有效载荷将非常小,形式为对象ID和关于这些ID的小元数据.当客户端端点通过此协议检索新元数据时,它们将基于此元数据从外部源获取实际对象数据.获取"真实"对象数据超出了范围,我只是在谈论元数据同步.
• 使用HTTP进行传输,使用JSON进行有效负载容器.问题基本上是关于如何最好地设计JSON有效负载模式.
• 我希望在Web上以及桌面和移动设备上轻松实现和维护.最好的方法是简单的基于计时器或基于事件的HTTP请求/响应,而没有任何持久性通道.此外,你不应该有博士学位阅读它,我希望我的规格适合2页,而不是200页.
• 身份验证和安全性超出了此问题的范围:假设请求是安全的并经过身份验证.
• 目标是设备上数据的最终一致性,它并非完全是实时的.例如,用户可以在离线时在一台设备上进行更改.再次上线时,用户将执行"同步"操作以推送本地更改并检索远程更改.
• 话虽如此,协议应该支持这两种操作模式:
  • 在设备上从头开始,应该能够拉出整个元数据图片
  • "随时随地同步".当并排查看两个设备上的数据并进行更改时,应该很容易将这些更改推送为其他设备可以近实时接收的短消息(取决于它何时决定联系服务器进行同步).

作为一个具体的例子,你可以想到Dropbox(它不是我正在研究的,但它有助于理解模型):在一系列设备上,用户可以管理文件和文件夹 - 移动它们,创建新的,删除旧的等.在我的上下文中,"元数据"将是文件和文件夹结构,但不是实际的文件内容.元数据字段将类似于文件/文件夹名称和修改时间(所有设备应该看到修改的同一时间).

另一个例子是IMAP.我没有阅读协议,但我的目标(减去实际的消息体)是相同的.

感觉有两个宏大的方法如何做到这一点:

• 交易消息.系统中的每个更改都表示为delta,端点与这些增量进行通信.示例:DVCS变更集.
• REST:将对象图作为一个整体或部分进行通信,而不必过多担心单个原子的变化.

编辑:一些答案正确地说,有关该应用程序的信息不足以提供足够好的建议.该应用程序的确切性质可能会分散注意力,但一个非常基本的RSS阅读应用程序是一个足够好的近似.所以我们假设应用规范如下:

• 有两个类:提要和项目.
• 我可以添加,重命名和删除Feed.添加订阅订阅它并开始接收该订阅源的项目.我还可以在UI中重新排序Feed显示顺序.
• 当我读取项目时,它们被标记为已读.我无法将它们标记为未读或与它们做任何其他事情.
• 基于以上所述,对象模型是:
  • "feed"具有属性"url","displayName"和"displayOrder"(displayOrder是UI的供稿列表中的供稿索引;在本地重新排序供稿会更改所有供稿的displayOrder,以使索引保持唯一且顺序).
  • "item"具有属性"url"和"unread",以及多对一关系"feed"(每个项目属于一个Feed)."url"也表现为项目的GUID.
  • 实际项目内容在每台设备上本地下载,不属于同步.

基于这种设计,我可以在一台设备上设置我的应用程序:添加一堆供稿,重命名并重新排序它们,并读取它们上的一些项目,然后标记为未读取.当我切换设备时,其他设备可以同步配置并向我显示具有相同名称,顺序和相同项目读取/未读状态的相同馈送列表.

(结束编辑)

我想在答案中:

• 我遗漏了什么重要的东西？限制,目标？
• 有什么好的背景阅读？(我意识到这就是许多计算机科学课程在很长的篇幅和细节上谈论的内容......我希望通过查看一些速成课程或掘金来使其短路.)
• 这些协议的一些很好的例子,我可以建模,甚至开箱即用？(我上面提到了Dropbox和IMAP ......我应该阅读IMAP RFC.)

我试图建立一个分布式文件系统中文件可用性的数学模型.我在MathOverflow上发布了这个问题,但这可能也被归类为CS问题,所以我也在这里给它一个镜头.

系统的工作方式如下:节点在r*b遥控节点存储文件(使用擦除代码编码),其中r是复制因子,b是整数常量.如果远程节点中至少有b个可用并且返回其文件的一部分,则擦除编码文件具有可以恢复文件的属性.

最简单的方法是假设所有远程节点彼此独立并具有相同的可用性p.根据这些假设,文件的可用性遵循二项分布,即二项分布http://bit.ly/dyJwwE

不幸的是,这两个假设可能会引入一个不容错误的错误,如本文所示:http://deim.urv.cat/~lluis.pamies/uploads/Main/icpp09-paper.pdf .

克服所有节点具有相同可用性的假设的一种方法是计算可用/不可用节点的每种可能组合的概率,并取所有这些结果的总和(这是他们在上面的论文中建议的那种,比我刚才描述的更正式.您可以将此方法视为具有深度r*b的二叉树,并且每个离开是可用/不可用节点的一种可能组合.文件的可用性与您通过> = b可用节点到达的可能性相同.这种方法更正确但是具有Ordo http://bit.ly/cEZcAP的计算成本.此外,它不涉及节点独立性的假设.

你们有没有一个好的近似的想法,它引入的误差比二项式分布 - aproximation少,但计算成本比http://bit.ly/d52MM9 http://bit.ly/cEZcAP好？

您可以假设每个节点的可用性数据是由一组元组组成的(measurement-date, node measuring, node being measured, succes/failure-bit).使用此数据,您可以计算节点之间可用性与可用性差异的相关性.

是否存在用.NET实现的分布式共享内存系统的现有库/框架/产品,或者可以从.NET客户端轻松访问？

谷歌搜索提供了一些学术论文的链接,但我找不到任何真正的实现.

注意:我最感兴趣的是在局域网上运行的东西,而不是"云".

我正在研究分布式Web应用程序,我们决定将Web模块与业务服务分开,以使其更具可扩展性.

情况就是这样:我们有一个服务器实例可以保存Web应用程序(控制器,JSP等)以及许多带有业务服务的服务器实例.如果Web应用程序需要任何数据,它会通过Hessian询问任何现有的业务服务器,然后得到响应并显示数据.

目前,我们根据登录用户从DB检索数据,但无法更改,因此每个服务器都应该知道要求哪个用户执行此任务.

我的问题是:您是否知道在多个独立应用程序中保持用户会话的解决方案？

例如,其中一个解决方案可以在每次请求时发送用户名,但这对我们来说不是一个好主意.

非常感谢

作为我工作的一部分,我们每年获得大约25TB的日志文件,目前它是通过基于NFS的文件系统保存的.一些存档如zipped/tar.gz,而其他存档为纯文本格式.

我正在寻找使用基于NFS的系统的替代方案.我查看了MongoDB,CouchDB.它们是面向文档的数据库这一事实似乎使它成为合适的选择.但是,日志文件内容需要更改为JSON才能存储到数据库中.我不愿意做的事.我需要按原样保留日志文件内容.

至于用法,我们打算放置一个小的REST API,允许人们获取文件列表,最新文件和获取文件的能力.

提出的解决方案/想法需要是应用程序级别的某种形式的分布式数据库或文件系统,其中可以存储日志文件并且可以通过添加更多机器来有效地水平扩展.

ANKUR

我正在寻找一些用于安排大量任务的通用库.该库必须能够跨群集中的节点分割任务,执行负载平衡和容错 - 因此,如果某个节点出现故障,则必须将节点的任务分布在其余节点上.

我查看了Hadoop - 但看起来它适用于map-reduce任务.在我的情况下,任务只是通知的发件人,对象状态的检查器等.

Quartz似乎很棒 - 但是当它归结为向节点分派事件时,它还不清楚它有多好.

还有其他选择吗？

我想设计一个作业调度程序集群,它包含几个要执行cron作业调度的主机.例如,需要的作业run every 5 minutes被提交到集群,集群应该指出下次运行要触发的主机,确保:

1. 容灾:如果不是所有主机都关闭,则应该成功触发作业.
2. 有效性:只有一个主机可以解雇下一个工作.

由于容灾,作业无法绑定到特定主机.一种方法是所有主机轮询数据库表(当然有锁),这保证只有一个主机获得下一个作业运行.由于它经常锁表,有没有更好的设计？

我已阅读分布式tensorflow文档和这个答案.

根据此,在数据并行方法:

• 该算法在各个核之间分配数据.
• 每个核心独立地尝试估计相同的参数
• 然后,核心彼此交换它们的估计值,以得出对该步骤的正确估计.

在模型并行方法中:

• 该算法将相同的数据发送到所有核心.
• 每个核心负责估计不同的参数
• 然后,核心彼此交换它们的估计值,以得出所有参数的正确估计值.

这些方法如何做In-graph replication和Between-graph replication有关？

这篇文章说:

例如,可以在不同的GPU上并行地训练网络中的不同层.此培训过程通常称为"模型并行性"(或TensorFlow文档中的"图中复制").

和:

在"数据并行"(或TensorFlow文档中的"图形间复制")中,您为每个设备使用相同的模型,但使用不同的训练样本在每个设备中训练模型.

那是准确的吗？

来自tensorflow文档页面中链接的Tensorflow DevSummit视频: 看起来数据被拆分并分发给每个工作人员.那么不In-graph replication遵循数据并行方法吗？