标签: distributed-system

我试图了解分布式系统中队列的用例是什么。
以及它如何扩展以及如何确保它不是系统中的单点故障？

任何直接回答或对文档的引用都值得赞赏。

1. 用例：
   我知道队列是一个消息系统。并且它解耦了彼此通信的系统。但是，这是使用队列的唯一目的吗？

2. 可扩展性：
   队列如何针对大量数据进行扩展？既读又写。

3. 可靠性：队列如何不成为系统中的单点故障？队列是否进行复制（类似于数据存储）？

我的问题没有指定到任何特定的队列服务器，如 Kafka 或 JMS。就一般而言。

我在木筏上遇到了问题。

在论文《寻找一种可理解的共识算法（扩展版）》中写道：

要开始选举，追随者会增加其当前任期并过渡到候选状态。（第 5.2 节）

它还说：

AppendEntries RPC 和 RequestVot RPC 中的接收者应为“Reply false if args.term < currentTerm”

所以，让我们想象一下这个场景，raft系统中有5台机器，现在机器0是leader，机器1到4是follower，现在是term 1。突然，机器1断开网络，然后机器1超时，并且它开始选举领导者，它发送RequestVot RPC，肯定会失败（网络断开）。然后它将开始新的领导者选举......等等。机器1的项是增加很多倍。也许增加到10。当机器1'Term增加到10时，它连接了网络。领导者（机器0）向机器1发送心跳，机器1将拒绝该心跳（机器0的期限小于机器1），现在机器1将无法重新加入系统。

我想知道我对消息总线和消息队列工作原理的理解是否正确。

首先，我需要明确命名，服务总线与消息总线可以互换使用吗？这是一种发布者-订阅者类型的系统，其中消息被添加到任意数量的发布者的消息集合中，并且任意数量的订阅者都可以从中读取消息，到目前为止我是对的吗？

P1 ---                                         /``````S1
       \________ Service Bus Middleware ------+------ S2
       /           MESSAGE-COLLECTION          \______S3
P2 ---

我不明白的是

1. 订阅者如何知道它感兴趣的消息，我的意思是它显然订阅了它，但是它如何知道它应该订阅哪条消息？，它在哪里看到消息列表，它如何使用它？通过 API 或如何？

2. 订阅者如何接收消息？

3. 何时从 MESSAGE-COLLECTION 中删除消息？我可以想象的是，为每条消息保留一些计数器，该计数器代表订阅者的总数，一旦一个订阅者成功处理该消息，该计数器就会递减。

消息队列也称为消息代理，是一种推拉类型的系统。有任意数量的生产者和任意数量的消费者。每个生产者为每个消费者创建一个队列，并向其提供消息。

             --- Message Queue 1 ---- C1
           /  
P1 ------ +
           \ 
             --- Message Queue 2 ---- C2


P2 ------ + --- Message Queue 1 ---- C1

在这种情况下，一旦消费者成功处理该消息，该消息就会被删除。我对消息队列工作原理的理解是否正确？

我不确定到底是什么的另一个概念是event hub。

目前正在阅读有关 RPC 和 RMI 的内容，我对它们之间的区别有点困惑。

在实现 RMI 和 gRPC 等时，语法基本相同。

它们都有确定方法参数和响应的接口。

它们都可以发送参数中的对象（Java RMI 本地执行此操作，C# gRPC 使用 proto）。

它们都通过某个对象上的方法调用（基于接口）来执行对服务器的请求。

那么区别是什么呢？客户端和服务器之间的数据传输过程是如何发生的？

从表面上看，RMI只是RPC的Java实现，而gRPC是C#实现。

我刚刚完成了草稿纸并开始实施。然而，我意识到我对一个关键细节有点困惑。raft 节点 \xe2\x80\x9c\xe2\x80\x9d 如何了解其对等节点？我在论文中没有看到\xe2\x80\x99 提到这一点，所以我认为它是特定于实现的，但在我看来，它导致了许多问题：

\n
• raft集群的大小是静态的吗？由于每个节点都必须了解其他所有对等点（以便发送 RPC），因此新节点如何加入现有集群？现有节点如何了解这个新节点？
\n
• 初始化时是否必须将每个节点\xe2\x80\x99s 网络位置硬编码到每个其他节点中？节点如何知道将 RPC 发送到哪里？
\n

非常感谢对此的一些帮助。我真的很想完全理解 raft，并且很高兴能够实现它，但我对系统架构的这一部分有点迷失。对我来说，节点应该使用硬编码的网络位置进行静态配置似乎并不正确，因为在现实世界中，我绝对可以想象需要将新节点添加到现有集群中。谢谢！

例如，如果我们有时间表 S1 ：

 r1[C] r2[A] r1[C] w3[B] w2[B] w1[C] commit1 r2[A] commit2 w3[B] commit3

我们知道这个调度不是冲突可串行化的，因此它不能来自两阶段锁定，但它是视图可串行化的。然而，如果我们想将严格的 2PL 应用于上述时间表，答案是：

1. x1[C] r1[C] s2[A] r2[A] r1[C] x3[B] w3[B] T2-waits-for-Xlock-on-B w1[C] commit1 u1[C] w3[B] commit3 u3[B] x2[B] w2[B] r2[A] commit2 u2[A] u2[B]

其中 u1[C] 表示 T1 释放对象 C 上的锁。在这种情况下，B 上的最后一次写入将由 T2 完成，这与原始调度 S1 不同。

或者严格 2PL 的正确应用如下：

2. x1[C] r1[C] s2[A] r2[A] r1[C] x3[B] w3[B] T2-waits-for-Xlock-on-B w1[C] commit1 u1[C] T3-waits-for-T2-to-take-lock-on-B-in-order-to-execute-w2[B]-first

在这种情况下，每个事务的读写顺序被保留，但会发生死锁。

总结我的问题：在附表 S1 中应用 2 相锁定（严格）的正确方法是什么？

每次我们应用两相锁定时，是否必须保持命令顺序与原始计划相同？

为什么 HAL 被弃用且不广泛使用？

HAL 背后的主要思想是在 http 端点之上添加一个抽象级别。使用关系概念向端点添加别名，而不是使用硬编码地址。这可以进行很多简化。例如，当两个团队处理两个模块并且第二个团队修改第一个团队使用的端点时，如果 HAL 的解析和地址检索是自动的（这很容易设置），则第一个团队将不必执行任何操作。

但我去维基并阅读：

最新版本的 HAL Internet-Draft 已于 2016 年 11 月 12 日到期

所以，我不明白为什么 HAL 没有得到广泛的认可，以及在现代分布式系统中它的替代品是什么。

当然，我知道消息传递系统，但它们依赖于平台。因此，我能想到的唯一其他选择是使用裸 http 地址来实现后端系统之间的平台无关通信，因为所有（几乎所有）技术都支持 http。

请不要将我的问题视为含糊不清，如果我上面写的内容不清楚，请在评论中提出问题。我的问题很明确：

1 HAL 是 Web 应用程序开发向前迈出的重要一步

2没有其他选择

3它已被弃用并且没有得到广泛认可

1、2、3产生了矛盾，所以这三者中的任何一个应该是错误的，我不知道哪一个是错误的。