想了解下为什么不基于rocksdb提供的transaction来做2pc？
关于为什么不基于RocksDB提供的transaction来做2PC，这里有几个关键点需要考虑：
-
RocksDB事务模型：RocksDB提供了基本的事务支持，包括乐观事务和悲观事务。然而，2PC（两阶段提交）是在悲观事务的基础上进一步实现的，用于保证在分布式系统中事务的原子性。RocksDB的事务模型主要是为了单机存储引擎设计的，而不是为了处理跨多个节点的分布式事务。
-
2PC的实现复杂性：2PC协议本身在实现上比较复杂，它需要在准备（Prepare）阶段将事务的变更写入WAL（Write-Ahead Log）但不写入Memtable，然后在提交（Commit）阶段再将变更写入Memtable。这种分离增加了实现的复杂性，并且可能导致内存和写入压力的问题。
-
性能考虑：在2PC中，Prepare阶段并不将数据写入Memtable，而是保留在WBWI（Write Batch With Index）的内存中。如果系统中存在大量的长事务，这将对内存造成很大压力。此外，Commit阶段可能会因为集中写入Memtable而导致write-stall，影响整体服务的TPS（每秒事务数）。
-
RocksDB的优化策略：为了解决上述问题，RocksDB提供了不同的write_policy策略，比如
WRITE_PREPARED和WRITE_UNPREPARED，以优化内存消耗和减少commit延时。这些策略允许在Prepare阶段就进行部分提交，以减少内存中待提交的数据量，并减少Commit阶段的写入压力。 -
分布式事务的需求：2PC通常用于分布式系统中，以确保跨多个节点的事务原子性。RocksDB作为一个单机存储引擎，其2PC的实现主要是为了支持上层构建分布式事务的系统，如MySQL的MyRocks引擎，而不是直接在RocksDB层面处理分布式事务。
-
RocksDB的2PC实现：RocksDB的2PC实现是为了提供给上层应用（如数据库管理系统）一个基础，让它们能够在RocksDB之上实现自己的分布式事务逻辑。RocksDB本身并不关心2PC的具体实现细节，它只提供必要的接口，如Prepare和Commit。
综上所述，RocksDB不直接基于其transaction来做2PC的主要原因是其事务模型主要是为单机设计的，而2PC是分布式事务的一部分，需要更复杂的实现和优化。此外，RocksDB提供了足够的接口和策略，让上层应用可以根据自己的需求实现和优化2PC。