问题标签 [consensus]

我有file1作为第一次操作的结果，它具有以下结构

并且file2由于不同的操作而具有相同的结构类型。

文件 2 样本

我想在 file1 (0.8) 中选择字段 3 值高于阈值的字段 1 和 2，然后对于字段 1 和 2 的这些选定值，选择字段 3 值高于另一个阈值的值文件 2 (abs(x)=0.4)。

请注意，尽管文件 1 和 2 具有相同的结构字段，但 1 和 2 的值并不相同（行数不同等）

你能做到这一点awk吗？

所需输出 101 34

我有一组 fasta 格式的对齐序列。我想从对齐中获得共识。在大多数站点的情况下，基地之一显示出最大的出现率。在两个或多个碱基出现相同次数的位点的情况下，应取哪个碱基。下面给出一个例子：

根据惯例，这将是共识

但是当与其他序列对齐时，共有序列的这个输出会抛出错误。那么在这种情况下应该怎么做以及如何为这些网站达成共识呢？

在Paxos made simple Lamport 中描述了算法的阶段 2 (a) 如下：

如果提议者从大多数接受者那里收到对其准备请求（编号为 n）的响应，那么它会向这些接受者中的每一个发送一个接受请求，以获取编号为 n 且值为 v 的提议，其中 v 是最高-在响应中编号的提案，或者如果响应报告没有提案，则为任何值。

• 这是否意味着提议者可以在收集到大多数接受者的响应后立即发送接受请求，而不管他们的提议编号如何？（我发现引用的强调部分暗示了这一点，因为所有相同编号的提案都应该具有相同的价值，对吧？）
• 或者提议者是否需要来自大多数接受者的具有相同提议编号的响应？（意味着编号为m（小于n）的响应不计入编号为n的响应的多数）

除了 MongoDB 在选举主节点时考虑其他因素（例如优先级）之外，raft 共识算法与 MongoDB 的主节点选举过程有何不同？

如果我有 3 个 DNA 序列并且我想通过一些函数来评估它们：

如何在python中计算这三个DNA序列的共识分数和加权对分数（WSP分数）？

共识得分是序列和共识序列之间的成对得分之和，共识（A）=sum{l}^{i=1}d（i）l是序列的长度，d是两个碱基之间的距离，例如：d(A,B)=2 代表 A!=B，d(A,-)=d(-,A)=1 代表 A!='-'，否则为 0。对于上述示例，A 和 B 可能是“A 或 C 或 G 或 T”

共识（A）=8

WSP (A) = \ sum_ {i=1}^{k-1} \sum_{j=i+l}^k \sum_{h=1}^lw _ij * s( A[ i, h ], [ j,h ] l : 序列长度, k 序列数, w _ij序列 i 和 j 的权重

s(A,B)=2 for A!=B, s(A,-)=d(-,A)=-1 for A!='-',3 else.all 权重因子为 1。

因此，三个序列的 WSP 得分为27

在paxos算法中，wiki中有一段描述：

阶段 2a：接受请求

如果 Proposer 从 Quorum of Acceptor 收到足够多的 Promise，它需要为其提案设置一个值。如果任何 Acceptor 之前接受过任何提案，那么他们会将其值发送给 Proposer，Proposer 现在必须将其提案的值设置为与 Acceptor 报告的最高提案编号相关联的值。如果到目前为止没有任何 Acceptor 接受提案，那么 Proposer 可以为其提案选择任何值。 [17] Proposer 向Acceptor 的Quorum 发送一个Accept Request 消息，并为其提议选择值。

假设提议者向五个接受者发送 Propose(4) 并接收回 Ack(abc, 2)、Ack(abc, 2) 和 Ack(xyz, 3)，它必须发送 Accept(xyz, 4)。

我的问题是：

1. 如果提议者最后必须发送 Accept(xyz,4)，那么当提议者使用自己的值发送接受请求时，例如。接受（qwe，n）？

2. 发送 Ack(xyz,3) 的接受者在看到新接受时会做什么，为什么？

谢谢

我已经阅读了许多文章并感到困惑。

意见 1：2PC 非常高效，交换的消息数量最少，延迟低。资料来源： http ://highscalability.com/paper-consensus-protocols-two-phase-commit

意见 2：分布式事务很难扩展到高水平，而且它们会降低吞吐量。作为 2PC 保证 ACID 由于其复杂的协调算法，它带来了很大的负担。资料来源：http: //ivoroshilin.com/2014/03/18/distributed-transactions-and-scalability-issues-in-large-scale-distributed-systems/

意见 3：“一些作者声称两阶段提交太昂贵而无法支持，因为它带来了性能或可用性问题。我们认为最好让应用程序程序员在出现瓶颈时处理由于过度使用事务而导致的性能问题，而不是总是围绕缺乏事务进行编码。在 Paxos 上运行两阶段提交可以缓解可用性问题。” 资料来源：http ://courses.cs.washington.edu/courses/csep552/13sp/lectures/6/spanner.pdf

意见 4：2PC 协调器也代表单点故障，这对于关键系统来说是不可接受的——我相信它是一个协调器。资料来源： http: //www.addsimplicity.com/adding_simplicity_an_engi/2006/12/2pc_or_not_2pc_.html

前 3 种观点相互矛盾。我认为第4个是正确的。请澄清什么是错误的，什么是正确的。给出事实为什么会这样也很好。

我对实现 RAFT 有以下疑问：

考虑以下场景\实现：

1. RAFT 领导者收到一个命令条目，它将条目附加到内存数组中，然后将条目发送给跟随者（带有心跳）
2. 追随者接收条目并将其附加到他们的内存数组中，然后发送响应它已收到条目
3. 然后领导者通过将条目写入持久存储（文件）来提交条目领导者在心跳中发送最新的提交索引
4. 追随者然后通过将条目存储到他们的持久存储（文件）来根据领导者的提交索引提交条目

RAFT 的实现之一（链接：https ://github.com/peterbourgon/raft/ ）似乎以这种方式实现它。我想确认这是否正常。

如果条目由领导者和追随者“在内存中”维护，直到它被提交，是否可以？在什么情况下这种情况可能会失败？

下面的问题是严肃的，而不是轻浮的。我缺乏分布式系统方面的经验，但我确实了解 Basic Paxos 的工作原理以及领导者选择为何有用。不幸的是，我的理解还不够深入，无法理解以下问题。

在论文Consensus on Transaction Commit的第 8 页（链接 PDF 的第 11 页）中，我们有以下声明。

选择一个唯一的领导者就相当于解决了共识问题。

如果这句话是真的，而且 Paxos 的目的是达成共识，为什么 Paxos 本身一般不用于领导选举？

此外，同一篇论文也支持描述了稳定领导者选举论文的领导者选举算法。

如果这两个问题是等价的，并且同一篇论文支持不同的领导者选举算法，为什么不使用其他算法来解决一般共识问题而不是 Paxos？

As the paper says:

Election Safety: at most one leader can be elected in a given term. §5.2

However, there may be more than one leader in the system. Raft only can promise that there is only one leader in a given term. So If I have more than one client, wouldn't I get different data? How does this allow Raft to be a consensus algorithm?

Is there something I don't understand here, that someone could explain?