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

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

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

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

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

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

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

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

फ़्लीट इवेंट रेफ़रंस सॉल्यूशन, ओपन सोर्स वाला एक समाधान है. इसकी मदद से, मोबिलिटी से जुड़े ग्राहक और पार्टनर, Fleet Engine और Google Cloud कॉम्पोनेंट के आधार पर मुख्य इवेंट जनरेट कर सकते हैं. फ़िलहाल, यह रेफ़रंस सॉल्यूशन उन ग्राहकों के लिए उपलब्ध है जो Last Mile Fleet Solution का इस्तेमाल करते हैं. इसमें मांग के हिसाब से राइड और डिलीवरी की सुविधा भी शामिल है.

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

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

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

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

डायग्राम : इस डायग्राम में, फ़्लीट इवेंट के रेफ़रंस समाधान को बनाने वाले बिल्डिंग ब्लॉक के बारे में बताया गया है

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

रेफ़रंस समाधान में ये कॉम्पोनेंट शामिल होते हैं:

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

सेवा चुनना

"लास्ट माइल फ्लीट सलूशन" या "मांग पर राइड और डिलीवरी की सुविधा देने वाला सलूशन" (तीसरी तिमाही 2023 के आखिर में उपलब्ध होगा) के लिए, रेफ़रंस सलूशन लागू करते समय, "सोर्स" और "सिंक '' के लिए टेक्नोलॉजी चुनना आसान है. वहीं दूसरी ओर, "प्रोसेस जारी है" में कई विकल्प मौजूद हैं. रेफ़रंस समाधान के लिए, 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 का इस्तेमाल करें
    • करीब-करीब रीयल-टाइम में इंटिग्रेशन की सुविधा

इन फ़ंक्शन का इस्तेमाल डिफ़ॉल्ट सेटिंग के साथ किया जा सकता है. हालांकि, इन्हें फिर से कॉन्फ़िगर भी किया जा सकता है. कॉन्फ़िगरेशन पैरामीटर, डिप्लॉयमेंट स्क्रिप्ट के ज़रिए सेट किए जाते हैं. साथ ही, इनके बारे में पूरी जानकारी, संबंधित Terraform मॉड्यूल के 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 की सेवाओं में कैप्चर या जनरेट किए गए डेटा से निकाले जा सकते हैं? या, क्या इंटिग्रेट किए गए बाहरी सिस्टम से डेटा को बेहतर बनाने की ज़रूरत है? अगर हां, तो वे सिस्टम कौनसे हैं और वे कौनसे इंटिग्रेशन इंटरफ़ेस उपलब्ध कराते हैं?
    • कारोबार के तौर पर, आपको कौनसी मेट्रिक मेज़र करनी हैं? इन्हें कैसे तय किया जाता है?
    • अगर आपको अलग-अलग इवेंट के लिए मेट्रिक का हिसाब लगाना है, तो इसके लिए किस तरह के एग्रीगेशन की ज़रूरत होगी? लॉजिकल चरणों को लेआउट करने की कोशिश करें. (उदा. पीक आवर के दौरान, बेड़े के किसी सबसेट के लिए एसएलओ के हिसाब से ईटीए/एटीए की तुलना करें, ताकि संसाधनों की कमी के बावजूद परफ़ॉर्मेंस का आकलन किया जा सके.)
  • आपको बैच के बजाय इवेंट पर आधारित मॉडल में दिलचस्पी क्यों है? क्या यह कम समय में कार्रवाई करने के लिए है या यह एक सामान्य इंटिग्रेशन (तेज़ी से काम करने वाला) के लिए है?
    • अगर कम समय में डेटा ट्रांसफ़र करना है, तो "low" तय करें. मिनट? सेकंड? क्या एक सेकंड से कम समय में जवाब चाहिए? और कितनी लेटेंसी है?
  • क्या आपकी टीम ने टेक्नोलॉजी स्टैक और उससे जुड़ी स्किल में पहले ही निवेश कर दिया है? अगर हां, तो यह क्या है और यह कौनसे इंटिग्रेशन पॉइंट उपलब्ध कराता है?
    • क्या ऐसी कोई ज़रूरी शर्त है जिसे आपके मौजूदा सिस्टम पूरा नहीं कर सकते या आपकी फ्लीट से आने वाले इवेंट को प्रोसेस करते समय उन्हें समस्या हो सकती है?

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

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

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

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

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

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

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

योगदानकर्ता

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

मुख्य लेखक: