有人可以给我一个真实的例子,说明 Paxos 算法是如何在分布式数据库中使用的吗?我已经阅读了很多关于 Paxos 的论文来解释该算法,但没有一篇真正用一个实际的例子来解释。
一个简单的例子可以是一个银行应用程序,其中一个帐户正在通过多个会话进行修改(即在柜员处存款、借记操作等)。Paxos 是用来决定哪个操作先发生的吗?另外,Paxos 协议的多个实例是什么意思?这个什么时候用?基本上,我试图通过一个具体的例子而不是抽象的术语来理解这一切。
有人可以给我一个真实的例子,说明 Paxos 算法是如何在分布式数据库中使用的吗?我已经阅读了很多关于 Paxos 的论文来解释该算法,但没有一篇真正用一个实际的例子来解释。
一个简单的例子可以是一个银行应用程序,其中一个帐户正在通过多个会话进行修改(即在柜员处存款、借记操作等)。Paxos 是用来决定哪个操作先发生的吗?另外,Paxos 协议的多个实例是什么意思?这个什么时候用?基本上,我试图通过一个具体的例子而不是抽象的术语来理解这一切。
例如,我们有一个 MapReduce 系统,其中 master 由 3 个主机组成。一个是主人,另一个是奴隶。选择master的过程使用Paxos算法。
Google Big Table 的 Chubby 也使用 Paxos:The Chubby Lock Service for Loosely-Coupled Distributed Systems , Bigtable: A Distributed Storage System for Structured Data
Clustrix数据库是在事务管理器中使用 Paxos 的分布式数据库。数据库内部使用 Paxos 来协调消息并维护分布式系统中的事务原子性。
执行事务提交时会采取以下步骤:
这对应用程序是透明的,并在数据库内部实现。因此,对于您的银行应用程序,应用程序级别需要做的就是针对死锁冲突执行异常处理。大规模实现数据库的另一个关键是并发性,这通常通过 MVCC(多版本并发控制)来帮助。
有人可以给我一个真实的例子,说明 Paxos 算法是如何在分布式数据库中使用的吗?
MySQL使用 Paxos。这就是高可用性 MySQL 设置需要三台服务器的原因。相比之下,典型的 Postgres 设置是不运行 Paxos 的主从两节点配置。
我已经阅读了很多关于 Paxos 的论文来解释该算法,但没有一篇真正用一个实际的例子来解释。
这是对事务日志复制的 Paxos 的相当详细的解释。这是在 Scala中实现它的源代码。Paxos(又名多 Paxos)在消息方面效率最高,因为在三节点集群中,在稳定状态下,领导者接受它自己的下一个值,传输到其他两个节点,并且知道该值是固定的得到一个回应。然后它可以将提交消息(学习消息)放在它发送的下一个值的前面。
一个简单的例子可以是一个银行应用程序,其中一个帐户正在通过多个会话进行修改(即在柜员处存款、借记操作等)。Paxos 是用来决定哪个操作先发生的吗?
是的,如果您使用 MySQL 数据库集群来保存银行账户,那么 Paxos 将用于确保副本与主服务器就交易应用于客户银行账户的顺序达成一致。如果所有节点都同意交易的顺序,他们将持有相同的余额。
如果不提出可能违反不超过您的信用的业务规则的不同余额,则无法对银行帐户的操作进行重新排序。确保订单的简单方法是仅使用一个服务器进程,该进程仅根据接收到的消息的顺序来决定正式订单。然后它可以跟踪每个银行账户的余额并执行业务规则。但是,您不希望只有一个服务器,因为它可能会崩溃。您希望副本服务器也接收贷记和借记命令并与主服务器达成一致。
拥有应该保持相同余额的副本的挑战是消息可能会丢失和重新发送,并且消息被可能延迟传递一些消息的交换机缓冲。最终结果是,如果网络不稳定,很难证明快速复制协议永远不会导致不同的服务器看到消息以不同的顺序到达。您最终将在同一集群中使用不同的服务器持有不同的余额。
您不必使用 Paxos 来解决银行账户问题。你可以做简单的主从复制。你有一个master,一个或多个slave,master会等到它得到slave的确认,然后再告诉任何客户端命令的结果。那里的挑战是丢失和重新排序的消息。在 Paxos 发明之前,数据库供应商只是创建了昂贵的硬件,旨在具有非常高的冗余和可靠性以运行主从。Paxos 的革命性在于它可以与商品网络一起工作,而无需专业硬件。
由于银行应用程序可以通过昂贵的定制硬件获利,因此许多现实世界的银行系统可能仍在以这种方式运行。在这种情况下,数据库供应商为专业硬件提供内置的可靠网络,数据库软件在该网络上运行。这是非常昂贵的,不是小公司想要的。注重成本的公司可以在任何具有正常网络的公共云中的 VM 上建立 MySQL 集群,Paxos 将使其可靠,而不是使用专业硬件。
另外,Paxos 协议的多个实例是什么意思?这个什么时候用?
我写了一篇关于多 Paxos 是原始 Paxos 协议的博客。简而言之,在选择集群中事务的顺序的情况下,您希望将事务作为值流进行流式传输。每个值都固定在协议的单独逻辑实例中。正如我在关于用于集群复制的 Paxos 的博客中所描述的那样,该算法在稳定状态下非常有效,只需要在主节点和足够多的节点之间进行一次往返即可获得多数,即三节点集群中的另一个节点。当出现崩溃或网络问题时,算法始终是安全的,但需要更多消息。因此,要回答您的问题,典型应用程序需要多轮 Paxos 来建立集群中客户端命令的顺序。
我应该注意到,Raft 是专门发明的,用于详细描述如何执行集群复制。最初的 Paxos 论文要求您弄清楚进行集群复制的许多细节。所以我们可以期待那些专门尝试实现集群复制的人会使用 Raft,因为它没有给实现者留下任何需要自己解决的问题。
那么什么时候可以使用 Paxos?它可用于更改基于不同协议写入值的集群的集群成员资格,只有在您知道确切的集群成员资格时才能正确。Corfu就是一个很好的例子,它通过让客户端同时写入服务器的分片来消除通过单个主机写入的瓶颈。然而,只有当所有客户端都准确了解当前集群成员和分片布局时,它才能准确地做到这一点。当节点崩溃或您需要扩展集群时,您可以提出新的集群成员资格和分片布局,并通过 Paxos 运行它以在整个集群中达成共识。
Raft
是一种旨在易于理解的共识算法。它相当于Paxos
容错和性能。不同之处在于它被分解为相对独立的子问题,并且清晰地解决了实际系统所需的所有主要部分。Raft
旨在比Paxos
通过逻辑分离更易于理解,但它也被正式证明是安全的,并提供了一些附加功能。Raft 提供了一种在计算系统集群中分布状态机的通用方法,确保集群中的每个节点都同意相同的一系列状态转换
筏上的实际用途
etcd
是一种强一致性,distributed key-value store
它提供了一种可靠的方式来存储分布式系统或机器集群需要访问的数据。它在网络分区期间优雅地处理领导者选举,并且可以容忍机器故障,即使在领导者节点中也是如此。任何复杂的应用程序,从简单的 Web 应用程序到Kubernetes
,都可以从 etcd 读取数据并将数据写入 etcd。
etcd 是用 Go 编写的,它具有出色的跨平台支持、小型二进制文件和强大的社区。etcd 机器之间的通信是通过 Raft 共识算法处理的。