Providing ACID transactions under conflicts across globally distributed data is the Everest of transaction processing protocols. Transaction processing in this scenario is particularly costly due to the high latency of cross-continent network links, which inflates concurrency control and data replication overheads. To mitigate the problem, we introduce Ocean Vista—a novel distributed protocol that guarantees strict serializability. We observe that concurrency control and replication address different aspects of resolving the visibility of transactions, and we address both concerns using a multi-version protocol that tracks visibility using version watermarks and arrives at correct visibility decisions using efficient gossip. Gossiping the watermarks enables asynchronous transaction processing and acknowledging transaction visibility in batches in the concurrency control and replication protocols, which improves efficiency under high cross-data center network delays. In particular, Ocean Vista can access conflicting transactions in parallel and supports efficient write-quorum/read-one access using one round trip in the common case. We demonstrate experimentally in a multi-data center cloud environment that our design outperforms a leading distributed transaction processing engine (TAPIR) more than tenfold in terms of peak throughput, albeit at the cost of additional latency for gossip and a more restricted transaction model. The latency penalty is generally bounded by one wide area network (WAN) round trip time (RTT), and in the best case (i.e., under light load) our system nearly breaks even with TAPIR by committing transactions in around one WAN RTT.

在全球分布的数据之间的冲突下提供ACID事务是事务处理协议的Everest。由于跨洲网络链接的高延迟，这种情况下的事务处理特别昂贵，这会增加并发控制和数据复制的开销。为了缓解该问题，我们引入了Ocean Vista-一种新颖的分布式协议，可确保严格的可序列化性。我们注意到并发控制和复制解决了解决事务可见性的不同方面，并且我们使用多版本协议解决了这两个问题，该协议使用版本水印跟踪可见性，并使用高效的八卦来做出正确的可见性决策。闲聊水印可在并发控制和复制协议中实现异步事务处理并批量确认事务可见性，从而在跨数据中心网络延迟高的情况下提高了效率。特别是，Ocean Vista可以并行访问冲突的事务，并支持有效的写入定额/读取一通常情况下，使用一次往返访问。我们在多数据中心云环境中进行了实验证明，我们的设计在峰值吞吐量方面比领先的分布式事务处理引擎（TAPIR）高出十倍以上，尽管这会增加闲聊的额外延迟和更严格的事务处理模型。延迟损失通常受一个广域网（WAN）往返时间（RTT）的限制，并且在最佳情况下（即，在轻负载下），我们的系统通过在一个WAN RTT内进行事务处理几乎可以使TAPIR达到收支平衡。