Distributed Storage Timeout Synchronization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional distributed storage systems face data discrepancies due to node failures and temporary communication failures during data writing processes, leading to inconsistencies among storage nodes.
Innovation Solution
A distributed storage system that accepts update requests, notifies clients of failures, and synchronizes data among nodes when no reply is received within a predetermined time frame, ensuring data consistency through a put/get process involving primary, secondary, and tertiary nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional distributed storage systems write data to multiple nodes (primary, secondary, tertiary) to ensure data redundancy, then data availability is improved, but data consistency deteriorates due to node failures and communication timeouts
Solution Approach 1:
The system performs preliminary actions by establishing a timeout mechanism before data writing completes. When a node does not respond within the predetermined timeout period, the system proactively detects the failure and triggers a rollback operation to prevent inconsistent data states, rather than waiting for the inconsistency to manifest
Solution Approach 2:
The system implements feedback mechanisms where nodes send acknowledgment signals during the data writing process. The primary node monitors responses from secondary and tertiary nodes, and based on this feedback, determines whether to commit or rollback the transaction. This closed-loop feedback ensures data consistency by adjusting the commit decision based on actual node states
2Reliability
If the system waits for all nodes to confirm data writing to ensure consistency, then data consistency is improved, but system response time deteriorates due to timeout waiting and failure handling
Solution Approach 1:
The system sets predetermined timeout values in advance based on historical performance data and network conditions. This preliminary configuration allows the system to make quick failure detection decisions without performing complex real-time analysis, reducing the time loss while maintaining consistency
Solution Approach 2:
The timeout mechanism is dynamic rather than static. The system adjusts timeout thresholds based on operational conditions, node performance, and network status. This dynamic adjustment optimizes the balance between detecting failures quickly (reducing time loss) and allowing sufficient time for normal operations (maintaining consistency)
3Reliability
If the system implements comprehensive failure detection and rollback mechanisms to prevent data discrepancies, then data consistency is improved, but system complexity increases due to additional monitoring and synchronization protocols
Solution Approach 1:
The system extracts the failure detection and rollback logic into independent, modular components. Each node has a dedicated timeout monitoring module and a standardized rollback procedure, separating these reliability functions from the core data writing logic. This extraction reduces overall system complexity by creating reusable, isolated functional blocks
Solution Approach 2:
The system implements a standardized rollback mechanism that discards partial writes when failures are detected and recovers by restoring previous consistent states. This approach simplifies complexity by providing a uniform failure handling pattern rather than requiring complex conditional logic for each failure scenario
Data Source
AI summary
An internode put requesting unit detects a time-out with respect to a put request issued to the next node in the order of a multiplexing chain and notifies a put/get executing unit of the time-out. The put/get executing unit sends an error to the previous node in the order of the multiplexing chain or a client and instructs a put-failed-data synchronizing unit to synchronize data failed to be put, and the put-failed-data synchronizing unit performs a synchronization process. A primary makes other put requests wait until completion of the synchronization process. Furthermore, when having received the error, the client issues a get request to the tail end of the multiplexing chain.