无领导者复制实际上是如何工作的?真的没有单个协调者/领导者节点来维护复制吗?

问题描述 投票:0回答:1

我一直在阅读 Martin Kleppmann 的“设计数据密集型应用程序”作为了解数据库复制及其与共识算法的关系的资源。

根据我对共识的理解,似乎有一个领导者/协调者节点在一堆副本节点之间驱动共识。 Raft 和 Paxos 似乎是这样工作的。

所以我的问题是:无领导复制系统如何工作?实际上是否没有单个领导者/协调者节点来协调一堆节点之间的协议/共识?

即使读或写请求被发送到一堆副本节点,难道不应该有一个隐式的协调者/领导者来处理请求吗?

我没有找到太多确凿的材料来解释无领导复制实际上如何在副本节点之间达成共识。

如果我的理解有误,或者遗漏了什么,请纠正我。

database-replication distributed-system consensus
1个回答
0
投票

我对主题的看法:

所以我的问题是:无领导复制系统如何工作?实际上是否没有单个领导者/协调者节点来协调一堆节点之间的协议/共识?

我看到了两种选择:

  • A) 请求到达任意节点并且该节点协调操作
  • B)请求必须落在负责数据的节点上,因此如果选择了错误的节点,请求将被重定向到正确的节点

Dynamo 是无领导系统的一个很好的例子,被定义为上面的 B。

另一个有趣的问题是无领导者和多领导者有什么区别?我对此的看法是基于哪些节点“拥有”数据。例如。我可以拥有一个包含两个 MariaDB 数据库的系统,允许在两个数据库上进行写入,并有一个双向复制过程,我将通过随机选择一条记录来解决冲突 - 这将是多领导者系统。

即使读或写请求被发送到一堆副本节点,难道不应该有一个隐式的协调者/领导者来处理请求吗?

通常,客户端本身就是协调者 - 他们向所有副本发送请求,读取结果,甚至可能进行读取修复。

© www.soinside.com 2019 - 2024. All rights reserved.