लेन-देन संदेश

लेन-देन संदेश वास्तुशिल्प तकनीकों का एक सेट है जो स्थानीय राज्य परिवर्तन (डेटाबेस/कैश) और ब्रोकर/बस पर संदेशों के बीच स्थिरता सुनिश्चित करता है। उद्देश्य: "राज्य निश्चित है - विफलताओं, रिट्रेज़, स्केलिंग और बहु-किरायेदारी के मामले में संदेश खो या दोहराया नहीं गया है"।

1) वितरण शब्दार्थ

सबसे अधिक एक बार: त्वरित और सस्ता, नुकसान संभव है, कोई नहीं लेता है।

कम से कम-एक बार: संदेश नहीं खोता है, डुप्लिकेट संभव है - पहचान की आवश्यकता है।

(प्रभावी) वास्तव में एक बार: कोई नुकसान नहीं होता है और कोई भी व्यावसायिक प्रभाव के लिए दिखाई नहीं देता है, तकनीकों के संयोजन (आउटबॉक्स/इनबॉक्स, उत्पादक/उपभोक्ता लेनदेन, डीडअप) द्वारा प्राप्

2) "दो-अक्षर" खतरनाक क्यों है

Naive तर्क "पहले डेटाबेस को लिखें, फिर बस में भेजें" (या इसके विपरीत) चरणों के बीच गिरने पर टूट जाता है: डेटा तय हो जाता है, और घटना खो जाती है; या तो घटना चली गई है, लेकिन कोई डेटा नहीं है। लेन-देन संदेश इस अंतर को पुल करता है।

3) बुनियादी पैटर्न

3. 1 आउटबॉक्स (निर्माता)

एक स्थानीय लेनदेन में, हम व्यवसाय परिवर्तन और पंक्ति को 'आउटबॉक्स' तालिका में लिखते हैं; एक अलग प्रकाशक आउटबॉक्स पढ़ ता है और रेट्रास और बैकऑफ के साथ एक दलाल में प्रकाशित होता है। बाहर रखा गया नुकसान; उपभोक्ताओं के बीच निष्क्रियता से युगल बुझ जाते हैं।

3. 2 इनबॉक्स/आइडेम्पोटेंट उपभोक्ता

प्रभाव को निष्पादित करने से पहले, उपभोक्ता प्राथमिक कुंजी के रूप में 'इनबॉक्स (उपभोक्ता, event_id)' में 'INSERT' बनाता है। कुंजी संघर्ष = घटना पहले से ही संसाधित → छोड़ दें। इस तरह "प्रभावी रूप से एक बार" हासिल किया जाता है।

3. 3 ऑफसेट लेनदेन के साथ पढ़ें-प्रक्रिया-लिखें

लॉग-ओरिएंटेड बसों के लिए साँचा: उपभोक्ता बैच को पढ़ ता है, एक ही लेनदेन में व्यवसाय परिवर्तन और "पारित ऑफसेट" रिकॉर्ड करता है। "प्रतिबद्धता के बाद, दलाल उपभोग किए गए संदेशों पर विचार करता है। यह प्रभाव में डुप्लिकेट्स के बिना "रीड → फॉल → रिपीट" को समाप्त करता है।

3. 4 टीएसएस/सागास इंटरसर्विस प्रभाव के लिए

जब आपको एक सुसंगत बहु-चरण प्रक्रिया की आवश्यकता होती है, तो टीसीसी या सागा का उपयोग करें; संदेश - आदेशों/घटनाओं का परिवहन, और लेन-देन - चरणों और मुआवजे के स्तर पर।

4) बेवकूफ उत्पादक और उपभोक्ता

निर्माता: स्थिर 'संदेश _ id '/' idempotency _ key', एक ही कुंजी के साथ पुनर्निर्मित होने से ग्राहकों के लिए नए प्रभाव नहीं बनते हैं; कुंजी द्वारा अनुक्रम बनाए रखें।

उपभोक्ता: 'इनबॉक्स' + बिजनेस आइडेम्पोटेंसी (upsert/merge, नवीनतम संस्करण/संशोधन की जाँच करें)।

5) आदेश और कारण

