标签: distributed-system

我一直致力于移动技术，现在我正在涉足后端系统，更具体地说是系统设计。我不断遇到关于 api 网关和负载均衡器角色的相互矛盾的陈述。谷歌搜索只返回了同样的六个结果，这些结果主要集中在一些著名服务提供的负载均衡器或 API 网关服务的实现上。我将在这里列出我面临的所有困惑，希望有人能够澄清所有这些。

有时，我发现 API 网关是与客户端设备通信的单点。另一方面，有些地方提到“请求发送到负载均衡器，负载均衡器将其均匀地分布在服务器上”。那么什么是正确的呢？API网关接收请求还是负载均衡器？

其他地方，当我用谷歌搜索这个主题时，说两者完全不同。我知道 API Gateway 可以做很多事情，比如 SSL 终止、日志记录、限制、验证等，但它也可以做负载平衡。那么API网关本身就是一个负载均衡器，还具备其他职责吗？

关于这个主题，我想了解负载均衡器是否在同一集群的服务器之间或不同的数据中心或集群之间分配负载？那么 API 网关呢？

api gateway 有什么特殊之处以至于它成为微服务架构的默认选择？API 网关托管在哪里？DNS 将域名解析为负载均衡器或 API 网关？

可能很清楚，我完全困惑了。如果问题正确的话，在哪些系统中负载均衡器比 API Gateway 受益更多。

在用Java设计分布式应用程序时,似乎有一些技术可以解决同一类问题.我简要介绍了Java远程方法调用和Java消息服务,但很难真正看到它们的区别.Java RMI似乎比JMS更紧密耦合,因为JMS使用异步通信,但除此之外我没有看到任何重大差异.

• 他们之间有什么区别？
• 其中一个比另一个更新吗？
• 哪一个在企业中更常见/更受欢迎？
• 它们相互之间有什么优势？
• 什么时候优先于另一个？
• 他们实施的难度有很大差异吗？

我还认为Web Services和CORBA解决了同样的问题.

当我们讨论分布式系统的性能时,我们使用术语tp50,tp90,tp99.99 TPS.有人可以解释一下我们的意思吗？

我有很多备用的intel linux服务器(数百个),并希望在Web托管和文件共享环境中将它们用于分布式文件系统.这不适用于HPC应用程序,因此高性能并不重要.主要要求是高可用性,如果一台服务器脱机,存储在其硬盘上的数据仍可从其他节点获得.它必须通过TCP/IP运行并提供标准POSIX文件权限.

我看了下面的内容:

• Lustre(http://wiki.lustre.org/index.php?title=Main_Page):非常接近,但它不为节点上的数据提供冗余.您必须使用RAID或DRBD创建数据HA.在Sun和Open Source的支持下,它应该存在一段时间

• gfarm(http://datafarm.apgrid.org/):看起来它提供了冗余,但代价是复杂性和可维护性.不像Lustre那样得到支持.

有没有人对这些或任何其他可能有效的系统有任何经验？

我正在接受承包,今天我已经接受了承包商职位的第一轮面试.我已经通过了它,但有人告诉我 - 主要是一个UI开发人员 - 我只介绍了他们后端需要的基础知识,我应该在第二轮之前阅读分布式系统.

到目前为止,在我的职业生涯中,我一直在从事后期操作,从不需要实时.由于我还剩下几天,我需要涵盖哪些主题？首先能够回答他的问题并且通常被视为分布式系统中的适当问题？

问题是如何在UI上实时显示数据？后端需要做什么？我已经提到了实时数据馈送的生产者/消费者模式.他很喜欢,但他说他在第二次面试时需要更多.

任何帮助将非常感激,

最近我一直在阅读很多有关分布式消息传递和相关模式的内容.我使用了一些工具支持的例子,比如例如NServiceBus.

许多这些模式都在互联网上描述.我最近读到的其中一些是:

• Message Broker:http://msdn.microsoft.com/en-us/library/ff648849.aspx
• 消息总线:http://msdn.microsoft.com/en-us/library/ms978583.aspx
• SOA中的消息传递模式:http://msdn.microsoft.com/en-us/library/aa480027.aspx
• Udi Dahan关于差异的帖子:http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences/

如果使用像NService bus这样的工具来做很多工作而不考虑基础设施问题,那么当我尝试实现基本的Message Bus和命令处理程序时,一些问题已经得到了解决.事实上,当谈到这些模式时,我看不出它们之间存在很多差异.

我不会粘贴代码,因为它很长,但我发现了两篇博文,很好地描述了我想谈的实现的想法.

• 消息总线:http://brentedwards.net/2010/04/13/roll-your-own-simple-message-bus-event-aggregator/

这个想法很简单,消息总线跟踪订阅者并在他们感兴趣的情况下将消息发送给不同的订阅者.

• 命令处理程序:http://weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx

它与消息总线非常相似.命令总线为给定的命令类型调用命令处理程序.

所以在这两种情况下都有相似之处.

使用一种模式比另一种模式有什么真正的差异和好处(我不是在谈论支持工具).我错过了什么？

第二个问题是.没有支持工具,消息总线是否有价值？我不认为自己会为自己的所有权利提供支持.

对于一个冗长而令人困惑的问题我很抱歉,但请不要犹豫,询问更多细节.

我试图理解以下术语之间的区别：

• 迹线ID
• 相关ID

这两个术语似乎都用作搜索多个服务产生的相关日志的标识符，尤其是在面向微服务的架构中。

这两者之间有细微的差别吗？

我们应该在我们的软件中使用这些术语中的哪一个？我们如何决定？

关于RDBMS在CAP定理中是CA的两点我不明白:

1)它说RDBMS 不是 分区容忍但是RDBMS如何比MongoDB或Cassandra等其他技术更少分区容忍？是否存在RDBMS设置,我们放弃CA以使其成为AP或CP？

2)CAP如何可用？是通过主从设置吗？在主机死机时,从机接管写入？

