有人能给我一个关于如何在分布式数据库中使用Paxos算法的真实示例吗？我已经阅读了许多关于Paxos的论文来解释算法，但没有一篇真正用实际例子来解释。
一个简单的例子可能是银行应用程序，其中一个帐户正在通过多个会话进行修改（即柜员存款，借记操作等）。 Paxos是否用于决定首先进行哪种操作？此外，Paxos协议的多个实例意味着什么？怎么用这个？基本上，我试图通过一个具体的例子而不是抽象的术语来理解这一切。
答案 0 :(得分：6)
例如，我们有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
答案 1 :(得分：2)
Clustrix数据库是一个在事务管理器中使用Paxos的分布式数据库。数据库内部使用Paxos来协调消息并在分布式系统中维护事务原子性。
执行事务提交时执行以下步骤：
这对应用程序都是透明的，并在数据库内部实现。因此，对于您的银行应用程序，所有应用程序级别需要执行的是针对死锁冲突执行异常处理。实现大规模数据库的另一个关键是并发，这通常通过MVCC（多版本并发控制）来帮助。
答案 2 :(得分：1)
有人可以给我一个有关Paxos算法的真实示例吗 在分布式数据库中使用？
MySQL uses Paxos。这就是为什么高度可用的MySQL设置需要三台服务器的原因。相反，典型的Postgres设置是不运行Paxos的主从两节点配置。
我已经阅读了很多有关Paxos的论文，这些论文解释了该算法，但是没有一个实例能真正说明这个问题。
这里是transaction log replication的Paxos的相当详细的说明。这是implements it in Scala的源代码。 Paxos (aka multi-Paxos)在消息方面具有最佳效率，就像在三节点群集中一样，在稳定状态下，领导者接受它自己的下一个值，传输给其他两个节点，并且知道该值在返回时是固定的一种回应。然后，它可以将提交消息（学习消息）放在它发送的下一个值的前面。
一个简单的示例可以是银行应用程序，其中一个帐户是 通过多个会话进行修改（即在柜员处存款， 借记操作等。）。 Paxos是否用于决定执行哪个操作 首先发生？
是的，如果您使用MySQL数据库集群来保存银行帐户，则可以使用Paxos来确保副本与主服务器就将交易应用于客户银行帐户的顺序达成一致。如果所有节点都同意执行事务的顺序，则它们将拥有相同的余额。
不能重新排序银行帐户上的操作，而不会得出不同的余额，这可能违反不超过您的信用额度的业务规则。确保订单的简单方法是仅使用一个服务器进程，该服务器进程仅根据接收到的消息的顺序确定正式订单。然后，它可以跟踪每个银行帐户的余额并执行业务规则。但是，您不希望只有一台服务器，因为它可能会崩溃。您希望副本服务器也接收信用和借记命令并与主服务器达成协议。
拥有应该保持相同平衡的副本所面临的挑战是，消息可能会丢失并重新发送，并且消息可能会被可能会延迟发送某些消息的交换机缓冲。最终结果是，如果网络不稳定，则很难证明快速复制协议永远不会导致不同的服务器看到消息以不同的顺序到达。您最终将在同一集群中拥有不同余额的不同服务器。
您不必使用Paxos来解决银行帐户问题。您可以执行简单的主从复制。您有一个主机，一个或多个从机，并且主机在告诉任何客户端命令结果之前，一直等到它收到从机的确认。那里的挑战是丢失和重新排序消息。在发明Paxos之前，数据库供应商刚刚创建了昂贵的硬件，旨在具有很高的冗余性和可靠性来运行主从服务器。 Paxos的革命性之处在于它可以与商品网络一起使用，而无需专业硬件。
由于银行应用程序可以通过昂贵的定制硬件获利，因此许多现实世界中的银行系统仍可能以这种方式运行。在这种情况下，数据库供应商为专业硬件提供内置的可靠网络，数据库软件将在该网络上运行。那是非常昂贵的，不是小公司想要的。具有成本意识的公司可以在具有常规网络的任何公共云中的VM上建立MySQL群集，Paxos将使其可靠而不是使用专业硬件。
另外，Paxos协议的多个实例是什么意思？怎么样 什么时候使用？
我写了一个关于多Paxos是original Paxos protocol的博客。简而言之，在选择集群中事务的顺序时，您希望将事务作为值流传输。每个值都固定在协议的单独逻辑实例中。正如我在Paxos for cluster replication博客中所描述的那样，该算法在稳态下非常有效，只需在主节点和足够多的节点之间进行一次往返即可拥有多数节点，而该节点是三节点集群中的另一个节点。当发生崩溃或网络问题时，该算法始终是安全的，但需要更多消息。因此，要回答您的问题，典型的应用程序需要多轮Paxos来建立集群中客户端命令的顺序。
我应该注意，Raft是专门为对群集复制进行详细描述而发明的。原始Paxos论文要求您弄清楚进行集群复制的许多细节。因此，我们可以预期专门尝试实现集群复制的人员会使用Raft，因为它不会给实现者带来任何麻烦。
那么什么时候可以使用Paxos？它可用于更改基于不同协议写值的集群的集群成员资格，只有当您知道确切的集群成员资格时，该协议才是正确的。 Corfu是一个很好的例子，它通过让客户端同时写入服务器分片来消除通过单个主机进行写入的瓶颈。但是，只有当所有客户端都对当前集群成员资格和分片布局有准确的了解时，它才能准确地做到这一点。当节点崩溃或您需要扩展集群时，您可以提出新的集群成员资格和分片布局，并通过Paxos运行它以在整个集群中达成共识。
答案 3 :(得分：0)
# imports
from plotly.subplots import make_subplots
import plotly.figure_factory as ff
import plotly.graph_objs as go
import pandas as pd
import numpy as np
data = dict(Pclass=[1,1,2,2,3,3],
Survived = [0,1,0,1,0,1],
CategorySize = [80,136,97,87,372,119] )
df=pd.DataFrame(data)
s0=df.query('Survived==0')
s1=df.query('Survived==1')
#layout = go.Layout(title= 'Pclass-Survived', xaxis = dict(title = 'Pclass'), yaxis = dict(title = 'CategorySize'),barmode='group' )
fig = go.Figure()
data=data['Pclass']
fig.add_trace(go.Bar(x=s0['Pclass'], y = s0['CategorySize'],
name='dead'
)
)
fig.add_trace(go.Bar(x=s1['Pclass'], y = s1['CategorySize'],
name='alive'
)
)
df_tot = df.groupby('Pclass').sum()
annot1 = [dict(
x=xi,
y=yi,
text=str(yi),
xanchor='auto',
yanchor='bottom',
showarrow=False,
) for xi, yi in zip(df_tot.index, df_tot['CategorySize'])]
fig.update_layout(barmode='stack', annotations=annot1)
fig.show()
是一种共识算法，旨在使其易于理解。它的容错和性能等效于Raft。区别在于，它被分解为相对独立的子问题，并且干净地解决了实用系统所需的所有主要部分。Paxos的目的是通过分离逻辑比Raft更易于理解，但是还被正式证明是安全的，并提供一些附加功能。 Raft提供了一种在计算机系统集群中分布状态机的通用方法，可确保集群中的每个节点都同意相同的一系列状态转换
筏上的实际用途
Paxos是一个高度一致的etcd，它提供了一种可靠的方式来存储需要由分布式系统或计算机集群访问的数据。它可以优雅地处理网络分区期间的领导者选举，即使在领导者节点中也可以容忍机器故障。从简单的Web应用程序到distributed key-value store，各种复杂的应用程序都可以从etcd中读取数据或将数据写入etcd。
etcd用Go编写，它具有出色的跨平台支持，小型二进制文件和背后的强大社区。 etcd机器之间的通信通过Raft共识算法处理。