GH GambleHub

CQRS और पढ़ें/लिखें पृथक्करण

CQRS क्या है

CQRS (कमांड क्वेरी रिस्पॉन्सिबिलिटी सेग्रीगेशन) एक वास्तुशिल्प दृष्टिकोण है जो डेटा मॉडल और लेखन (कमांड) और पढ़ ने (क्वेरी) के लिए जिम्मेदार घटकों को अलग करता है।

विचार: राज्य परिवर्तन प्रक्रिया वैध अवैध और लेनदेन के लिए अनुकूलित है, और तेज, लक्षित अनुमानों और स्केलिंग के लिए पढ़ रहा है।

कुंजी> कमांड स्थिति बदलते हैं और ऑपरेशन का परिणाम लौटाते हैं। अनुरोध केवल पढ़े जाते हैं और कोई दुष्प्रभाव नहीं होते हैं।


आपको इसकी आवश्यकता क्यों है

प्रदर्शन पढ़ें: विशिष्ट परिदृश्यों (टेप, रिपोर्ट, कैटलॉग) के लिए भौतिक अनुमान।

महत्वपूर्ण पथ स्थिरता: "भारी" से अलग रिकॉर्डिंग और समुच्चय।

भंडारण चयन की स्वतंत्रता: लेखन के लिए OLTP, पढ़ ने के लिए OLAP/कैश/खोज इंजन।

त्वरित विकास: "ब्रेकिंग" लेनदेन के जोखिम के बिना नए विचार जोड़ें।

अवलोकन और ऑडिटिंग (विशेष रूप से इवेंट सोर्सिंग के साथ संयोजन में): राज्य को ठीक करना और फिर से भरना आसान है।


कब लागू करें (और कब नहीं)

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

बुनियादी अवधारणाएँ

कमांड-इरादा राज्य को बदलने का है ('CreateOrd', 'CaperPayMands')। अपरिवर्तनीय की जाँच करता है।

क्वेरी-रिट्रीव्स डेटा ('GetaryBYId', 'ListUersTransactions')। कोई दुष्प्रभाव नहीं।

रिकॉर्ड मॉडल: कुल/अपरिवर्तनीय/लेनदेन; भंडारण - संबंधपरक/कुंजी-मूल्य/घटना लॉग।

पढ़ें (प्रक्षेपण) मॉडल: भौतिक तालिकाओं/सूचकांक/कैश, तुल्यकालित अतुल्यकालिक रूप से।

स्थिरता: अक्सर रिकॉर्डिंग और पढ़ ने के बीच अंतिम; महत्वपूर्ण रास्ते - राइट मॉडल से सीधे पढ़ ने के माध्यम से।


वास्तुकला (कंकाल)

1. लेखन-सेवा: कमांड स्वीकार करता है, इनवेरिएंट को मान्य करता है, परिवर्तन (डेटाबेस या घटनाओं) को कैप्चर करता है।

2. आउटबॉक्स/सीडीसी: परिवर्तनों के तथ्य का गारंटीकृत प्रकाशन।

3. प्रोजेक्शन प्रोसेसर: घटनाओं/सीडीसी को सुनें और पढ़ ने के मॉडल को अपडेट करें।

4. रीड-सर्विस: भौतिक दृश्य/कैश/खोजों से प्रश्न परोसता है।

5. सागास/ऑर्केस्ट्रेशन: क्रॉस-एग्रीगेट प्रक्रियाओं का समन्वय करें।

6. अवलोकन: प्रक्षेपण अंतराल, सफल अनुप्रयोगों का प्रतिशत, डीएलक्यू।


रिकॉर्डिंग मॉडल डिजाइन करना

समुच्चय: स्पष्ट लेनदेन सीमाएं (उदाहरण के लिए, 'आदेश', 'भुगतान', 'UserBalk')।

इनवेरिएंट्स: औपचारिक (मौद्रिक मात्रा ≥ 0, विशिष्टता, सीमा)।

कमांड कुंजी द्वारा पहचाने जाते हैं (उदाहरण के लिए, 'idempotency _ key')।

लेनदेन न्यूनतम दायरे में हैं; बाहरी दुष्प्रभाव - आउटबॉक्स के माध्यम

कमांड उदाहरण (छद्म-JSON)

json
{
"command": "CapturePayment",
"payment_id": "pay_123",
"amount": 1000,
"currency": "EUR",
"idempotency_key": "k-789",
"trace_id": "t-abc"
}

रीडिंग मॉडल डिजाइन करना

प्रश्नों से शुरू करें: क्या स्क्रीन/रिपोर्ट की आवश्यकता है

Denormalization स्वीकार्य है: पढ़ें-मॉडल - "अनुकूलित कैश।"

विभिन्न कार्यों के लिए कई अनुमान: खोज (OpenSearch), रिपोर्ट (स्तंभ भंडारण), कार्ड (KV/Redis)।

