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

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

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

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

सेवा चुनना

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

मुख्य लेखक: