监督机制其实是对两阶段提交协议（2PC）的实践，仔细想想，除了机器坏掉，还有一些情况会破坏交易的原子性。

例如：A账户要扣掉100块，但是它的余额只有90块，或者已经达到了今天的转账限额，这种情况下，如果贸然给B账户加了100块，A账户却不够扣，就会陷入麻烦了。

反之如果B账户状态有异常，不能加100块，同样会有麻烦。解决这个问题的方法，就是引入一位“裁判员”。裁判员站在A账户和B账户旁边，它的工作流程是这样的：

1. 裁判员问A账户：你的三台机器都没问题吧？A账户说：没问题。

2. 裁判员问A账户：你的账户允许扣100吗？A账户说：允许。

3. 裁判员问B账户：你的三台机器都没问题吧？B账户说：没问题。

4. 裁判员问B账户：你的账户状态能接受加100吗？B说：允许。

5. 这时，裁判员吹哨，A、B账户同时冻结。

6. A扣100，B加100，双方向裁判汇报“成功”。

7. 裁判员再吹哨，A、B账户同时解冻。

以上7步，都是按时间顺序完成的，卡在任何一步，账目都不会乱，一分钱都不会丢。完全符合“原子化”的要求。

1. 两阶段提交（Two-Phase Commit, 2PC）：

   • 在分布式系统中，为了保证跨多个节点的操作能够要么全部成功，要么全部失败，通常会使用两阶段提交协议。这个过程分为准备阶段（Prepare Phase）和提交阶段（Commit Phase）。在准备阶段，协调者向参与者发送准备请求，参与者准备好之后回复给协调者；在提交阶段，如果所有参与者都准备好了，则协调者会发出提交命令，否则会发出回滚命令。

2. 单机事务：

   • 对于只涉及单个节点的事务，OceanBase 可以直接利用单机数据库的事务机制来保证原子性，这通常依赖于底层的数据库管理系统（DBMS）提供的事务功能。

3. 多版本并发控制（MVCC）：

   • OceanBase 使用多版本并发控制来支持高并发读写操作，同时保证事务的一致性和隔离性。通过维护数据的多个版本，可以在不阻塞写操作的情况下允许读操作访问旧版本的数据。

4. 全局唯一事务 ID (GTS)：

   • OceanBase 使用全局唯一的事务 ID（Global Transaction ID, GTID）来标识每一个事务，并且在事务开始时获取一个全局一致的事务序号，以此来保证事务执行的顺序性和一致性。

5. 故障恢复机制：

   • OceanBase 还包括了故障恢复机制，在系统出现故障后能够恢复到一个一致的状态，这也间接地支持了事务的原子性。

通过这些机制的组合使用，OceanBase 能够在分布式环境下保证写操作的原子性，使得即使在分布式环境中，事务也能像在一个单一的数据库实例中那样执行。

裁判员充当2PC中的协调器角色。