GH GambleHub

इवेंट सोर्सिंग: बेसिक्स

घटना सोर्सिंग क्या है

इवेंट सोर्सिंग (ईएस) डोमेन ऑब्जेक्ट्स की स्थिति को "वर्तमान लाइन" के रूप में संग्रहीत करने का एक तरीका है, लेकिन एक अपरिवर्तनीय घटना लॉग के रूप में जो कुछ भी हुआ उसका वर्णन करता है। कुल की वर्तमान स्थिति इसकी घटनाओं को रोल अप (रीप्ले) करके प्राप्त की जाती है, और इस लॉग के शीर्ष पर किसी भी पढ़े गए दृश्य को अनुमानों के रूप में बनाया जाता है।

मुख्य निहितार्थ:
  • इतिहास "सत्य का प्राथमिक स्रोत" है, राज्य इतिहास का प्रक्षेपण है।
  • किसी भी राज्य को दोहराया, जांचा और समझाया जा सकता है (ऑडिट)।
  • नए विचारों और एनालिटिक्स को जोड़ ने के लिए पुराने "स्नैपशॉट" के प्रवास की आवश्यकता नहीं है - यह घटनाओं को खोने के लिए पर्याप

मूल शब्द

स्पष्ट आक्रमणकारियों के साथ स्थिरता की समग्र डोमेन इकाई (आदेश, भुगतान, UserBalk)।

घटना - एक अपरिवर्तनीय तथ्य जो अतीत में हुआ ('भुगतान। अधिकृत ',' आदेश। भेज दिया ')।

इवेंट स्टोर एक परिशिष्ट-केवल लॉग है जो इकाई के भीतर घटनाओं का क्रम प्रदान करता है।

कुल संस्करण अंतिम लागू घटना (आशावादी संगति के लिए) की संख्या है।

स्नैपशॉट - दृढ़ संकल्प को गति देने के लिए राज्य की एक आवधिक छाप।

प्रक्षेपण (रीड-मॉडल) - पढ़ ने/खोज/रिपोर्टिंग (अक्सर अतुल्यकालिक) के लिए भौतिक दृश्य।

यह कैसे काम करता है (धागा → घटनाएँ → अनुमान)

1. क्लाइंट एक कमांड ('CaperPayMands', 'PlaceOrde') भेजता है।

2. कुल आक्रमणकारियों को मान्य करता है और, यदि सभी ठीक हैं, तो घटनाएं उत्पन्न करता है।

3. घटनाओं को परमाणु रूप से संस्करण सत्यापन (आशावादी संगति) के साथ इवेंट स्टोर में जोड़ा जाता है।

4. प्रोजेक्शन प्रोसेसर इवेंट फ्लो की सदस्यता लेते हैं और रीड मॉडल को अपडेट करते हैं।

5. जब कुल निम्नलिखित कमांड के लिए लोड किया जाता है, तो स्नैपशॉट (यदि कोई हो) → स्नैपशॉट के बाद की घटना के लिए स्थिति बहाल की जाती है।

घटना डिजाइन

आवश्यक गुण (कोर)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"aggregate_type": "Payment",
"aggregate_id": "pay_123",
"aggregate_version": 5,
"occurred_at": "2025-10-31T10:42:03Z",
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"meta": { "trace_id": "t-abc", "actor": "user_42" }
}
सिफारिशें:
  • नामकरण: 'डोमेन। क्रिया। v {प्रमुख} '।
  • एडिटिविटी: पुराने क्षेत्रों के अर्थ को बदले बिना, नए क्षेत्र वैकल्पिक हैं।
  • अतिसूक्ष्मवाद: केवल तथ्य, आसानी से वसूली योग्य डेटा के दोहराव के बिना।

संविदाएँ और योजनाएँ

स्कीमा (एवरो/जेसन स्कीमा/प्रोटोबुफ) फिक्स करें और सीआई पर संगतता की जांच करें।

"ब्रेकिंग" परिवर्तनों के लिए - घटना का एक नया प्रमुख संस्करण और प्रवास अवधि के लिए समानांतर प्रकाशन 'v1 '/' v2'।

प्रतिस्पर्धी पहुंच: आशावादी संगति

नियम: नई घटनाओं को केवल तभी लिखा जा सकता है यदि 'अपेक्षित _ संस्करण = = current_version'।

स्यूडोकोड:
pseudo load: snapshot(state, version), then apply events > version new_events = aggregate. handle(command)
append_to_store(aggregate_id, expected_version=current_version, events=new_events)
//if someone has already written an event between load and append, the operation is rejected -> retray with reload

इसलिए हम वितरित लेनदेन के बिना आक्रमणकारियों की अखंडता की गारंटी देते हैं।

स्नैपशॉट्स (कन्वोल्यूशन त्वरण)

हर N घटनाओं या टाइमर पर एक स्नैपशॉट लें।