TTL और reassembly: अनुमान स्रोत से पुनर्प्राप्त करने में सक्षम होना चाहिए (घटना रीप्ले/स्नैपशॉट)।


स्थिरता और UX

अंतिम स्थिरता: इंटरफ़ेस थोड़े समय के लिए पुराने डेटा प्रदर्शित कर सकता है।

UX पैटर्न: "डेटा अपडेट किया गया है...", आशावादी UI, सिंक्रनाइज़ेशन संकेतक, पुष्टि होने तक खतरनाक कार्यों को अवरुद्ध करना।

ऑपरेशन के लिए जिन्हें मजबूत स्थिरता की आवश्यकता होती है (उदाहरण के लिए, लिखने से पहले एक सटीक संतुलन दिखाना), सीधे लेखन मॉडल से


CQRS और इवेंट सोर्सिंग (वैकल्पिक)

इवेंट सोर्सिंग (ईएस) घटनाओं को संग्रहीत करता है, और कुल की स्थिति उनके दृढ़ संकल्प का परिणाम है।

CQRS + ES बंडल एक आदर्श ऑडिट और अनुमानों का आसान आश्वासन देता है, लेकिन जटिलता बढ़ाता है।

वैकल्पिक: नियमित OLTP डेटाबेस + आउटबॉक्स/CDC → अनुमान।


प्रतिकृति: आउटबॉक्स और सीडीसी

आउटबॉक्स (एक लेनदेन में): डोमेन बदलता है + आउटबॉक्स में किसी घटना को लिखना; प्रकाशक टायर को बचाता है।

सीडीसी: डेटाबेस लॉग (डेबेजियम, आदि) से पढ़ ना → डोमेन घटनाओं में परिवर्तन।

वारंटी: डिफ़ॉल्ट रूप से कम से कम एक बार, उपभोक्ताओं और अनुमानों को निष्क्रिय होना चाहिए।


भंडारण चयन

लिखें: लेनदेन के लिए संबंधपरक (PostgreSQL/MySQL); केवी/दस्तावेज़ - जहाँ अपरिवर्तनीय सरल हैं।

पढ़ें:
  • केवी/रेडिस - कार्ड और त्वरित कुंजी रीडिंग;
  • खोज (OpenSearch/Elasticsearch) - खोज/फ़िल्टर/पहलू;
  • कॉलम (क्लिकहाउस/BigQuery) - रिपोर्ट;
  • CDN - सार्वजनिक निर्देशिका/सामग्री पर कैश।

एकीकरण पैटर्न

एपीआई परत: 'कमांड' और 'क्वेरी' के लिए अलग-अलग एंडपॉइंट/सेवाएं।

पहचान: हेडर/शरीर में ऑपरेशन की कुंजी; टीटीएल के साथ हाल की-कुंजियों का भंडारण।

सागास/ऑर्केस्ट्रेशन: टाइमआउट, मुआवजा, कदम दोहराव।

Backpressure-प्रक्षेपण प्रोसेसर के समानतावाद को सीमित करता है।


अवलोकन क्षमता

मेट्रिक्स लिखें: p95/99 कमांड लेटेंसी, सफल लेनदेन का प्रतिशत, सत्यापन त्रुटियां।

मेट्रिक्स पढ़ें: p95/99 अनुरोध, हिट-रेट कैश, खोज क्लस्टर पर लोड करें।

प्रोजेक्शन लैग (समय और संदेश), डीएलक्यू दर, डीडुप्लीकेशन प्रतिशत।

ट्रेसिंग: 'trace _ id' → outbox कमांड → → query प्रक्षेपण के माध्यम से जाता है।


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

अधिकार पृथक्करण: लेखन और पढ़ ने के लिए विभिन्न स्कोप/भूमिकाएँ; कम से कम विशेषाधिकार का सिद्धांत।

पीआईआई/पीसीआई: अनुमानों में न्यूनतम करें; एट-रेस्ट/इन-फ्लाइट एन्क्रिप्शन; मास्किंग।

ऑडिट: फिक्स टीम, अभिनेता, परिणाम, 'ट्रेस _ आईडी'; महत्वपूर्ण डोमेन (भुगतान, केवाईसी) के लिए WORM अभिलेखागार।


परीक्षण

अनुबंध परीक्षण: कमांड (त्रुटियों, अपरिवर्तनीय) और प्रश्नों (प्रारूप/फिल्टर) के लिए।

प्रक्षेपण परीक्षण: घटनाओं/सीडीसी की एक श्रृंखला प्रस्तुत करें और अंतिम रीड मॉडल की जांच करें।

अराजकता/विलंबता: प्रक्षेपण प्रोसेसर में विलंबता को इंजेक्ट करना; UX अंतराल पर जाँच करें।

पुनरावृत्ति: स्नैपशॉट/लॉग से स्टैंड पर अनुमानों को फिर से जोड़ ना।


प्रवासन और विकास

नया क्षेत्र - घटना/सीडीसी में योज्य; रीड मॉडल का पुनर्निर्माण किया जा

