背景介绍
HDFS namenode在进行写入操作时记录日志。 HDFS日志最早写入本地，每次重新启动或出现故障时重新启动。 通过本地镜像文件操作日志，可以恢复到宕机前的状态，没有数据不一致的情况。 尝试实现高可用性(HA )时，日志会写入各个计算机，导致该计算机的磁盘出现问题，重新启动后将无法恢复，从而导致数据不一致。 会发生新文件不存在、删除成功仍存在等可疑现象。 这在分布式存储系统中是不可接受的。
在独立系统中，保证在wal(writeaheadlog )日志中发生问题时的恢复，在HDFS中为操作日志) EditLog )，记录每个操作的动作记述。 下面简要介绍了editlog的格式。
文件格式
正在编辑的日志edits_inprogress_txID (后面将提到的segment和txid )表示日志文件中的第一个事务id
Finalized日志不再一致更改的日志文件edits_fristTxit_endTxid
内容格式
文件头：有版本号事务头id
文件内容
1操作型-1字节
2日志长度-4字节
3个事务txid -字节
4内容
5校验和- 4字节
文件结尾：事务id
请注意，以前没有日志分布式日志。 每次flush日志时，都会在该段日志之后添加INVALID_TXID，并在下一次flush时复盖该标志，但当前版本中已删除该标志
虽然editlog可以提供独立系统的可靠性，但至少需要两个名称模式，才能在分布式环境中确保namenode的高可用性。 要实现高可用性和可靠性，首先要保证HDFS的操作日志(EditLog )中有副本。 但是，有副本会产生新的问题。 如何保证多个复制副本之间的一致性？ 这是分布式存储必须解决的问题。 为此，Clouder公司开发了QJM (QJM )解决了这个问题。
Journal Node 集群
日志节点是根据paxos的思想设计的，只不过一半以上的写入成功了，即使这次写入成功了。 所以，journal需要引进三台组成一个集群，核心思想是一半的Quorum，异步写入多个Journal Node。简要说明将
写日志过程
editlog写入多个节点的过程。
ActiveNamenode 写日志到 Journal Node，采用 RPC 长连接
StandbyNamenode 同步已经 Finally 日志生成镜像文件，以及 Journal Node 直接同步数据，采用 HTTP
活动名称每次收到事务请求时，都会先写日志。 写这个日志的过程，网上分析了很多好文章，这里只是大致叙述了一些值得我们学习的地方和一些好的设计思想。
1 批量刷磁盘
应该说是写日志的一般做法，每次日志来都要刷磁盘，所以效率很低。 批量刷光盘可以合并很多小IO。 (类似于MySQL的组提交) )。
2 双缓冲区切换
buf当前日志写入缓冲区bufReady用于刷新磁盘的缓冲区如果没有双缓冲区，则在写入日志缓冲区已满时强制刷新磁盘。 我们知道，刷新磁盘不仅要刷新操作系统内核缓冲器，而且要刷新磁盘设备也需要相当长的时间。 引入双缓冲区后，可以同时执行刷新磁盘和写入日志的操作，从而大大提高了Namenode的吞吐量。
恢复数据
数据恢复在Active Namenode crash后由standby namenode继承，变更为Active Namenode后，首先需要进行的是， 这是指在恢复原始的活动名称分类时，编辑程序将恢复日志节点的数据。因此，如果标准节点可以正式声明为可对外工作，则必须匹配日志节点集群的数据以下主要分析恢复算法。 恢复算法官方称是基于multi paxos算法的。
Multi Paxos
Paxos协议是分布式系统中最复杂的协议，在互联网上主要讲概念和理论，不怎么讲实践，所以写正文也是为了更好地理解paxos。 网络上有很多关于paxos的资料。 可以看到丹博最近分享的ppt。 我说得很明白。多传真操作系统是传真操作系统的改进版。 由于Basic paxos将在paxos的每一轮中生成新的专业技术支持，因此这通常是由任何人都可以开始选举的多点编写的，就像zk Leader选举一样。 但是，大多数分布式系统都有leader，leader开始提供专业技术支持。 然后，可以使用第一个专业技术支持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 如下信息：
是否有 segment
有 segment，则附加 segment 的状态
committedTxnId 该 journal node 已经提交的事务 ID，QJM 每次日志同步后，会更新每个 AsyncLogger 的 committedTxnId，journal node 也每次请求都检查传过来的 committedTxnId，如果大于，则更新到本地。
lastWriterEpoch 最新的日志文件对应的编号，会每次在写新的 segment，即 startLogSegment RPC 调用时，会记录或者更新
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实现之前，先上个图，了解下大概流程
上图主要包含的流程总结如下
Prepare Recovery
PrepareRecoverRequest
prepareResponse
checkRequest 并选择一个 segment 来做为同步源
Accept Recovery
客户端发起AcceptRecovery
Journal 接受 AcceptRecovery 请求
接受请求后的检查 segment 是否包含事务
接受请求后的检查上一次 paxos 是否正常完成，这里的检查是判断是否需要去同步数据
commit
这里分别对每个阶段的主要行为分析如下：
PrepareRecoverRequest(P1a)
第一阶段，发起提案
服务端 Journal(prepareResponse) P1b:
checkRequest
journal 在newEpoch,发起提案，接受提案都通过 checkRequest 来检查提案编号epoch,的合法性，并做对应的操作
选择一个 segment 来做为同步源
第一阶段准备恢复完成后，如果超过半数以上的节点返回，则需要从这些返回的日志文件segment中选择一个最合适的副本。下面就是选择算法
选择的算法如下：
近可能选择一个存在segment的文件来恢复，因为有的 journal node 可能不包含对应的 segment
两个都保护 segment 文件,检查他们的 startTxid，如果不相等，这不合逻辑，抛异常
如果都存在 segment 则比较他们的状态，Finalizer 优先于 InProgress，因为 finalized 代表最新的
如果两个 segment 都是 finalized，则检查他们的长度是否一致，不一致也是不正常的，因为 finalized 是不会变的，长度应该一样。一样的话随便选择一个
比较 Epoch，如果 epoch 不一样，则选择最新的 epoch，这里特别注意上面提到的 AcceptedInEpoch 和 lastWriterEpoch 的比较
如果 Epoch 相等，则比较 segment 文件长度，选择较长的
客户端发起AcceptRecovery(P2a)
第一阶段完成即根据提案的响应从中选择一个 value，作为发起 accept 请求的提案，选择算法上面已经描述，接下来就发发起 accept 请求。
Journal接受AcceptRecovery请求(P2b)
accept 阶段需要对提案编号 epoch 检查，因为在提案阶段做了承若。
1 接受请求后的检查 segment 是否包含事务
2 接受请求后的检查上一次 paxos 是否正常完成，这里的检查是判断是否需要去同步数据
检查是否存在上次没有恢复完成的数据，即上轮 paxos 失败了，又发起了新的恢复这里是检查上轮 paxos 实例是否做完，正确退出；如果没有正常退出，则需要判断提案编号，如果本次 accept 的编号 epoch 小于上轮 paxos 的 epoch,则不对。
currentSegment 是当前 journal 本地的日志段,有两种情况需要从其它的journal node 同步数据
currentSegment is ，这种情况是 active namenode 还没有发送日志到该 journal 时就 crash了，而且是一个新的 segment
文件存在，但是 segment 的长度和需要恢复的 segment 长度不一致
客户端 恢复成功后，超过半数成功返回，则做 finalize
accept 成功后，做第三阶段，commit，这里是 finalize 操作，对文件进行重命名，以便被 namenode 读取
Journal Node 故障的情况
分布式日志系统，除了正常情况下的逻辑处理，更重要的是怎么容灾，如果超过一半，直接不写，因为 QJM 核心就是过半，但如果只是其中一个出现故障，是可以容忍的。
在其中一个 Journal Node Crash 的情况下， QJM 就不会往该故障的 Journal Node 发送日志流了，并标记 outOfSync 为 true, 在什么时候会重新往该节点发送数据呢？会在写新的日志文件时即 startLogSegment RPC 请求的时候，请求成功后，会检查对应的节点 outOfSync 是否为 true，如果是，则重新标记 false，让其开始接受日志，如果在写日志的过程中，有一个节点临时故障，比如网断，后面又恢复，在写新的日志文件之前， QJM 只是会发心跳给写过程中失败的节点，并带上当前的事务 ID(txid)，并不立即开始写，可以想下，如果是立即就写，会出现什么情况？ 至少会出现事务断层的现象，因为在出现故障期间的事务都没有写到该节点。
关于作者
ygdmf，上海欧电云信息科技有限公司架构师，个人对分布式存储，并发等底层相关的技术比较感兴趣，一直在学习的路上。