HBase为何未采用Raft、Paxos等共识算法？

核心逻辑：靠WAL天然有序性+严格串行消费避免乱序 #

HBase的WAL本身是严格按写入顺序追加的不可变文件——主节点上所有写操作都会按照实际执行的先后顺序写入WAL，绝不会出现内部条目乱序的情况。而复制流程的两个关键环节彻底锁死了顺序：

• 主节点的复制守护进程（HLog复制器）会按WAL的物理写入顺序逐条读取日志条目，不会跳读或打乱顺序。
• 从节点接收日志后，会维护一个全局的复制进度标记（比如对应WAL的文件名+偏移量），并且串行应用这些日志条目到本地存储，绝不会并行执行或者调整顺序。

你担心的「先设true再设false，从节点反转顺序导致最终状态为true」的情况根本不会发生——主WAL里这两个操作是按顺序写的，从节点一定会严格按这个顺序执行，最终状态必然是false。

为什么不需要共识协议？ #

共识协议（比如Paxos、Raft）的核心是解决多节点写时的顺序协商问题，当多个节点都能发起写操作时，需要通过共识来统一全局顺序。但HBase的主从复制是单向的主→从同步模型：

• 所有写操作仅在主节点执行，而且HBase通过Region的单点写分配（一个Region同一时间只由一个RegionServer负责写）保证了主节点上的写操作天然有序，不需要和其他节点协商。
• 从节点只是被动接收并应用日志，不参与写决策，自然不需要共识协议来协调顺序。

异常场景下的顺序兜底 #

如果遇到网络波动导致从节点断连，恢复后复制器会直接从上次记录的偏移量位置继续读取主节点的WAL，不会跳过或乱读日志。就算主节点故障切换，HBase也会通过ZooKeeper记录主节点的WAL进度，新主节点的WAL会延续之前的顺序标记，保证复制的连续性和顺序性。

内容的提问来源于stack exchange，提问作者Yaswanth Tavva