सर्किट को नया स्वरूप देते समय डबल-राइट; स्विच करने तक पुराने अनुमानों को पकड़े रखें।

वर्शनिंग: 'v1 '/' v2' इवेंट्स और एंडपॉइंट्स, सनसेट-प्लान।

फ्लैग्स: कैनरी के साथ नए प्रश्नों/अनुमानों की शुरूआत।


एंटी-पैटर्न

CQRS "फैशन की खातिर" सरल CRUD सेवाओं में।

कठिन तुल्यकालिक पढ़ ने-लिखने की निर्भरता (अलगाव और दृढ़ ता को मारता है)।

सभी के लिए एक सूचकांक: एक रीड-स्टोर में विषम प्रश्नों को मिलाना।

अनुमानों में idempotency duplicates और विसंगतियाँ नहीं हैं।

गैर-वसूली योग्य अनुमान (कोई रीप्ले/स्नैपशॉट नहीं)।


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

भुगतान (ऑनलाइन सेवा)

लिखें: 'अधिकृत करें', 'कैप्चर', ट्रांजेक्शनल डेटाबेस में 'रिफंड'; आउटबॉक्स 'भुगतान प्रकाशित करता है '.

पढ़ें:
  • यूआई के लिए रेडिस "भुगतान कार्ड";
  • रिपोर्टिंग के लिए क्लिकहाउस;
  • लेनदेन खोजने के लिए ओपन सर्च।
  • महत्वपूर्ण पथ: प्राधिकरण ≤ 800 ms p95; UI के लिए स्थिरता पढ़ें - अंतिम (2-3 s तक)।

केवाईसी

लिखें: प्रारंभ/अद्यतन स्थिति के लिए कमांड; एक सुरक्षित डेटाबेस में पीआईआई भंडारण।

पढ़ें: पीआईआई के बिना स्टेटस का हल्का प्रक्षेपण; यदि आवश्यक हो तो पीआईआई को कड़ा किया जाता है।

सुरक्षा: पढ़ ने की स्थिति और दस्तावेजों तक पहुंचने पर विभिन्न स्

बैलेंस शीट (iGaming/Finance)

लिखें: 'UserBalk' परमाणु वेतन वृद्धि/कमी के साथ कुल; सर्जरी के लिए पहचान कुंजी।

पढ़ें: "त्वरित संतुलन" के लिए कैश; लिखने के लिए - लिखने से प्रत्यक्ष पढ़ ना (सख्त स्थिरता)।

सागा: जमा/निष्कर्ष घटनाओं द्वारा समन्वित होते हैं, विफलताओं के मामले में - मुआवजा।


कार्यान्वयन चेकलिस्ट

  • लेखन मॉडल के कुल और अपरिवर्तनीय को उजागर किया गया है।
  • प्रमुख प्रश्नों को परिभाषित किया गया है और उनके लिए अनुमान लगाए गए
  • आउटबॉक्स/सीडीसी और पहचान प्रक्षेपण प्रोसेसर कॉन्फ़िगर किए गए हैं।
  • एक स्नैपशॉट/रीप्ले योजना है।
  • SLO: कमांड लेटेंसी, प्रोजेक्शन लैग, पढ़ ने/लिखने की उपलब्धता अलग से।
  • अलग पहुंच अधिकार और डेटा एन्क्रिप्शन लागू किया गया।
  • DLQ अलर्ट/lag/deduplication विफलताएँ।
  • टेस्ट: अनुबंध, अनुमान, अराजकता, रिप्ले।

एफएक्यू

क्या CQRS के लिए इवेंट सोर्सिंग अनिवार्य है?

नहीं, यह नहीं है। आप एक नियमित डेटाबेस + आउटबॉक्स/सीडीसी पर निर्माण कर सकते हैं।

Desynchronization से कैसे निपटें?

स्पष्ट रूप से डिजाइन UX, प्रक्षेपण अंतराल को मापते हुए, महत्वपूर्ण संचालन को लिखने से पढ़ ने दें।

क्या एक ही सेवा में लिखना और पढ़ ना दोनों संभव है?

हां, भौतिक अलगाव वैकल्पिक है; जिम्मेदारियों का तार्किक विभाजन अनिवार्य है।

समुच्चय के बीच लेनदेन के बारे में क्या?

सागा और घटनाओं के माध्यम से; यदि संभव हो तो वितरित लेन - देन से बचें।


परिणाम

CQRS हाथों को एकजुट करता है: स्पष्ट अपरिवर्तनों और तेजी के साथ एक पतला, विश्वसनीय लेखन पथ, लक्षित भौतिक अनुमानों से पढ़ ता है। यह उत्पादकता को बढ़ाता है, विकास को सरल बनाता है, और सिस्टम को तनाव के लिए अधिक लचीला बनाता है - यदि स्थिरता, अवलोकन और पलायन अनुशासित हैं।

Contact

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

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

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

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

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

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