播面

在 HBase 2.x 中引入的 Procedure V2 (简称 PV2) 框架，是 HBase 架构演进中极具里程碑意义的改进（核心对应 Issue 为 HBASE-12439）。它的出现主要为了解决 HBase 1.x 时代在分布式状态管理、集群故障恢复（尤其是 Master 宕机）、并发控制以及代码维护等方面的深层痛点。

PV2 本质上是一个支持持久化、可恢复、支持回滚的分布式状态机执行框架。

以下是 PV2 框架具体解决的核心痛点：

1. 解决 Master 宕机导致的状态不一致与“永远的 RIT”问题（最核心痛点）

• 1.x 时代的痛点： 在 HBase 1.x 中，像建表、删表、Region 分裂（Split）、合并（Merge）、Region 转移（Assign/Unassign）等复杂的多步操作，其状态机散落在内存和 ZooKeeper 中。如果 HMaster 在执行这些操作的中途宕机，新的 Master 选举出来后，极难完全恢复之前中断的上下文。这会导致大量的 Region 处于 RIT（Region-In-Transition）状态且无法自动恢复，运维人员被迫频繁使用 hbck 工具进行人工干预修复。
• PV2 的解决方式： PV2 引入了类似数据库的 WAL（Write-Ahead Log）机制，称为 Procedure WAL。任何操作（Procedure）的每一步状态变化，都会先持久化到 Procedure WAL 中。如果 Master 宕机，新 Master 启动时只需回放（Replay）这个 WAL，就能精准知道每个任务执行到了哪一步，并继续往下执行，实现了断点续传，极大降低了由于 Master 故障导致的集群不一致。

2. 摆脱对 ZooKeeper 的重度依赖与滥用

• 1.x 时代的痛点： 1.x 极度依赖 ZooKeeper 来存储 Region 的状态变更（创建大量的 ZNode），并依赖 ZK 的 Watcher 机制来做事件通知。但 ZK 的 Watcher 是异步的，且在网络抖动或全量垃圾回收（Full GC）时容易丢失事件或产生“脑裂”现象。状态同步在 Master 端内存、RegionServer 和 ZooKeeper 三者之间来回流转，逻辑极其脆弱。
• PV2 的解决方式： PV2 将复杂操作的控制权完全收拢到 Master 内部（Master 成为真正的“大脑”）。Region 的状态转换不再通过修改 ZK 节点来通知，而是由 Master 直接通过 RPC 指令下发给 RegionServer。ZooKeeper 被“降级”回其本职工作（服务发现、Master 选举等），消除了复杂的 ZK 状态同步痼疾。

3. 解决缺乏统一的事务/回滚机制的痛点

• 1.x 时代的痛点： 在 1.x 中，如果一个包含多步的 DDL 操作（例如建表建了 50 个 Region，建到第 30 个时出错）失败了，系统缺乏自动清理已完成工作（即“回滚”）的能力，往往会遗留脏数据（半张表）。
• PV2 的解决方式： PV2 强制要求所有接入该框架的操作必须实现状态机的两个核心方法：execute()（执行）和 rollback()（回滚）。如果在执行中途发生不可恢复的错误，PV2 框架会自动逆序调用历史步骤的 rollback() 方法，将系统恢复到操作前的干净状态，提供了类似数据库事务的保障。

4. 解决缺乏全局并发控制和锁机制的问题

• 1.x 时代的痛点： 1.x 缺乏一个统一的资源锁机制。例如，当客户端正在请求对某个 Table 进行 Disable 操作时，可能系统内部恰好在对该 Table 的某个 Region 进行 Split 或 Merge。这种并发冲突会导致灾难性的状态混乱。
• PV2 的解决方式： PV2 框架内置了一套层级锁（Hierarchical Locking）机制，涵盖 Namespace、Table、Region Server、Region 四个级别。
  • 例如，在对 Region 进行 Split 时，会获取 Region 级别的互斥锁，并对 Table 获取共享锁。
  • 如果此时有 Disable Table 的操作，它需要获取 Table 级别的互斥锁。由于 Table 已被加上了共享锁，Disable 操作会被挂起，直到 Split 结束。这完美解决了各类并发操作的冲突。

5. 解决代码高度碎片化、难以扩展与维护的痛点

• 1.x 时代的痛点： 在没有统一框架之前，每新增一种运维操作（如 Snapshot、Clone、Split、Merge），开发者都需要从头编写一套线程池、异步回调、ZK 监听、容错处理的代码。代码冗余度极高，且极难排查 Bug。
• PV2 的解决方式： PV2 提供了一个高度抽象、类似于“操作系统调度器”的基础组件（ProcedureExecutor）。开发者只需要继承 Procedure 类，编写业务逻辑的每一步（State），而不需要关心多线程调度、崩溃恢复、锁管理、持久化等底层细节。这让 HBase 后续的代码迭代变得非常清晰和稳定。

总结

HBase 2.x 的 Procedure V2 框架 是对 HBase 核心管控链路的一次“脱胎换骨”的重构。基于 PV2，HBase 重写了著名的 Assignment Manager (AMv2)。它解决了以前动不动就产生僵尸 RIT、极度依赖 ZK、Master 单点故障恢复难的顽疾，让 HBase 的可用性（Availability）和可维护性上升到了一个全新的台阶。这也是为什么 HBase 2.x 敢于宣称大幅减少了对 hbck 工具依赖的根本原因。