Храните 'स्नैपशॉट _ state', 'एग्रीगेट _ id', 'वर्जन', 'क्रिएट _ at'।

स्नैपशॉट के बाद हमेशा घटनाओं की जांच करें और पकड़ें (सिर्फ कलाकारों पर भरोसा न करें)।

स्नैपशॉट निकालें ताकि उन्हें लॉग से फिर से बनाया जा सके ("जादू" फ़ील्ड को संग्रहीत न करें)।

अनुमान और CQRS

ES स्वाभाविक रूप से CQRS के साथ संयुक्त है:
  • लिखें-मॉडल = समुच्चय + ईवेंट स्टोर।
  • पढ़ें मॉडल = घटनाओं द्वारा अद्यतन अनुमान (रेडिस कार्ड, खोज के लिए ओपनसर्च, रिपोर्टिंग के लिए क्लिकहाउस/ओएलएपी)।
  • अनुमान निष्क्रिय हैं: एक ही 'ईवेंट _ आईडी' को पुनर्संसाधित करने से परिणाम नहीं बदलता है।

सर्किट विकास और संगतता

योगात्मक-पहला: क्षेत्र जोड़ें; प्रकार/शब्दार्थ न बदलें।

जटिल परिवर्तनों के लिए, नए ईवेंट प्रकार जारी करें और प्रोजेक्शन माइग्रेटर लि

संक्रमण अवधि के लिए एक डबल प्रविष्टि ('v1' + 'v2') बनाए रखें और सभी अनुमान तैयार होने पर 'v1' शूट करें।

सुरक्षा, पीआईआई और "भूलने का अधिकार"

इतिहास में अक्सर संवेदनशील डेटा होता है दृष्टिकोण:
  • घटनाओं में पीआईआई को न्यूनतम करें (डेटा के बजाय पहचानकर्ता, संरक्षित पक्षों में विवरण)।
  • क्रिप्टो-मिटाएँ: एन्क्रिप्ट फ़ील्ड और, जब हटाने के लिए प्रेरित किया जाता है, तो कुंजी को नष्ट कर दें (घटना बनी हुई है, लेकिन डेटा उपलब्ध नहीं है)।
  • संशोधन घटना: 'उपयोगकर्ता। piiredacted। v1 'अनुमानों में संवेदनशील क्षेत्रों के प्रतिस्थापन के साथ (इतिहास संपादन के तथ्य को संरक्षित करता है)।
  • प्रतिधारण नीतियां: कुछ डोमेन के लिए, कुछ घटनाओं को WORM भंडारण के लिए संग्रहीत किया जा सकता है।

निष्पादन और पैमाना

विभाजन: आदेश कुल के अंदर महत्वपूर्ण है - 'एग्रीगेट _ आईडी' द्वारा विभाजन।

ठंडी शुरुआत: स्नैपशॉट + आवधिक "कॉम्पैक्टिंग" कन्वोल्यूशन।

एक लेन - देन में बैच परिशिष्ट - समूह घटनाएं।

प्रक्षेपण प्रोसेसर के लिए बैकप्रेशर और डीएलक्यू; अंतराल (समय और संदेश की संख्या) मापते हैं।

इवेंट स्टोर इंडेक्सिंग: '(aggregate_type, aggregate_id)' और समय द्वारा त्वरित पहुंच।

परीक्षण

समुच्चय के लिए विनिर्देशन परीक्षण - "आदेश → अपेक्षित घटनाएं" परिदृश्य।

प्रक्षेपण परीक्षण: घटना प्रवाह फ़ीड करें और भौतिक स्थिति/सूचकांक की जाँच करें।

पुनरावृत्ति परीक्षण: स्टैंड पर खरोंच से अनुमानों का पुनर्निर्माण - सुनिश्चित करें कि परिणाम मेल खाता है।

अराजकता/विलंबता: देरी और लेता है, पहचान की जाँच करें।

डोमेन के उदाहरण

1) भुगतान

घटनाएँ: 'भुगतान। शुरू किया ',' भुगतान। अधिकृत ',' भुगतान। कैप्चर ',' भुगतान। वापस कर दिया '।

Invariants: आप 'अधिकृत' के बिना 'कैप्चर' नहीं कर सकते; मात्रा गैर-नकारात्मक हैं; मुद्रा अपरिवर्तित है।

अनुमान: "भुगतान कार्ड" (केवी), लेनदेन खोज (ओपनसर्च), रिपोर्टिंग (ओएलएपी)।

2) आदेश (ई-कॉमर्स)

घटनाएँ: 'क्रम। रखा ',' आदेश। भुगतान ',' आदेश। पैक ',' आदेश। भेज दिया ',' आदेश। वितरित '।

अपरिवर्तनीय: राज्य चार्ट स्थिति संक्रमण; 'शिप' से पहले रद्द करना संभव है।

