Hangfire से RabbitMQ तक: डेटाबेस पोलिंग (Polling) को खत्म करना
Hangfire छोटी टीमों के लिए बेहतरीन है। आप बस एक NuGet पैकेज जोड़ते हैं और उसे अपने डेटाबेस से जोड़ देते हैं। आपको मुफ्त में एक जॉब रनर और एक डैशबोर्ड मिल जाता है। एक सिंगल सर्विस के लिए, इससे बेहतर कुछ मिलना मुश्किल है।
मैंने SavePosty में ईमेल, वेबहुक्स (webhooks) और कंटेंट फेचिंग (content fetching) को संभालने के लिए Hangfire का उपयोग किया था। हर जॉब एक ही तरह से काम करती थी। वे सभी नए काम की जांच करने के लिए हर कुछ सेकंड में मेरे Postgres डेटाबेस को पोल (poll) करते थे।
अंततः मैंने सब कुछ RabbitMQ पर स्थानांतरित कर दिया। यहाँ बताया गया है कि मैंने ऐसा क्यों किया और मैंने क्या खोया।
क्यों मैं स्थानांतरित हुआ:
- पोलिंग लोड काम के साथ नहीं, बल्कि समय के साथ बढ़ता है। हर Hangfire जॉब एक टाइमर के आधार पर आपके डेटाबेस को हिट करती है। भले ही कोई काम न हो, डेटाबेस व्यस्त रहता है। यह लागत आपके जॉब काउंट और पोलिंग फ्रीक्वेंसी के साथ बढ़ती जाती है।
- बहुत सारे मॉडल्स। मेरे ऐप का एक हिस्सा पहले से ही RabbitMQ का उपयोग कर रहा था। बाकी हिस्सा Hangfire का उपयोग करता था। इसका मतलब था बैकग्राउंड वर्क को मैनेज करने के दो अलग-अलग तरीके। RabbitMQ पर जाने से सब कुछ एक समान (unified) हो गया।
- लेटेंसी (Latency)। एक ब्रोकर काम आते ही उसे पुश कर देता है। Hangfire अगले पोल का इंतज़ार करता है।
ट्रेड-ऑफ (Trade-offs):
Hangfire को सेटअप करना आसान है। यह आपके मौजूदा SQL टेबल्स का उपयोग करता है। इसमें एक बेहतरीन इन-बिल्ट डैशबोर्ड है।
RabbitMQ के लिए एक ब्रोकर को मैनेज करने की आवश्यकता होती है। यह डेटाबेस CPU के बजाय RAM और नेटवर्क का उपयोग करता है। आपको बेहतर स्केलिंग मिलती है, लेकिन ऑपरेशनल ओवरहेड (operational overhead) भी बढ़ जाता है।
मैंने सुरक्षित रूप से माइग्रेशन कैसे किया:
मैंने अपने बिजनेस लॉजिक को बिल्कुल वैसा ही रखा। मैंने 'थिन कंज्यूमर्स' (thin consumers) बनाए जो फ्रंट डोर की तरह काम करते हैं। कंज्यूमर मैसेज प्राप्त करता है और उसे मौजूदा जॉब क्लास को सौंप देता है।
मैंने दो चीजों पर ध्यान केंद्रित किया:
- रिट्राय पैरिटी (Retry parity)। मैंने RabbitMQ कंज्यूमर में Hangfire की रिट्राय सेटिंग्स से मेल खाया ताकि मैं मैसेज न खोऊं।
- स्कीमा सेफ्टी (Schema safety)। मैंने पुराने कॉलम्स को 'नलेबल' (nullable) रखा ताकि डिप्लॉयमेंट के दौरान डेटाबेस खराब न हो।
मैंने क्या खोया:
सबसे बड़ी कमी विजिबिलिटी (visibility) की है। Hangfire आपको एक फेल हुई जॉब पर क्लिक करने और यह देखने की अनुमति देता है कि वास्तव में क्या हुआ था। RabbitMQ आपको दिखाता है कि डेड लेटर क्यू (Dead Letter Queue) में कितने मैसेज हैं, लेकिन यह आपको प्रति-जॉब (per-job) वैसा आसान व्यू नहीं देता। अब मैं डैशबोर्ड के बजाय स्ट्रक्चर्ड लॉग्स (structured logs) पर निर्भर हूँ।
मेरी सलाह:
Hangfire पर ही रहें यदि:
- आप एक सिंगल सर्विस चलाते हैं।
- आपकी टीम छोटी है।
- आपको डिबगिंग के लिए एक आसान डैशबोर्ड की आवश्यकता है।
RabbitMQ पर जाएँ यदि:
- आपकी कई सर्विसेज हैं।
- पोलिंग के कारण आपके डेटाबेस पर लोड अधिक है।
- आप pub/sub पैटर्न का उपयोग करना चाहते हैं।
निर्णय आपके सिस्टम पर निर्भर करता है, न कि किसी एक जॉब पर।
Source: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4
Optional learning community: https://t.me/GyaanSetuAi