व्यवसाय कुंजी (उदाहरण के लिए, 'एग्रीगेट _ आईडी', 'किरायेदार _ आईडी') द्वारा भाग लें ताकि एक वस्तु की घटनाएं क्रम में आएं।

लॉट के अंदर लगातार संख्या/टाइमस्टैम्प रखें; जब DLQ से फिर से तैयार किया जाता है, तो "कुंजी और क्रमिक रूप से" का निरीक्षण करें।

यदि वैश्विक व्यवस्था महत्वपूर्ण नहीं है, तो कुंजी द्वारा स्थानीय व्यवस्था सुनिश्चित करें और डोमेन आक्रमणकारि

6) ऑफसेट और फिक्सिंग प्रभाव

विकल्प ए: "डीबी में ऑफसेट"

"अंतिम संसाधित ऑफसेट (विभाजन, ऑफसेट)" को उसी लेनदेन पर लिखें जहाँ आप डोमेन डेटा बदलते हैं। पुनः आरंभ करते समय, अगले ऑफसेट से जारी रखें, एक बार-बार प्रभाव से बचें।

विकल्प बी: ब्रोकर लेनदेन

कुछ दलाल एक उत्पादक/उपभोक्ता लेनदेन में संदेशों और ऑफसेट की परमाणु रिकॉर्डिंग का समर्थन करते हैं। यदि उपलब्ध हो, लेकिन हमेशा उपभोक्ता पर पहचान के साथ पूरक का उपयोग करें।

7) रेट्राई, बैकऑफ, डीएलक्यू

घातीय बैकऑफ और जिटर के साथ केवल वापस लेने योग्य त्रुटियों (टाइमआउट, 5xx) को दोहराएं।

गैर-वापस लेने योग्य (स्कीमा/सत्यापन) - तुरंत डीएलक्यू में मेटाडेटा (किरायेदार, कुंजी, ऑफसेट, कारण) के साथ।

DLQ (बैच, दर सीमा) से पुनर्वितरण की खुराक लें, दोहराने से पहले सर्किट की जांच करें, कुंजी द्वारा आदेश का निरीक्षण करें।

8) बहु-किरायेदारी और क्षेत्र

संदेश मेटाडेटा और पार्टीशन कुंजियों में 'किरायेदार _ id', 'योजना', 'क्षेत्र' शामिल करें.

प्रति-किरायेदार निष्पक्षता: प्रकाशन/प्रसंस्करण को सीमित करें ताकि "शोर" ग्राहक बाकी से बजट में कटौती न करे।

रेजीडेंसी: डोमेन डेटा के समान क्षेत्र में संदेश और आउटबॉक्स स्टोर करें; अंतर प्रतिकृतियाँ - अतुल्यकालिक समुच्चय।

9) अवलोकन और लेखा परीक्षा

ट्रेसिंग: सहसंबंध 'इवेंट _ id '/' एग्रीगेट _ id '/' saga _ id', "red → process → lite/commit"।

मेट्रिक्स: प्रकाशन/प्रसंस्करण लैग (p95/p99), सफलता दर, डीएलक्यू-दर, सफलता को फिर से प्राप्त करना, "डुप्लिकेट दबाया"।

लॉग: सफलता के लिए छोटा; त्रुटियों पर विवरण (कारण, प्रयास, कुंजी, ऑफसेट)।

ऑडिट: कौन फिर से तैयार/लुढ़का, किस बैच और किस परिणाम के साथ।

10) सुरक्षा और अनुपालन

पेलोड में पीआईआई को न्यूनतम करें; डीएलक्यू/लॉग में स्थानांतरित करते समय मास्क।

बाहरी बसों के लिए साइन/एन्क्रिप्ट संदेश; सेवाओं के बीच mTLS का उपयोग करें।

प्रति किरायेदार/क्षेत्र शेल्फ जीवन और "भूलने का अधिकार" प्रबंधित करें।

11) विशिष्ट एकीकरण योजनाएं

1. सेवा स्रोत (राइट-साइड)

स्थानीय लेनदेन: डोमेन रिकॉर्ड + आउटबॉक्स।

प्रकाशक: बैच, 'SKIP LOCKED', बैकऑफ, प्रति किरायेदार सीमा।

लैग 'नो − occurred_at' की निगरानी।

