स्ट्रीमिंग डेटा प्राप्त करना

स्ट्रीमिंग डेटा का उपभोग करने के लिए Client बनाना

स्ट्रीमिंग एंडपॉइंट का उपयोग करते समय, उपयोग को बेहतर बनाने के लिए कुछ सामान्य सर्वोत्तम प्रथाओं को ध्यान में रखना चाहिए।    

Client डिज़ाइन

फ़िल्टर स्ट्रीम एंडपॉइंट के साथ समाधान बनाते समय, आपको ऐसे Client की ज़रूरत होगी जो निम्नलिखित कार्य कर सके:

1. फ़िल्टर स्ट्रीम एंडपॉइंट के लिए HTTPS स्ट्रीमिंग कनेक्शन स्थापित करे।
2. स्ट्रीम में नियम जोड़ने और हटाने के लिए फ़िल्टर स्ट्रीम नियम एंडपॉइंट पर असमकालिक रूप से POST अनुरोध भेजे।
3. कम डेटा वॉल्यूम को संभाले – स्ट्रीमिंग कनेक्शन बनाए रखे, पोस्ट ऑब्जेक्ट और keep-alive सिग्नलों का पता लगाए।
4. अधिक डेटा वॉल्यूम को संभाले – असमकालिक प्रक्रियाओं का उपयोग करके स्ट्रीम इनजेशन को अतिरिक्त प्रोसेसिंग से अलग करे, और यह सुनिश्चित करे कि Client-साइड बफ़र नियमित रूप से फ्लश किए जाएँ।
5. Client-साइड पर वॉल्यूम खपत ट्रैकिंग का प्रबंधन करे।
6. स्ट्रीम डिस्कनेक्शन का पता लगाए, उनका आकलन करे, और स्ट्रीम से अपने-आप फिर से कनेक्ट हो जाए।  

स्ट्रीमिंग एंडपॉइंट से कनेक्ट करना

X API v2 के स्ट्रीमिंग एंडपॉइंट्स से कनेक्शन स्थापित करने का मतलब है बहुत लंबे समय तक चलने वाला HTTP अनुरोध करना और रिस्पॉन्स को क्रमिक रूप से पार्स करना। वैचारिक रूप से, आप इसे HTTP पर अनंत लंबी फ़ाइल डाउनलोड करने जैसा समझ सकते हैं।  एक बार कनेक्शन स्थापित हो जाने पर, जब तक कनेक्शन खुला रहता है, X सर्वर उसी कनेक्शन के माध्यम से पोस्ट इवेंट्स भेजता रहेगा।  

डेटा ग्रहण करना

ध्यान दें कि JSON ऑब्जेक्ट्स के अलग-अलग फ़ील्ड्स किसी निश्चित क्रम में नहीं होते, और हर स्थिति में सभी फ़ील्ड्स मौजूद नहीं होंगे। इसी तरह, अलग-अलग गतिविधियाँ क्रमबद्ध तरीके से डिलीवर नहीं की जातीं, और डुप्लिकेट संदेश भी मिल सकते हैं। यह भी ध्यान रखें कि समय के साथ नए संदेश type जोड़े जा सकते हैं और स्ट्रीम के माध्यम से भेजे जा सकते हैं।

इसलिए, आपके Client को निम्न स्थितियों को संभालने में सक्षम होना चाहिए:

• किसी भी क्रम में आने वाले फ़ील्ड्स
• अप्रत्याशित या अनुपस्थित फ़ील्ड्स
• अक्रमबद्ध पोस्ट्स
• डुप्लिकेट संदेश
• किसी भी समय स्ट्रीम से आने वाले नए मनमाने संदेश type

प्रासंगिक पोस्ट डेटा और अनुरोधित फ़ील्ड पैरामीटर्स के अलावा, स्ट्रीम कनेक्शन पर निम्न प्रकार के संदेश डिलीवर किए जा सकते हैं। ध्यान दें कि यह सूची पूरी नहीं भी हो सकती—स्ट्रीम्स में अतिरिक्त ऑब्जेक्ट्स जोड़े जा सकते हैं। सुनिश्चित करें कि आपका parser अप्रत्याशित संदेश प्रारूपों को संभाल सके।  

बफ़रिंग

