फ़्लीट इंजन और फ़्लीट इवेंट रेफ़रंस सलूशन की मदद से, करीब-करीब रीयल-टाइम इवेंट जनरेट करें

ज़मीन पर काम करने वाले फ़्लीट से मिलने वाले रीयल टाइम के आस-पास के सिग्नल, कारोबारों के लिए कई तरह से फ़ायदेमंद होते हैं. उदाहरण के लिए, कारोबार इनका इस्तेमाल इन कामों के लिए कर सकते हैं:

  • अपने फ़्लीट की परफ़ॉर्मेंस को मॉनिटर करना और संभावित समस्याओं का पहले से पता लगाना
  • सटीक ईटीए और ट्रैकिंग की जानकारी देकर, ग्राहक सेवा को बेहतर बनाएं
  • कमियों का पता लगाकर उन्हें ठीक करके लागत कम करना
  • ड्राइवर के व्यवहार पर नज़र रखकर और संभावित खतरों की पहचान करके, सुरक्षा को बेहतर बनाएं
  • ड्राइवर के रास्तों और शेड्यूल को ऑप्टिमाइज़ करके, बेहतर नतीजे पाएं
  • वाहन की जगह की जानकारी और सेवा के घंटों को ट्रैक करके, नियमों का पालन करना

इस दस्तावेज़ में बताया गया है कि डेवलपर, Google Maps Platform के "मोबिलिटी सेवाएं" ("लास्ट माइल फ्लीट सलूशन" (एलएमएफ़एस) या "मांग पर राइड और डिलीवरी की सेवाएं देने वाला सलूशन" (ओडीआरडी) से मिलने वाले सिग्नल को कार्रवाई किए जा सकने वाले कस्टम इवेंट में कैसे बदल सकते हैं. इसमें GitHub पर उपलब्ध फ़्लीट इवेंट के रेफ़रंस सॉल्यूशन के मुख्य कॉन्सेप्ट और डिज़ाइन से जुड़े फ़ैसलों के बारे में भी बताया गया है.

यह दस्तावेज़ इनके लिए काम का है:

  • आर्किटेक्ट को Google Maps Platform की "मोबिलिटी सेवाएं" और इसके मुख्य कॉम्पोनेंट "Fleet Engine" के बारे में जानकारी होनी चाहिए. अगर आपने "मोबिलिटी सेवाएं" का इस्तेमाल पहले कभी नहीं किया है, तो हमारा सुझाव है कि आप अपनी ज़रूरतों के हिसाब से, लास्ट माइल फ्लीट सलूशन और/या मांग पर राइड और डिलीवरी की सुविधा देने वाला सलूशन के बारे में जान लें.
  • Google Cloud के बारे में जानकारी रखने वाले आर्किटेक्ट. Google Cloud का इस्तेमाल पहली बार करने वाले लोगों के लिए, Google Cloud पर स्ट्रीमिंग डेटा पाइपलाइन बनाना लेख को पहले से पढ़ लेना फ़ायदेमंद होगा.
  • अगर आपको अन्य एनवायरमेंट या सॉफ़्टवेयर स्टैक को टारगेट करना है, तो Fleet Engine के इंटिग्रेशन पॉइंट और ज़रूरी बातों को समझें. ये बातें अब भी लागू होनी चाहिए.
  • जिन लोगों को यह जानने में दिलचस्पी है कि फ़्लीट से इवेंट कैसे जनरेट किए जा सकते हैं और उनका इस्तेमाल कैसे किया जा सकता है.

इस दस्तावेज़ को पढ़ने के बाद, आपको स्ट्रीमिंग सिस्टम के मुख्य एलिमेंट और ज़रूरी बातों के बारे में बुनियादी जानकारी मिल जाएगी. साथ ही, आपको Google Maps Platform और Google Cloud के उन बिल्डिंग ब्लॉक के बारे में भी पता चल जाएगा जिनसे फ़्लीट इवेंट रेफ़रंस सलूशन बनता है.

फ़्लीट इवेंट के रेफ़रंस समाधान की खास जानकारी

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

यह समाधान कार्यों या यात्राओं से जुड़े विशिष्ट डेटा में परिवर्तन के आधार पर स्वचालित रूप से ईवेंट उत्पन्न करता है. इन इवेंट का इस्तेमाल करके, हितधारकों को सूचनाएं भेजी जा सकती हैं. जैसे, यहां दी गई सूचनाएं. इसके अलावा, अपने फ़्लीट के लिए अन्य कार्रवाइयां भी ट्रिगर की जा सकती हैं.

  • कार्य आगमन के लिए ETA परिवर्तन
  • कार्य आगमन के लिए सापेक्ष ETA परिवर्तन
  • कार्य आगमन तक शेष समय
  • टास्क के लिए तय की गई जगह तक पहुंचने में बची हुई दूरी
  • कार्य परिणाम स्थिति परिवर्तन

रेफ़रंस समाधान के हर कॉम्पोनेंट को, अपने कारोबार की ज़रूरतों के हिसाब से बनाया जा सकता है.

लॉजिकल बिल्डिंग ब्लॉक

आरेख : निम्नलिखित आरेख उच्च स्तरीय बिल्डिंग ब्लॉक्स दिखाता है जो फ़्लीट इवेंट्स संदर्भ समाधान बनाते हैं

फ़्लीट इवेंट की खास जानकारी और लॉजिकल बिल्डिंग ब्लॉक

संदर्भ समाधान में निम्नलिखित घटक शामिल हैं:

  • इवेंट का सोर्स: ओरिजनल इवेंट स्ट्रीम कहां से आती है. "लास्ट माइल फ्लीट सलूशन" या "मांग पर राइड और डिलीवरी की सुविधा देने वाला सलूशन", दोनों को Cloud Logging के साथ इंटिग्रेट किया जा सकता है. इससे, Fleet Engine के आरपीसी कॉल के लॉग को इवेंट स्ट्रीम में बदला जा सकता है. ये इवेंट स्ट्रीम, डेवलपर के लिए उपलब्ध होती हैं. यह उपभोग का मुख्य स्रोत है.
  • प्रसंस्करण: कच्चे RPC कॉल लॉग को इस ब्लॉक के भीतर स्थिति परिवर्तन ईवेंट में परिवर्तित किया जाता है, जो लॉग ईवेंट की एक स्ट्रीम पर गणना करता है. ऐसे परिवर्तन का पता लगाने के लिए, इस घटक को एक स्टेट स्टोर की आवश्यकता होती है, ताकि परिवर्तन का पता लगाने के लिए नई आने वाली घटनाओं की तुलना पिछली घटनाओं से की जा सके. आयोजनों में हमेशा रुचि की सभी जानकारी शामिल नहीं हो सकती. ऐसे मामलों में, यह ब्लॉक ज़रूरत के मुताबिक बैकएंड को लुकअप कॉल कर सकता है.
    • स्टेट स्टोर: कुछ प्रोसेसिंग फ़्रेमवर्क, इंटरमीडिएट डेटा को अपने-आप सेव करते हैं. लेकिन यदि नहीं, तो अपनी ओर से स्थिति को संग्रहीत करने के लिए, चूंकि ये वाहन और घटना प्रकार के लिए अद्वितीय होनी चाहिए, एक केवी प्रकार डेटा दृढ़ता सेवा एक अच्छा विकल्प है.
  • सिंक (कस्टम इवेंट): बदलाव की जानकारी का पता चलने पर, इसे ऐसे सभी ऐप्लिकेशन या सेवाओं के लिए उपलब्ध कराया जाना चाहिए जिन्हें इससे फ़ायदा मिल सकता है. इसलिए, इस कस्टम इवेंट को इवेंट डिलीवरी सिस्टम में पब्लिश करना एक स्वाभाविक विकल्प है, ताकि इसका इस्तेमाल डाउनस्ट्रीम में किया जा सके.
  • डाउनस्ट्रीम सेवा: यह ऐसा कोड होता है जो जनरेट किए गए इवेंट का इस्तेमाल करता है और आपके इस्तेमाल के उदाहरण के हिसाब से कार्रवाइयां करता है.

सेवा चुनना

"लास्ट माइल फ्लीट सलूशन" या "मांग के हिसाब से राइड और डिलीवरी की सुविधा देने वाला सलूशन" (तीसरी तिमाही के आखिर में उपलब्ध होगा) के लिए, रेफ़रंस सलूशन लागू करते समय, "सोर्स" और "सिंक '' के लिए टेक्नोलॉजी चुनना आसान है. वहीं दूसरी ओर, "प्रोसेस जारी है" में कई विकल्प उपलब्ध हैं. रेफ़रंस समाधान के लिए, Google की इन सेवाओं को चुना गया है.

डायग्राम : इस डायग्राम में, रेफ़रंस समाधान को लागू करने के लिए Google Cloud सेवा दिखाई गई है

फ़्लीट इवेंट के रेफ़रंस समाधान बनाने के लिए बिल्डिंग ब्लॉक

Cloud Project का लेआउट

हमारा सुझाव है कि आप डिफ़ॉल्ट रूप से, एक से ज़्यादा प्रोजेक्ट में डिप्लॉयमेंट करें. ऐसा इसलिए किया जाता है, ताकि Google Maps Platform और Google Cloud के इस्तेमाल को अलग-अलग किया जा सके. साथ ही, इसे अपनी पसंद के बिलिंग सिस्टम से जोड़ा जा सके.

इवेंट का सोर्स

"लास्ट माइल फ्लीट सॉल्यूशन" और "ऑन-डिमांड राइड और डिलीवरी सॉल्यूशन" एपीआई अनुरोध और जवाब के पेलोड को Cloud Logging में लिखते हैं. Cloud Logging, लॉग को आपकी पसंद की एक या उससे ज़्यादा सेवाओं तक पहुंचाता है. यहां Cloud Pub/Sub पर रूट करना सबसे सही विकल्प है. इससे कोडिंग के बिना, लॉग को इवेंट स्ट्रीम में बदला जा सकता है.

सिंक

Google Cloud में, Cloud Pub/Sub को मैसेज डिलीवर करने के लिए, लगभग रीयल टाइम में काम करने वाले सिस्टम के तौर पर चुना जाता है. जिस तरह सोर्स से इवेंट, Pub/Sub को डिलीवर किए जाते थे उसी तरह कस्टम इवेंट भी Pub/Sub को पब्लिश किए जाते हैं, ताकि उन्हें डाउनस्ट्रीम में इस्तेमाल किया जा सके.

प्रोसेस जारी है

इवेंट प्रोसेसिंग में इन कॉम्पोनेंट की भूमिका होती है. अन्य बिल्डिंग ब्लॉक की तरह, प्रोसेसिंग कॉम्पोनेंट पूरी तरह से सर्वरलेस होते हैं. साथ ही, ये अप और डाउन, दोनों तरह से अच्छी तरह से स्केल होते हैं.

  • शुरुआती रिलीज़ (*) के लिए, कंप्यूट प्लैटफ़ॉर्म के तौर पर Cloud Functions का इस्तेमाल किया गया है
    • सर्वरलेस, लागत को मैनेज करने के लिए स्केलिंग कंट्रोल के साथ अप और डाउन होता है
    • प्रोग्रामिंग भाषा के तौर पर Java का इस्तेमाल किया जाता है. ऐसा इसलिए, क्योंकि Fleet Engine से जुड़े एपीआई के लिए क्लाइंट लाइब्रेरी उपलब्ध हैं. इससे लागू करने में आसानी होती है
  • स्टेट स्टोर के तौर पर Cloud Firestore का इस्तेमाल करना
    • सर्वर के बिना कुंजी-वैल्यू स्टोर
  • अपस्ट्रीम और डाउनस्ट्रीम कॉम्पोनेंट के साथ इंटिग्रेशन पॉइंट के तौर पर Cloud Pub/Sub का इस्तेमाल करें
    • करीब-करीब रीयल-टाइम में इंटिग्रेशन की सुविधा

इन फ़ंक्शन का इस्तेमाल डिफ़ॉल्ट सेटिंग के साथ किया जा सकता है. हालांकि, इन्हें फिर से कॉन्फ़िगर भी किया जा सकता है. कॉन्फ़िगरेशन पैरामीटर, डिप्लॉयमेंट स्क्रिप्ट के ज़रिए सेट किए जाते हैं. साथ ही, इनकी पूरी जानकारी संबंधित टेराफ़ॉर्म मॉड्यूल के README में दी गई होती है.

*ध्यान दें: इस रेफ़रंस समाधान में, लागू करने के ऐसे अन्य तरीके रिलीज़ करने का प्लान है जो अलग-अलग ज़रूरी शर्तों को पूरा करने में मदद कर सकते हैं.

डिप्लॉयमेंट

रेफ़रंस समाधान को बार-बार डिप्लॉय करने, उसे पसंद के मुताबिक बनाने, सोर्स कोड को कंट्रोल करने, और सुरक्षित बनाने के लिए, Terraform को ऑटोमेशन टूल के तौर पर चुना गया है. Terraform, IaC (Infrastructure as Code) का एक ऐसा टूल है जिसका इस्तेमाल बड़े पैमाने पर किया जाता है. यह Google Cloud के साथ काम करता है.

Terraform मॉड्यूल

एक बड़ा मोनोलिथिक रेफ़रंस सॉल्यूशन डिप्लॉयमेंट मॉड्यूल बनाने के बजाय, ऑटोमेशन के फिर से इस्तेमाल किए जा सकने वाले ब्लॉक को Terraform मॉड्यूल के तौर पर लागू किया जाता है. इनका इस्तेमाल अलग-अलग किया जा सकता है. मॉड्यूल में कॉन्फ़िगर किए जा सकने वाले कई वैरिएबल होते हैं. इनमें से ज़्यादातर की डिफ़ॉल्ट वैल्यू होती हैं, ताकि आप तुरंत शुरू कर सकें. हालांकि, आपके पास अपनी ज़रूरतों और प्राथमिकताओं के हिसाब से इन्हें पसंद के मुताबिक बनाने का विकल्प भी होता है.

रेफ़रंस समाधान में शामिल मॉड्यूल:

  • Fleet Engine के लिए लॉगिंग कॉन्फ़िगरेशन: Fleet Engine के साथ इस्तेमाल करने के लिए, Cloud Logging से जुड़े कॉन्फ़िगरेशन को अपने-आप लागू करें. रेफ़रंस समाधान में, इसका इस्तेमाल Fleet Engine से जुड़े लॉग को Pub/Sub के किसी विषय पर भेजने के लिए किया जाता है.
  • फ़्लीट इवेंट के लिए क्लाउड फ़ंक्शन डिप्लॉयमेंट: इसमें फ़ंक्शन के कोड का सैंपल डिप्लॉयमेंट शामिल होता है. साथ ही, यह सुरक्षित क्रॉस-प्रोजेक्ट इंटिग्रेशन के लिए ज़रूरी अनुमति सेटिंग के ऑटोमेशन को भी मैनेज करता है.
  • पूरे रेफ़रंस समाधान को डिप्लॉय करना: यह पिछले दो मॉड्यूल को कॉल करता है और पूरे समाधान को रैप करता है.

सुरक्षा

आईएएम का इस्तेमाल, कम से कम विशेषाधिकार के सिद्धांत लागू करने के लिए किया जाता है. साथ ही, Google Cloud के सुरक्षा से जुड़े सबसे सही तरीके भी लागू किए जाते हैं. जैसे, सेवा खाते के तौर पर काम करना. Google Cloud, सुरक्षा पर ज़्यादा कंट्रोल पाने के लिए आपको क्या-क्या ऑफ़र करता है, इस बारे में बेहतर तरीके से जानने के लिए, यहां दिए गए लेख पढ़ें.

अगली कार्रवाइयां

अब आपके पास फ़्लीट इवेंट रेफ़रंस सॉल्यूशन को ऐक्सेस करने और इसके बारे में ज़्यादा जानने का विकल्प है. शुरू करने के लिए, GitHub पर जाएं.

अपेंडिक्स

अपनी ज़रूरतें इकट्ठा करना

हमारा सुझाव है कि आप प्रोसेस की शुरुआत में ही अपनी ज़रूरतें पूरी कर लें.

सबसे पहले, इस बारे में जानकारी दें कि आपको रीयल टाइम के आस-पास होने वाले इवेंट का इस्तेमाल क्यों करना है. यहाँ कुछ सवाल दिए गए हैं, जिनसे आपको अपनी ज़रूरतों के बारे में साफ़ तौर पर पता चल पाएगा.

  • किसी इवेंट स्ट्रीम के काम की होने के लिए, कौनसी जानकारी ज़रूरी है?
    • क्या नतीजे सिर्फ़ Google की सेवाओं में कैप्चर या जनरेट किए गए डेटा से निकाले जा सकते हैं? या, क्या इंटिग्रेट किए गए बाहरी सिस्टम से डेटा को बेहतर बनाने की ज़रूरत है? अगर हां, तो वे सिस्टम कौनसे हैं और वे कौनसे इंटिग्रेशन इंटरफ़ेस उपलब्ध कराते हैं?
    • कारोबार के तौर पर, आपको कौनसी मेट्रिक मेज़र करनी हैं? इन्हें कैसे तय किया जाता है?
    • यदि आपको विभिन्न घटनाओं के लिए मीट्रिक्स की गणना करनी हो, तो इसके लिए किस प्रकार के एकत्रीकरण की आवश्यकता होगी? तार्किक चरणों को रेखांकित करने का प्रयास करें. (उदा. संसाधन बाधाओं के तहत प्रदर्शन की गणना करने के लिए व्यस्ततम घंटों के दौरान बेड़े के एक उप-भाग में SLOs के विरुद्ध ETA/ATA की तुलना करें.)
  • आपको बैच के बजाय इवेंट पर आधारित मॉडल में दिलचस्पी क्यों है? क्या यह कम समय में कार्रवाई करने के लिए है या यह एक ढीला-ढाला इंटिग्रेशन (तेज़ी से काम करने वाला) है?
    • अगर कम समय में डेटा ट्रांसफ़र करना है, तो "low" तय करें. मिनट? सेकंड? क्या एक सेकंड से कम समय में जवाब चाहिए? और कितनी लेटेंसी है?
  • क्या आपकी टीम ने टेक्नोलॉजी स्टैक और उससे जुड़ी स्किल्स में पहले ही निवेश कर दिया है? अगर हां, तो यह क्या है और यह कौनसे इंटिग्रेशन पॉइंट उपलब्ध कराता है?
    • क्या ऐसी कोई ज़रूरी शर्त है जिसे आपके मौजूदा सिस्टम पूरा नहीं कर सकते या आपकी फ्लीट से आने वाले इवेंट को प्रोसेस करने में उन्हें समस्या हो सकती है?

डिज़ाइन से जुड़े सिद्धांत

किसी भी काम को करने से पहले, उसके बारे में सोच-विचार करना हमेशा फ़ायदेमंद होता है. इससे सुसंगत डिजाइन निर्णय लेने में मदद मिलती है, खासकर तब जब आपके पास चुनने के लिए कई विकल्प हों.

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

स्ट्रीमिंग के कॉन्सेप्ट

अगर आपने हाल ही में इवेंट पर आधारित या स्ट्रीमिंग शुरू की है, तो आपको कुछ ज़रूरी कॉन्सेप्ट के बारे में पता होना चाहिए. इनमें से कुछ कॉन्सेप्ट, बैच प्रोसेसिंग से काफ़ी अलग हो सकते हैं.

  • स्केल : बैच प्रोसेसिंग के विपरीत, जहां आपको आमतौर पर प्रोसेस किए जाने वाले डेटा की मात्रा का अच्छा अंदाजा होता है, स्ट्रीमिंग में आपको ऐसा नहीं पता होता. किसी शहर में अचानक से ट्रैफ़िक जाम होने की वजह से, उस इलाके से कई इवेंट जनरेट हो सकते हैं. ऐसे में, आपको उन इवेंट को प्रोसेस करना होगा.
  • विंडोइंग : इवेंट को एक-एक करके प्रोसेस करने के बजाय, अक्सर ऐसा होता है कि आपको किसी टाइमलाइन पर मौजूद इवेंट को छोटे "विंडो" में ग्रुप करना होता है, ताकि उन्हें एक यूनिट के तौर पर कैलकुलेट किया जा सके. विंडोइंग की कई रणनीतियां होती हैं. जैसे, "तय की गई विंडो (जैसे, हर कैलेंडर दिन)", "स्लाइडिंग विंडो (पिछले पांच मिनट)", "सेशन विंडो (इस यात्रा के दौरान)". आपको इनमें से किसी एक को चुनना चाहिए. विंडो जितनी लंबी होगी, नतीजे मिलने में उतना ही ज़्यादा समय लगेगा. अपनी ज़रूरतों के हिसाब से सही मॉडल और कॉन्फ़िगरेशन चुनें.
  • ट्रिगर करना : कुछ मामलों में, आपके पास लंबे समय तक चलने वाले सेशन के अलावा कोई और विकल्प नहीं होता. हालांकि, आपको इवेंट जनरेट करने के लिए विंडो के आखिर तक इंतज़ार नहीं करना चाहिए. इसके बजाय, बीच-बीच में इंटरमीडिएट नतीजे दिखाने चाहिए. इस कॉन्सेप्ट को उन मामलों में लागू किया जा सकता है जहां तुरंत नतीजे पाने की ज़रूरत होती है. ऐसे में, पहले तुरंत नतीजे दिखाए जाते हैं और बाद में उन्हें ठीक किया जाता है. मान लें कि डिलीवरी के 25%, 50%, और 75% पूरे होने पर, इंटरमीडिएट स्टेटस दिखाया जाता है.
  • क्रम : ज़रूरी नहीं है कि इवेंट, सिस्टम में उसी क्रम में पहुंचें जिस क्रम में उन्हें जनरेट किया गया था. खास तौर पर, मोबाइल नेटवर्क पर कम्यूनिकेशन से जुड़े इस्तेमाल के उदाहरणों के लिए. इससे देरी होती है और राउटिंग के पाथ मुश्किल हो जाते हैं. आपको "इवेंट का समय" (जब इवेंट असल में हुआ) और "प्रोसेस करने का समय" (जब इवेंट सिस्टम तक पहुंचा) के बीच के अंतर के बारे में पता होना चाहिए. साथ ही, इवेंट को इसी हिसाब से मैनेज करना चाहिए. आम तौर पर, आपको "event time" के आधार पर इवेंट प्रोसेस करने होते हैं.
  • मैसेज डिलीवरी - कम से कम एक बार बनाम ठीक एक बार: अलग-अलग इवेंट प्लैटफ़ॉर्म पर, इन दोनों के लिए अलग-अलग सपोर्ट उपलब्ध है. इस्तेमाल के उदाहरण के आधार पर, आपको फिर से कोशिश करने या डुप्लीकेट डेटा हटाने की रणनीतियों पर विचार करना होगा.
  • पूरा होना : क्रम बदलने की तरह ही, मैसेज के गायब होने की संभावना होती है. ऐसा इन वजहों से हो सकता है: डिवाइस की बैटरी खत्म होने की वजह से ऐप्लिकेशन और डिवाइस बंद हो गया हो, फ़ोन को गलती से नुकसान पहुंचा हो, सुरंग में कनेक्टिविटी न होने की वजह से मैसेज नहीं मिला हो या मैसेज मिला हो, लेकिन उसे स्वीकार करने की समयसीमा खत्म हो गई हो. जानकारी पूरी न होने से, आपके नतीजों पर क्या असर पड़ेगा?

यह पूरी सूची नहीं है, बल्कि सिर्फ़ एक झलक है. यहां कुछ ऐसे लेख दिए गए हैं जिन्हें पढ़ने का सुझाव दिया जाता है. इनसे आपको हर विषय के बारे में ज़्यादा जानकारी मिल सकती है.

योगदानकर्ता

Google इस दस्तावेज़ को मैनेज करता है. इस लेख को इन लोगों ने लिखा है.

मुख्य लेखक: