Order pipelines
Orders billing, shipping और analytics तक पहुँचते हैं, और हर एक उसी stream को अपनी गति से पढ़ता है।
कोर डेटाबैकग्राउंड काम
Consumer Groups के साथ Event Streaming
Consumer groups, acknowledgements और crash हुए consumer के छोड़े संदेशों की अपने आप recovery वाली append-only event streams।
- append-only log
- Durable
- consumer groups प्रति stream
- N
- crash पर खोए संदेश
- 0
कदम 1 में से 5
Event publish करें
Order service एक event append करती है और उसकी id वापस पाती है।
उदाहरण सेशनplaying
# Event publish करें
hotkv> XADD orders * type created order 1182 total 49.00
"1790985600123-0"
असली HotKV कमांड और उदाहरण रिस्पॉन्स के साथ एक एनिमेटेड वॉकथ्रू। किसी भी कदम पर क्लिक करके वहां पहुंचें। कमांड और रिस्पॉन्स अंग्रेज़ी में ही रहते हैं, ठीक वैसे जैसे आप HotKV में टाइप करते और देखते हैं।
समस्या
Events पर प्रतिक्रिया देने वाली सेवाओं को queue से ज़्यादा चाहिए। कई स्वतंत्र consumers वही events चाहते हैं, हर consumer group को instances में काम बाँटना होता है, और जब कोई instance संदेश हाथ में लिए मर जाता है तो किसी को यह देखकर उन्हें अपने हाथ में लेना होता है।
HotKV इसे कैसे संभालता है
Stream एक append-only log है। हर consumer group उसे स्वतंत्र रूप से पढ़ता है, हर संदेश group के एक सदस्य को देता है, और जब तक सदस्य acknowledge न करे, उसे pending रखता है। XAUTOCLAIM बहुत देर से pending संदेशों को किसी स्वस्थ consumer को सौंप देता है।
कदम दर कदम
क्या होता है, कमांड दर कमांड
- 01
Event publish करें
Order service एक event append करती है और उसकी id वापस पाती है।
XADD orders * type created order 1182 total 49.00 - 02
दो groups, एक stream
Billing और shipping का अपना-अपना group है और दोनों को event मिलता है।
XGROUP CREATE orders billing 0 MKSTREAM - 03
Consume करें
Billing का एक instance अपने group के नए संदेश पढ़ता है, कुछ आने तक रुकते हुए।
XREADGROUP GROUP billing billing-1 COUNT 10 BLOCK 5000 STREAMS orders > - 04
Acknowledge करें
Invoice बनते ही billing acknowledge करता है और संदेश उसकी pending सूची से निकल जाता है।
XACK orders billing 1790985600123-0 - 05
Crash से recover करें
Shipping का एक instance संदेश पकड़े हुए मर गया। 60 सेकंड idle रहने के बाद उन्हें एक स्वस्थ instance अपने हाथ में ले लेता है।
XAUTOCLAIM orders shipping shipping-2 60000 0-0 COUNT 25
कहां फ़िट बैठता है
असली परिदृश्य
Audit और activity feeds
User की कार्रवाइयाँ stream में append होती हैं और जिस भी सेवा को history चाहिए वह उन्हें replay कर सकती है।
IoT ingestion
Device के संदेश streams में buffer होते हैं और workers का एक group उन्हें प्रोसेस करता है, जो load के साथ scale होता है।
अंतर्निहित
आपको क्या मिलता है
Append-only log
Entries को समय के क्रम वाली ids मिलती हैं और उन्हें लंबाई या उम्र के हिसाब से trim किया जा सकता है।
XADDXTRIMConsumer groups
हर group को हर संदेश मिलता है, और वह काम को अपने सदस्यों में बाँटता है।
XGROUPXREADGROUPAcknowledgements
संदेश acknowledge होने तक pending रहते हैं।
XACKXPENDINGअपने आप recovery
बहुत देर से idle संदेशों को कोई दूसरा consumer अपने हाथ में ले लेता है।
XAUTOCLAIMXCLAIMआम सवाल
क्या मैं पुराने events replay कर सकता हूँ?
हाँ। XRANGE stream के किसी भी हिस्से को id से पढ़ता है, और नया consumer group शुरुआत से शुरू हो सकता है।
Stream को हमेशा बढ़ते रहने से कैसे रोकूँ?
उसे XTRIM से, या XADD के MAXLEN या MINID विकल्प से trim करें।
क्या XADD duplicate events से बच सकता है?
XADD idempotent producer ids (IDMP) को सपोर्ट करता है, इसलिए दोबारा की गई publish दूसरी entry नहीं बनाती। XADD संदर्भ देखें।
संबंधित उपयोग के मामले
इसे अपने वर्कलोड पर आज़माएं
HotKV Redis प्रोटोकॉल बोलता है, इसलिए आप किसी मौजूदा क्लाइंट को इसकी ओर इंगित करके यही कमांड चला सकते हैं।