我是DB架构和CAP定理的新手所以请耐心等待.

我见过多个有关以下问题的问题：

RuntimeError: NCCL error in: /opt/conda/conda-bld/pytorch_1614378083779/work/torch/lib/c10d/ProcessGroupNCCL.cpp:825, unhandled cuda error, NCCL version 2.7.8
ncclUnhandledCudaError: Call to CUDA function failed.

但似乎没有人能帮我解决这个问题：

• https://github.com/pytorch/pytorch/issues/54550
• https://github.com/pytorch/pytorch/issues/47885
• https://github.com/pytorch/pytorch/issues/50921
• https://github.com/pytorch/pytorch/issues/54823

我尝试torch.cuda.set_device(device)在每个脚本的开头手动执行。这似乎对我不起作用。我尝试过不同的 GPU。我尝试过降级pytorch版本和cuda版本。1.6.0、1.7.1、1.8.0 和 cuda 10.2、11.0、11.1 的不同组合。我不确定还能做什么。人们做了什么来解决这个问题？

也许非常相关？

• Pytorch“NCCL 错误”：未处理的系统错误，NCCL 版本 2.4.8”

更完整的错误消息：

('jobid', 4852)
('slurm_jobid', -1)
('slurm_array_task_id', -1)
('condor_jobid', 4852)
('current_time', 'Mar25_16-27-35')
('tb_dir', PosixPath('/home/miranda9/data/logs/logs_Mar25_16-27-35_jobid_4852/tb'))
('gpu_name', 'GeForce GTX TITAN X')
('PID', '30688')
torch.cuda.device_count()=2

opts.world_size=2

ABOUT TO SPAWN WORKERS
done setting sharing strategy...next mp.spawn
INFO:root:Added key: store_based_barrier_key:1 to store for rank: 1
INFO:root:Added key: store_based_barrier_key:1 to store …

所以我一直试图了解消息队列和消息代理之间的区别，以及为什么应该使用一个而不是另一个。

所以据我了解。MESSAGE QUEUE 有助于进程间通信，但它基本上仅限于仅允许 2 个应用程序之间的通信？我问这个是因为例如 MSMQ（如果我的理解是正确的）只将消息存储在队列中，直到它被第一个消费者处理，之后它会自动将它从队列中删除。这样对吗 ？

现在 MESSAGE BROKERS 是 MESSAGE QUEUE 的某种扩展？因为它们提供了一种发布者 - 订阅者（S）关系的机制，就像观察者一样？

我的理解正确吗？如果是这样，两者之间还有其他区别吗？另外，您为什么要在 MESSAGE BROKER 上使用 MESSAGE QUEUE，因为您很可能会使用分布式系统，该系统肯定会由多个服务组成。

谢谢。