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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सेवा चुनना

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

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

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

Cloud प्रोजेक्ट का लेआउट

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

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

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

सुरक्षा

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

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

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

अन्य जानकारी

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

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

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

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

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

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

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

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

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

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

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

योगदानकर्ता

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

मुख्य लेखक: