रीट्रीज़ के साथ HTTP अनुरोधों को स्टोर और अग्रेषित करें?

Question

ट्विलियो और अन्य HTTP संचालित वेब सेवाओं में fallback URL की अवधारणा है, जहां मुख्य URL समय समाप्त होने या अन्यथा विफल होने पर वेब सेवाएं आपकी पसंद के यूआरएल पर एक जीईटी या पोस्ट भेजती हैं। ट्विलियो के मामले में, अगर फॉलबैक यूआरएल भी विफल रहता है तो वे अनुरोध का पुनः प्रयास नहीं करेंगे। मैं फॉलबैक यूआरएल को एक अलग मशीन पर होस्ट करना चाहता हूं ताकि प्राथमिक सर्वर नीचे या पहुंच योग्य होने पर त्रुटि ईथर में खो न जाए।

मैं माध्यमिक के लिए किसी तरह करना चाहते हैं: फ़ॉलबैक URL को

1. स्टोर अनुरोध
2. खेलना प्राथमिक सर्वर पर एक अलग यूआरएल के लिए अनुरोध
3. पुन: प्रयास करें # 2 सफलता तक , फिर कतार/डेटाबेस से अनुरोध हटाएं

क्या सॉफ्टवेयर का कुछ मौजूदा टुकड़ा है जो यह कर सकता है? यदि आवश्यकता हो तो मैं खुद को कुछ बना सकता हूं, मुझे लगा कि यह ऐसा कुछ होगा जो किसी ने पहले ही किया होगा। मैं खोजने के लिए सही buzzword जानने के लिए HTTP और आसपास के उपकरण (प्रॉक्सी, रिवर्स प्रॉक्सी, आदि) के साथ पर्याप्त परिचित नहीं हूँ।

Answer 1

कुछ संभावनाएं हैं।

एक विकल्प सामान्य पता रिडंडेंसी प्रोटोकॉल या कार्प का उपयोग करना है। मैन पेज से संक्षिप्त विवरण निम्नानुसार है।

"कार्प एक ही स्थानीय नेटवर्क पर कई होस्टों को आईपी पते का एक सेट साझा करने की अनुमति देता है। इसका प्राथमिक उद्देश्य यह सुनिश्चित करना है कि ये पते हमेशा उपलब्ध हों, लेकिन कुछ कॉन्फ़िगरेशन में कार्प लोड संतुलन कार्यक्षमता भी प्रदान कर सकता है।"

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

दूसरा विकल्प nginx का उपयोग करना है। यह संभवतः आप जो करने की कोशिश कर रहे हैं उसके लिए उपयुक्त है।

कई साल पहले मुझे ऐसा करने की कोशिश करने के समान कुछ चाहिए था और मैंने कुछ ऐसा करने के साथ हैकिंग समाप्त कर दी। अनिवार्य रूप से यह एक स्विच था। जब 'ए' विफल रहता है, तो 'बी' पर स्विच करें। री-सिंक प्रक्रिया 'बी' से समयबद्ध मुद्रित लॉग लेना था और उन्हें 'ए' वापस खेलना था, एक बार 'ए' वापस ऑनलाइन था।