Hadoop namenode高可用性分析：QJM核心源代码解读

正文

请到「今天看啥」查看全文

Multi Paxos 是 paxos 改进版，因为 Basic paxos 每一轮 paxos 都生成一个新的 proposal，这一般是由多点写，就像 zk Leader 选举，每个人都可以发起选举。但我们大多数分布式系统都有一个 leader，并且都是有 leader 发起 proposal，那后面就可以用第一次 proposal number，就直接执行 accept 阶段，从 qjm 这个实践里看，有点类似 RAFT 了，都有 leader 的角色。重用当前的提案编号 epoch

恢复数据过程：

1 隔离

2 选择恢复源

3 恢复

1 隔离

开始恢复前需要对前任隔离起来，防止他突然间复活，导致脑裂。隔离的措施是 newEpoch，重新生成一个新的 epoch，算法是通过计算所有 jn 节点中最大的一个，加 1，然后让命令 journal node 集群更新 epoch。更新后，如果前任复活，也不能向 journal node 集群写数据了，因为他的 epoch 比 journal 集群小，都会被拒绝。

生成新的 Epoch 代码如下:

拒绝的代码如下：

2 选择一个恢复源

隔离成功后，需要选择一个副本来恢复，每个 journal 的最新的 segment 文件不一致，因为 namenode crash 的时间不同而不同。所以需要从 journal 集群中最新的副本的信息。

3 恢复

隔离成功后，就开始恢复。在分布式系统，为了使各个节点的数据达成一致，经典的算法还是 Paxos，根据Paxos，分为 2 阶段分别说明如下：QJM 的两阶段对应的是 PrepareRecover 和 AccepteRecover，注意这里说是 Paxos 上文说是 Multi Paxos，区别就是 epoch 重用的。核心算法还是 Paxos。

3.1 PrepareRecovery

向所有 journal node 发送提议，并选中一个恢复的 segment，返回 segment 如下信息：

1. 是否有 segment

2. 有 segment，则附加 segment 的状态

3. committedTxnId 该 journal node 已经提交的事务 ID，QJM 每次日志同步后，会更新每个 AsyncLogger 的 committedTxnId，journal node 也每次请求都检查传过来的 committedTxnId，如果大于，则更新到本地。
   

4. lastWriterEpoch 最新的日志文件对应的编号，会每次在写新的 segment，即 startLogSegment RPC 调用时，会记录或者更新
   

5. AcceptedInEpoch 上次恢复接受的提案编号，在 accept 阶段持久化 ，什么时候 AcceptedInEpoch 会大于 LastWriterEpoch?，当在一次 paxos 协议执行到 accept 都成功，执行恢复前假设 epoch 是 1， lastWriterEpoch 也是 1，则当前的 epoch 是 2（ newEpoch）但是在最后 finalize 时，在发给最后一个 journal node 时 ActiveNamenode 又 crash 了，这时这个没有收到 finalize 请求的，他的 AcceptedInEpoch 是 2，他的 lastWriterEpoch 还是 1，因为还没有 stargLogSegment，所以还是 1，这种情况下下次再执行 paxos 恢复时，应该恢复 AcceptedInEpoch 对应的 segemnt，这也是在 2 段提交 (2PC) 在 commit 阶段出现故障时，保障一致性的一种容错方式，值得借鉴。

3.2 AccepteRecovery

根据 PrepareRecovery 选择的结果根据一个算法，选中一个segment，给所有的journal 发送 accept 请求，告诉他们都要和指定的 segment 达到一致，怎么样达成一致，下面会分析到。

PrepareRecover 对应 Paxos 的第一阶段，AccepteRecover 对应第二阶段

在分析具体的2PC实现之前，先上个图，了解下大概流程

请到「今天看啥」查看全文