2. सेवा-उपभोक्ता (रीड-साइड)

बैच पढ़ ना - 'इनसर्ट इनबॉक्स (उपभोक्ता, )' की कोशिश कर रहा है - यदि सफल हो, तो हम प्रभाव को निष्पादित करते हैं।

उसी लेनदेन में, हम "पास ऑफसेट" (विकल्प ए) को ठीक करते हैं या ब्रोकर के लेनदेन (विकल्प बी) पर भरोसा करते हैं।

त्रुटि पर: नीति के अनुसार पुनः प्राप्त या DLQ।

3. प्रक्षेपण/भौतिक दृश्य

केवल पहचान अद्यतन (अपसर्ट), कॉम्पैक्ट डीडुप्लिकेशन कुंजियाँ, आवधिक चेकसम सत्यापन।

12) कॉन्फ़िगरेशन टेम्पलेट (उदाहरण)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) प्री-सेल चेकलिस्ट

• "दो-अक्षर" को समाप्त कर दिया: निर्माता पर आउटबॉक्स या उपभोक्ता पर एक लेनदेन में ऑफसेट और प्रभाव को ठीक करना।
• आइडेम्पोटेंट उपभोक्ता: 'इनबॉक्स '/डेडअप जर्नल, संचालन की व्यावसायिक पहचान।
• व्यापार कुंजी द्वारा विभाजन, स्थानीय आदेश का पालन किया जाता है।
• बैकऑफ + जिटर रिट्रेसेस, त्रुटि वर्गीकरण, मेटाडेटा समृद्ध डीएलक्यू।
• Redrave dosed, सुरक्षित; प्लेबुक हैं।
• बहु-किरायेदार सीमाएं और प्राथमिकताएं; 'किरायेदार _ आईडी/योजना/क्षेत्र' टैग।
• टेलीमेट्री: लैग्स, सफलता दर, "डुप्लिकेट्स दबा", p95/p99 द्वारा अलर्ट।
• PII/प्रतिधारण/एन्क्रिप्शन नीतियां लागू हैं।
• परीक्षण: चरणों, डुप्लिकेट, कुंजी क्रम, बड़े पैमाने पर redraw के बीच छोड़ दें।

14) विशिष्ट त्रुटियां

बस में भेजना और डाटाबेस को बिना आउटबॉक्स/ऑफसेट लेनदेन के अलग-अलग चरणों में लिखना।

बिना पहचान के एक उपभोक्ता → दुष्प्रभावों की नकल करता है।

वैश्विक आदेश "आओ क्या हो सकता है" महंगा है और शायद ही कभी उचित है; कुंजी द्वारा पर्याप्त

सीमा के बिना एक बड़े पैमाने पर redraw - एक माध्यमिक घटना।

ट्रेसिंग/लैग मेट्रिक्स की कमी - "छिपी हुई गिरावट"।

DLQ/लॉग में PII मिश्रण।

15) त्वरित व्यंजनों

SaaS घटनाएँ: Outbox + idempotent उपभोक्ता (इनबॉक्स), 'किरायेदार _ id: कुल _ id' द्वारा विभाजन।

ETL/अनुमान: एक लेनदेन में ऑफसेट को ठीक करने के साथ रीड-प्रोसेस-राइट, बैच 500-1000, अपसर्ट।

उच्च भार: प्रकाशन शार्डिंग, 'SKIP LOCKED', WFQ प्रति किरायेदार, अंतराल नियंत्रण।

सख्त अनुपालन क्षेत्र: क्षेत्रीय आउटबॉक्स, पेलोड एन्क्रिप्शन, रिड्राइव्स का प्रतिधारण और ऑडिट।

निष्कर्ष

ट्रांजेक्शनल मैसेजिंग डेटा और संदेशों को जोड़ ने का अनुशासन है। आउटबॉक्स/इनबॉक्स, आइडेम्पोटेंसी, ऑफसेट फिक्सेशन के साथ-साथ प्रभाव और डीएलक्यू के साथ प्रबंधित रिट्रेस के संयोजन से, आपको वैश्विक ताले के बिना व्यावहारिक रूप से एक बार व्यवहार मिलता है और दुर्घटनाओं, चोटियों और जटियों के शोषण के साथ भी।