पाठ 15 / 32
वितरित ट्रांज़ैक्शन और सागा
एक साझा डेटाबेस के बिना सेवाओं में डेटा को सही रखना।
यह कठिन क्यों है
एकल-डेटाबेस ट्रांज़ैक्शन मुफ़्त में एटॉमिक होता है। एक बार डेटा अलग-अलग डेटाबेस वाली अलग-अलग सेवाओं में रहने लगे, तो बहु-चरण ऑपरेशन को समग्र रूप से सफल या विफल बनाने के लिए स्पष्ट प्रोटोकॉल चाहिए।
टू-फ़ेज़ कमिट
2PC में एक कोऑर्डिनेटर हर भागीदार से prepare करने को कहता है (लॉक करें और कमिट का वादा करें), फिर, केवल यदि सभी हाँ कहें, सबको commit करने को कहता है। यह मज़बूत कंसिस्टेंसी देता है पर कोऑर्डिनेटर बीच में मरे तो अटक जाता है — बड़े स्केल, उच्च-उपलब्धता सिस्टम के लिए कमज़ोर फ़िट।
सागा पैटर्न
एक सागा ट्रांज़ैक्शन को स्थानीय ट्रांज़ैक्शन की एक श्रृंखला में तोड़ता है, हर एक के साथ इसे पूर्ववत करने के लिए एक प्रतिपूरक क्रिया। यदि 5 में से चरण 4 विफल हो, तो आप चरण 3, 2, 1 के लिए प्रतिपूरण चलाते हैं — सेवाओं में कोई लॉक नहीं रहता, पर आप eventual consistency के लिए डिज़ाइन करते हैं।
स्केल पर सागा को प्राथमिकता दें
अधिकांश बड़े सिस्टम (ई-कॉमर्स चेकआउट, यात्रा बुकिंग) वर्कफ़्लो इंजन द्वारा ऑर्केस्ट्रेटेड या इवेंट के ज़रिए समन्वित सागा उपयोग करते हैं, 2PC को संकीर्ण, कम-लेटेंसी दायरों जैसे एकल डेटाबेस क्लस्टर के लिए सुरक्षित रखते हैं।