स्ट्रीमिंग एंडपॉइंट्स डेटा उपलब्ध होते ही उसे आपको जितनी जल्दी संभव हो, भेज देते हैं। इसके कारण कई मामलों में डेटा की मात्रा बहुत अधिक हो सकती है। अगर X सर्वर तुरंत स्ट्रीम में नया डेटा नहीं लिख पाता है (उदाहरण के लिए, अगर आपका Client पर्याप्त तेज़ी से नहीं पढ़ रहा है; अधिक जानकारी के लिए डिस्कनेक्शन को संभालना देखें), तो वह आपके Client को पकड़ने का मौका देने के लिए अपनी ओर से कॉन्टेंट को बफ़र करता है। हालांकि, जब यह बफ़र भर जाता है, तो कनेक्शन बंद करने के लिए एक फ़ोर्स्ड डिस्कनेक्ट शुरू किया जाता है, और बफ़र की गई पोस्ट्स हटा दी जाती हैं तथा दोबारा नहीं भेजी जातीं। अधिक जानकारी के लिए नीचे देखें।

यह पहचानने का एक तरीका कि आपका ऐप कब पीछे रह रहा है, यह है कि प्राप्त हो रही पोस्ट्स के टाइमस्टैम्प की तुलना मौजूदा समय से करें और समय के साथ इस अंतर को ट्रैक करें।

हालांकि सार्वजनिक इंटरनेट पर संभावित लेटेंसी और रुकावटों के कारण स्ट्रीम बैकअप को पूरी तरह समाप्त नहीं किया जा सकता, लेकिन आपके ऐप के सही कॉन्फ़िगरेशन से इन्हें काफी हद तक कम किया जा सकता है। बैकअप की घटनाओं को कम करने के लिए:

• सुनिश्चित करें कि आपका Client स्ट्रीम को पर्याप्त तेज़ी से पढ़ रहा है। आमतौर पर, स्ट्रीम पढ़ते समय आपको कोई वास्तविक प्रोसेसिंग कार्य नहीं करना चाहिए। स्ट्रीम को पढ़ें और उस गतिविधि को प्रोसेसिंग के लिए किसी दूसरे थ्रेड/प्रोसेस/डेटा स्टोर को सौंप दें, ताकि यह काम असिंक्रोनस रूप से हो सके।
• सुनिश्चित करें कि आपके डेटा सेंटर में बड़े और लगातार डेटा वॉल्यूम के साथ-साथ उससे कहीं अधिक बड़े स्पाइक्स (जैसे सामान्य वॉल्यूम का 5-10x) को संभालने के लिए पर्याप्त इनबाउंड बैंडविड्थ हो। फ़िल्टर्ड स्ट्रीम के लिए, आपकी ओर आवश्यक वॉल्यूम और उससे संबंधित बैंडविड्थ पूरी तरह इस बात पर निर्भर करती है कि आपके नियम किन पोस्ट्स से मैच हो रहे हैं।  

उपयोग ट्रैकिंग और नियम प्रबंधन

डेवलपर्स की अपने स्ट्रीम्स के लिए “सामान्य” डेटा वॉल्यूम के बारे में अपेक्षाएँ अलग-अलग हो सकती हैं, इसलिए किसी विशिष्ट प्रतिशत कमी/बढ़ोतरी या समयावधि के लिए हमारी कोई सामान्य अनुशंसा नहीं है। 

अपने स्ट्रीम डेटा वॉल्यूम में अप्रत्याशित उतार-चढ़ाव की निगरानी करने पर विचार करें। डेटा वॉल्यूम में कमी, स्ट्रीम डिसकनेक्शन से अलग किसी समस्या का संकेत हो सकती है। ऐसी स्थिति में, स्ट्रीम को अभी भी keep-alive signal और संभवतः कुछ नया activity data मिल रहा होगा। हालांकि, पोस्ट्स की संख्या में उल्लेखनीय कमी होने पर आपको यह जांचना चाहिए कि कहीं आपके application या network में inbound data volume कम होने का कोई कारण तो नहीं है, और किसी संबंधित सूचना के लिए status page देखें।

