मैं घटना स्ट्रीमिंग/भंडारण/कफका जैसे प्रसंस्करण से खरगोश एमक्यू जैसे मैसेजिंग इंफ्रास्ट्रक्चर को अलग करने के साथ शुरू करूंगा। ये दो अलग-अलग उद्देश्यों के लिए दो अलग-अलग उद्देश्यों के लिए बनाई गई हैं।
घटना सोर्सिंग के बारे में, आपको एक ऐसा स्थान होना चाहिए जहां आपको ईवेंट स्टोर करना होगा। यह संग्रहण केवल संलग्न होना चाहिए और पहचान के आधार पर असंगठित डेटा के तेज़ी से पढ़ने का समर्थन करना चाहिए। इस तरह के दृढ़ता का एक उदाहरण EventStore है।
इवेंट सोर्सिंग सीक्यूआरएस के साथ मिलकर जाता है, जिसका अर्थ है कि आपको अपने परिवर्तन (ईवेंट) को किसी अन्य स्टोर में प्रोजेक्ट करना होगा, जिसे आप पूछ सकते हैं। यह उस स्टोर को ईवेंट पेश करके किया जाता है, यह वह जगह है जहां डोमेन ऑब्जेक्ट स्थिति को बदलने के लिए ईवेंट संसाधित होते हैं।यह समझना महत्वपूर्ण है कि अनुमानों के लिए संदेश आधारभूत संरचना का उपयोग करना आम तौर पर एक बुरा विचार है। यह संदेश की प्रकृति और दो चरण प्रतिबद्धता के कारण है।
यदि आप देखते हैं कि ईवेंट कैसे बने रहते हैं, तो आप देख सकते हैं कि वे स्टोर में एक लेनदेन के रूप में सहेजे जाते हैं। यदि आपको घटनाओं को प्रकाशित करने की आवश्यकता है, तो यह एक और लेनदेन होगा। चूंकि आप बुनियादी ढांचे के दो अलग-अलग टुकड़ों से निपट रहे हैं, चीजें तोड़ सकती हैं।
संदेश समस्या यह है कि संदेश आमतौर पर "कम से कम एक बार" वितरित होने की गारंटी दी जाती है और संदेशों का क्रम आमतौर पर गारंटी नहीं देता है। साथ ही, जब आपका संदेश उपभोक्ता विफल रहता है और संदेश को नाक करता है, तो इसे फिर से वितरित किया जाएगा लेकिन आमतौर पर थोड़ी देर बाद, अनुक्रम को तोड़ दिया जाएगा।
ऑर्डरिंग और डुप्लिकेशन चिंताएं, जो भी, कफका जैसे ईवेंट स्ट्रीमिंग सर्वर पर लागू नहीं होती हैं। साथ ही, यदि आप कैच-अप सदस्यता का उपयोग करते हैं तो इवेंटस्टोर केवल एक बार ईवेंट डिलीवरी की गारंटी देगा।
मेरे अनुभव में, संदेशों को कमांड भेजने और स्वतंत्र सेवाओं को एक प्रतिक्रियाशील तरीके से जोड़ने के लिए ईवेंट संचालित आर्किटेक्चर को लागू करने के लिए उपयोग किया जाता है। दूसरी तरफ, इवेंट स्टोर्स का इस्तेमाल घटनाओं को जारी रखने के लिए किया जाता है और केवल उन घटनाओं को प्राप्त किया जाता है जिन्हें वहां क्वेरी स्टोर में पेश किया जाता है और संदेश बस में भी प्रकाशित किया जाता है।
स्रोत
2016-12-15 14:47:41
धन्यवाद एलेक्सी, यहां त्वरित प्रश्न: यह कैसे है "ऑर्डरिंग और डुप्लिकेशंस चिंताओं, जो भी, कफका जैसे ईवेंट स्ट्रीमिंग सर्वर पर लागू नहीं होते हैं"? यदि आपके समवर्ती ग्राहक हैं तो आप अनिवार्य रूप से आउट-ऑफ-ऑर्डर समस्याएं शुरू करते हैं यदि वे समवर्ती ग्राहक एक दूसरे पर निर्भर हैं, इसलिए विशिष्ट ऐप के व्यावसायिक नियमों के आधार पर उनमें से कुछ कस्टम सिंक्रनाइज़ेशन लागू किए जाने चाहिए। क्या मेरी समझ सही है? – IlliakaillI
मुझे व्यक्तिगत रूप से काफ्का के साथ कोई अनुभव नहीं है, लेकिन मैंने डीडीडीयू 2016 पर मार्टिन क्लेप्पमान की बात देखी है https://dddeurope.com/2016/martin-kleppmann.html जहां वह बताते हैं कि जब उन्होंने कफका तैयार किया तो वे सख्त घटना आदेश के लिए लक्षित थे। मुझे यह भी पता है कि इवेंटस्टोर कैच/अप सदस्यता का उपयोग करते समय ईवेंट ऑर्डर की गारंटी देता है। अनिवार्य रूप से यह गारंटी तब टूट जाती है जब आप अपने ईवेंट स्ट्रीम पर प्रतिस्पर्धी उपभोक्ताओं को सेट करते हैं, आदेश देने की गारंटी के लिए आप वहां कुछ भी नहीं कर सकते हैं। असीमित प्रक्रिया भी आदेश तोड़ देगा। –
मैं देखता हूं। मैं पूछ रहा हूं क्योंकि किसी भी एचए सिस्टम में आपको प्रतिस्पर्धा करने वाले उपभोक्ताओं को गलती सहनशीलता के लिए प्रतिस्पर्धा करना पड़ता है, और ऐसा लगता है कि ऐसे सिस्टम के लिए ऑर्डर स्थितियों को स्वचालित रूप से संभालने के लिए कोई तंत्र नहीं है। – IlliakaillI