Jitter-Tolerant Two-Phase Commit Protocol for Distributed Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional distributed two-phase commit (2PC) protocols experience latency amplification due to jitter, leading to compromised write I/O performance and potential system halting, especially in high workloads, as write requests are committed sequentially and require all hosts to agree, causing delays and accumulation of inflight prepare requests.
Innovation Solution
Assigning a monotonically increasing unique prepare ID in the prepare phase instead of a log sequence number (LSN) allows write requests with higher prepare IDs to be committed without waiting for lower ID requests, reducing latency and preventing system overload by allowing parallel commitment of requests with higher IDs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional distributed 2PC protocol commits write requests sequentially requiring all hosts to agree, then atomicity and consistency are ensured, but latency increases and write I/O performance deteriorates due to jitter-related delays
Solution Approach 1:
The patent segments the commit process by introducing independent commit batches for different prepare IDs. Each batch can be committed independently without waiting for other batches, breaking the sequential dependency chain that causes latency amplification while maintaining atomicity within each batch through the 2PC protocol
Solution Approach 2:
The patent performs preliminary actions by assigning monotonically increasing prepare IDs to write requests before committing them. This allows the system to pre-order and batch multiple write requests, then commit them in parallel batches rather than sequentially, reducing overall latency while ensuring consistency through the prepare-commit mechanism
2Stability of the object's composition
If conventional distributed 2PC protocol waits for all hosts to agree on each write request, then data consistency across hosts is maintained, but system throughput decreases due to accumulation of inflight prepare requests
Solution Approach 1:
The patent segments the commit workload into multiple independent batches identified by different prepare IDs. Each batch can be processed and committed independently by different hosts in parallel, increasing system throughput while maintaining data consistency through the 2PC prepare-commit mechanism within each batch
Solution Approach 2:
The patent enables continuous processing of write requests by allowing multiple commit batches to be in flight simultaneously. While one batch is being committed, the system can continue preparing and committing other batches with different prepare IDs, eliminating idle time and improving overall system throughput while maintaining consistency through the 2PC protocol
3Loss of information
If conventional distributed 2PC protocol processes write requests in sequential order with monotonically increasing LSNs, then log sequence integrity is maintained, but latency amplification occurs due to jitter causing system halting
Solution Approach 1:
The patent segments the log sequence into independent batches identified by monotonically increasing prepare IDs. Each batch represents a discrete unit of work that can be committed independently without affecting other batches, maintaining log integrity through the prepare-commit mechanism while enabling parallel processing to reduce latency amplification
Solution Approach 2:
The patent performs preliminary ordering by assigning monotonically increasing prepare IDs to write requests before batching and committing them. This preliminary assignment ensures log sequence integrity is maintained while allowing the actual commit operation to proceed in parallel batches, reducing latency amplification caused by sequential processing
Data Source
AI summary
A method of ensuring atomicity of transactions across a plurality of active hosts in a distributed environment, is provided. The method generally includes receiving, from a client, a second request to commit a second transaction subsequent to receiving a first request to commit a first transaction; assigning a second prepare identifier (ID) to the second transaction, wherein the second prepare ID assigned to the second transaction is greater than a first prepare ID assigned to the first transaction; transmitting, to the plurality of active hosts, instructions to prepare for committing the second transaction, the instructions including the second prepare ID; receiving, from each host, an acknowledgement indicating successful preparation for committing the second transaction; and transmitting, to the plurality of active hosts, instructions to commit the second transaction prior to receiving, from each host, an acknowledgement indicating successful preparation for committing the first transaction.