ऐसी निगरानी लागू करने के लिए, आप एक निश्चित समयावधि में अपेक्षित नए पोस्ट्स की संख्या को ट्रैक कर सकते हैं। यदि किसी स्ट्रीम का डेटा वॉल्यूम निर्धारित threshold से काफी नीचे गिर जाता है और तय समयावधि के भीतर सामान्य स्तर पर वापस नहीं आता, तो alerts और notifications शुरू हो जाने चाहिए। आप डेटा वॉल्यूम में बड़ी बढ़ोतरी की निगरानी भी करना चाह सकते हैं, खासकर यदि आप filtered स्ट्रीम में नियम संशोधित कर रहे हों, या यदि कोई ऐसी घटना हो जिससे पोस्ट activity में उछाल आए।

यह ध्यान रखना महत्वपूर्ण है कि filtered स्ट्रीम के माध्यम से डिलीवर किए गए पोस्ट्स कुल मासिक पोस्ट वॉल्यूम में गिने जाते हैं, इसलिए अनुकूलन के लिए आपको अपने उपयोग को ट्रैक और समायोजित करना चाहिए।  यदि वॉल्यूम अधिक है, तो आवश्यकता पड़ने पर 100% matching को घटाकर sample:50 या sample:25 करने के लिए अपने प्रत्येक नियम में sample: operator जोड़ने पर विचार करें।

इसके अतिरिक्त, हम आपको प्रोत्साहित करते हैं कि आप अपने ऐप के भीतर ऐसे उपाय लागू करें जो वॉल्यूम के पहले से निर्धारित threshold को पार करने पर आपकी टीम को अलर्ट करें, और संभव हो तो अन्य उपाय भी अपनाएँ, जैसे ऐसे नियमों को अपने-आप हटाना जो बहुत अधिक डेटा ला रहे हों, या अत्यधिक परिस्थितियों में स्ट्रीम से पूरी तरह disconnect हो जाना।  

सिस्टम संदेशों का जवाब देना

Keep-alive संकेत कम से कम हर 20 सेकंड में, स्ट्रीम आपके Client का timeout होने से रोकने के लिए खुला कनेक्शन बनाए रखते हुए \r\n carriage return के रूप में एक keep-alive संकेत, या heartbeat, भेजेगी। आपके Client ऐप्लिकेशन को स्ट्रीम में आने वाले \r\n वर्णों को संभालने में सक्षम होना चाहिए।

अगर आपका Client अपनी HTTP लाइब्रेरी में read timeout को सही तरीके से implement करता है, तो आपका ऐप इस बात के लिए HTTP protocol और अपनी HTTP लाइब्रेरी पर भरोसा कर सकेगा कि इस अवधि के भीतर कोई डेटा न पढ़े जाने पर वह event throw करे, और आपको \r\n वर्ण की अलग से निगरानी करने की आवश्यकता नहीं होगी।

यह event आम तौर पर exception throw होने या उपयोग की गई HTTP लाइब्रेरी के आधार पर किसी अन्य event के रूप में होगा। इन timeout का पता लगाने के लिए अपने HTTP methods को error/event handlers के साथ wrap करना बहुत अधिक अनुशंसित है। timeout होने पर, आपके ऐप्लिकेशन को फिर से connect करने का प्रयास करना चाहिए।

त्रुटि संदेश v2 streaming एंडपॉइंट्स स्ट्रीम के भीतर त्रुटि संदेश भी भेज सकते हैं। नीचे इन संदेशों का मूल प्रारूप दिया गया है, साथ ही कुछ उदाहरण भी दिए गए हैं। कृपया ध्यान दें कि भेजे जाने वाले संदेश बदल सकते हैं और नए संदेश जोड़े जा सकते हैं। Client ऐप्लिकेशन को बदलते सिस्टम संदेश payloads को संभालने में सक्षम होना चाहिए।

ध्यान दें कि त्रुटि संदेश उस दस्तावेज़ीकरण का लिंक देंगे जिसमें बताया गया होगा कि समस्या का समाधान कैसे किया जाए।

संदेश प्रारूप:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "This stream has been disconnected upstream for operational reasons.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

ध्यान दें कि पूर्ण बफ़र के कारण फ़ोर्स डिस्कनेक्ट का संकेत देने वाले त्रुटि संदेश शायद कभी आपके Client तक न पहुँचें, यदि फ़ोर्स डिस्कनेक्ट का कारण बना बैकअप ही उन्हें पहुँचने से रोक दे। इसलिए, आपके ऐप को फिर से कनेक्ट शुरू करने के लिए इन संदेशों पर निर्भर नहीं होना चाहिए.