मुख्य सामग्री पर जाएं

परिचय

स्ट्रीमिंग डेटा का उपयोग करते समय, अपने कनेक्शन समय को अधिकतम रखना और सभी मेल खाने वाला डेटा प्राप्त करना एक बुनियादी लक्ष्य होता है। इसका मतलब है कि रिडंडेंट कनेक्शनों का लाभ उठाना, डिस्कनेक्शन का अपने-आप पता लगाना, जल्दी से फिर से कनेक्ट होना, और खोए हुए डेटा को रिकवर करने की योजना होना महत्वपूर्ण है। इस इंटीग्रेशन गाइड में, हम रिकवरी और रिडंडेंसी से जुड़ी अलग-अलग सुविधाओं पर चर्चा करेंगे: रिडंडेंट कनेक्शन, बैकफिल, और रिकवरी। रिडंडेंट कनेक्शन रिडंडेंट कनेक्शन आपको फ़िल्टर्ड स्ट्रीम से एक से अधिक समकालिक कनेक्शन स्थापित करने की सुविधा देता है। इससे रिडंडेंसी मिलती है, क्योंकि आप दो अलग-अलग कंज़्यूमर के साथ एक ही स्ट्रीम से कनेक्ट हो सकते हैं और दोनों कनेक्शनों पर एक ही डेटा प्राप्त कर सकते हैं। इस तरह, अगर एक स्ट्रीम डिस्कनेक्ट हो जाए या आपके एप्लिकेशन का प्राइमरी सर्वर विफल हो जाए, तो आपके ऐप के पास ऐसे अलग-अलग परिदृश्यों के लिए हॉट फेलओवर उपलब्ध होता है। फ़िल्टर्ड स्ट्रीम में वर्तमान में केवल Enterprise access वाले Projects को अधिकतम दो रिडंडेंट कनेक्शनों तक कनेक्ट होने की अनुमति है। रिडंडेंट स्ट्रीम का उपयोग करने के लिए, बस उसी URL से कनेक्ट करें जिसका उपयोग आपके प्राइमरी कनेक्शन के लिए किया जाता है। आपकी स्ट्रीम का डेटा दोनों कनेक्शनों के माध्यम से भेजा जाएगा।

डिसकनेक्शन के बाद छूटा हुआ डेटा पुनर्प्राप्त करना: Backfill

डिसकनेक्शन का पता चलने के बाद, आपका सिस्टम इतना सक्षम होना चाहिए कि वह स्ट्रीम से फिर से कनेक्ट हो सके। यदि संभव हो, तो आपके सिस्टम को यह भी रिकॉर्ड करना चाहिए कि डिसकनेक्शन कितनी देर तक रहा, ताकि डेटा को backfill करने के लिए आप सही recovery सुविधा का उपयोग कर सकें।  यदि आप Enterprise access वाले किसी Project का उपयोग कर रहे हैं और आपने यह निर्धारित किया है कि डिसकनेक्शन पाँच मिनट या उससे कम समय तक रहा, तो आप backfill पैरामीटर, backfill_minutes, का उपयोग कर सकते हैं। यदि आप इस पैरामीटर को अपने GET /tweets/search/stream अनुरोध के साथ भेजते हैं, तो आपको पिछले एक से पाँच मिनट के भीतर आपकी rules से मेल खाने वाले पोस्ट्स प्राप्त होंगे। आम तौर पर, हम नए मेल खाने वाले पोस्ट्स से पहले ये पुराने पोस्ट्स भेजते हैं, और पोस्ट्स को deduplicate भी नहीं करते। इसका मतलब है कि यदि आपका कनेक्शन 90 सेकंड के लिए टूटा था, लेकिन आप दो मिनट के backfill डेटा का अनुरोध करते हैं, तो आपको 30 सेकंड के duplicate पोस्ट्स प्राप्त होंगे, जिन्हें संभालने में आपका सिस्टम सक्षम होना चाहिए। यहाँ एक उदाहरण है कि backfill पैरामीटर के साथ अनुरोध कैसा दिख सकता है: curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN" यदि आपके पास Enterprise access नहीं है, या आपने यह निर्धारित किया है कि डिसकनेक्शन पाँच मिनट से अधिक समय तक रहा, तो आप छूटा हुआ डेटा अनुरोध करने के लिए recent search endpoint या recovery सुविधा का उपयोग कर सकते हैं। हालाँकि, ध्यान दें कि search पोस्ट्स endpoints में sample:, bio:, bio_name:, या bio_location: operators शामिल नहीं होते, और keyword तथा #hashtag operators के साथ accents और diacritics का उपयोग करने पर इनके matching behavior में कुछ अंतर होते हैं। इन अंतरों का मतलब यह हो सकता है कि filtered stream endpoints के माध्यम से प्राप्त होने वाले सभी पोस्ट्स आप पूरी तरह पुनर्प्राप्त न कर पाएँ।  डिसकनेक्शन के बाद छूटा हुआ डेटा पुनर्प्राप्त करना: रिकवरी यदि आप Enterprise access वाले किसी Project का उपयोग कर रहे हैं, तो 5 मिनट की backfill window में फिर से कनेक्ट न कर पाने की स्थिति में आप पिछले 24 घंटों के भीतर का छूटा हुआ डेटा पुनर्प्राप्त करने के लिए रिकवरी सुविधा का उपयोग कर सकते हैं। स्ट्रीमिंग recovery सुविधा आपको 24 घंटे की विस्तारित backfill window देती है। रिकवरी आपको छूटे हुए डेटा की समयावधि को ‘replay’ करने में सक्षम बनाती है। recovery stream तब शुरू होती है, जब आप ‘start_time’ और ‘end_time’ request parameters का उपयोग करके कनेक्शन अनुरोध करते हैं। कनेक्ट होने के बाद, रिकवरी बताई गई समयावधि को फिर से स्ट्रीम करेगी और फिर डिस्कनेक्ट हो जाएगी।   आप एक ही समय में recovery के लिए 2 concurrent requests कर सकते हैं, यानी “two recovery jobs”। तकनीकी रूप से रिकवरी उसी तरह काम करती है जैसे backfill, बस इसमें start और end time निर्धारित होते हैं। एक recovery period एक ही time range के लिए होता है।
नामTypeविवरण
start_timedate (ISO 8601)YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339).

UTC में तिथि, जो उस आरंभ समय को दर्शाती है जहाँ से पुनर्प्राप्ति करनी है।
end_timedate (ISO 8601)YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339).

UTC में तिथि, जो उस समाप्ति समय को दर्शाती है जहाँ तक पुनर्प्राप्ति करनी है।
उदाहरण अनुरोध URL: https://api.x.com/2/tweets/search/stream?start_time=2022-07-12T15:10:00Z&end_time=2022-07-12T15:20:00Z