अनुमान: उपयोगकर्ता आदेशों की सूची, स्थिति के अनुसार SLA बोर्ड।

3) बैलेंस शीट (वित्त/आईगेमिंग)

घटनाएँ: 'संतुलन। जमा ',' संतुलन। नामांकित ',' संतुलन। श्रेय ',' संतुलन। समायोजित '।

कठिन अपरिवर्तनीय: संतुलन दूर नहीं जाता है <0; कमांड 'operation _ id' हैं।

महत्वपूर्ण संचालन सीधे कुल (सख्त स्थिरता), यूआई से पढ़े जाते हैं - प्रक्षेपण (अंतिम) से।

विशिष्ट घटना भंडार संरचना (डीबी संस्करण)

घटनाएं

'event _ id (PK)', 'एग्रीगेट _ type', 'एग्रीगेट _ id', 'वर्जन', 'hease _ at', 'event _ type', 'पेलोड', 'मेटा'

सूचकांक: '(aggregate_type, aggregate_id, संस्करण)'।

स्नैपशॉट्स

'कुल _ प्रकार', 'कुल _ id', 'संस्करण', 'राज्य', 'निर्मित _ ate'

सूचकांक: '(aggregate_type, aggregate_id)'।

consumers_offsets

'consumer _ id', 'event _ id '/' पोजीशन', 'updated _ at' (अनुमानों और खुदरा के लिए)।

अक्सर पूछे जाने वाले प्रश्न (FAQs)

क्या हर जगह ईएस का उपयोग करना अनिवार्य है?

नहीं, यह नहीं है। ईएस उपयोगी है जब ऑडिटिंग, जटिल अपरिवर्तनीय, प्रजनन योग्यता और डेटा के विभिन्न अभ्यावेदन महत्वपूर्ण हैं। सरल CRUD के लिए, यह निरर्थक है।

"वर्तमान स्थिति" अनुरोध के बारे में क्या?

या तो प्रक्षेपण (जल्दी, अंतिम) से पढ़ें, या इकाई से (अधिक महंगा, लेकिन सख्ती से)। महत्वपूर्ण संचालन आमतौर पर दूसरे पथ का उपयोग

क्या मुझे काफ्का/स्ट्रीम ब्रोकर की जरूरत है?

घटना भंडार - सत्य का स्रोत; प्रोजेक्टर और बाहरी सिस्टम को घटनाओं को वितरित करने के लिए ब्रोकर सुविधाजनक है।

"भुलाए जाने का अधिकार" के साथ क्या करें?

PII को न्यूनतम करें, संवेदनशील क्षेत्रों को एन्क्रिप्ट करें और अनुमानों में क्रिप्टो इरेज़र/रिडेक्शन लागू करें।

मैं पुराने डेटा को कैसे पलायन करूं?

पूर्वव्यापी घटना पीढ़ी ("री-हाईस्टोरी") के लिए एक स्क्रिप्ट लिखें या "स्टेट-ए-आईएस" के साथ शुरू करें और केवल नए परिवर्तनों के लिए घटनाओं को प्रकाशित करें।

एंटीपैटर्न

इवेंट सोर्सिंग "आदत से बाहर": डोमेन लाभ के बिना सिस्टम को जटिल बनाता है।

वसा की घटनाएं: पीआईआई और डबल्स के साथ फूला हुआ पेलोड - ब्रेक और अनुपालन मुद्दे।

आशावादी संगति की कमी: रेसिंग के दौरान आक्रमणकारियों का नुकसान।

गैर-प्रजनन योग्य अनुमान: कोई रीप्ले/स्नैपशॉट नहीं - मैनुअल फिक्स।

डोमेन इवेंट के रूप में रॉ सीडीसी: लीक डीबी स्कीमा और हार्ड कनेक्टिविटी।

आंतरिक और एकीकरण घटनाओं को मिलाना: बाहर एक स्थिर "शोकेस" प्रकाशित करें।

उत्पादन जाँच सूची

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

कुल

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

Contact

हमसे संपर्क करें

किसी भी प्रश्न या सहायता के लिए हमसे संपर्क करें।हम हमेशा मदद के लिए तैयार हैं!

इंटीग्रेशन शुरू करें

Email — अनिवार्य है। Telegram या WhatsApp — वैकल्पिक हैं।

आपका नाम वैकल्पिक
Email वैकल्पिक
विषय वैकल्पिक
संदेश वैकल्पिक
Telegram वैकल्पिक
@
अगर आप Telegram डालते हैं — तो हम Email के साथ-साथ वहीं भी जवाब देंगे।
WhatsApp वैकल्पिक
फॉर्मैट: देश कोड और नंबर (उदा. +91XXXXXXXXXX)।

बटन दबाकर आप अपने डेटा की प्रोसेसिंग के लिए सहमति देते हैं।