Hangfire कडून RabbitMQ कडे: डेटाबेस पोलिंग थांबवणे

लहान टीमसाठी Hangfire उत्तम आहे. तुम्ही एक NuGet package जोडून ते तुमच्या डेटाबेसकडे वळवू शकता. तुम्हाला मोफत जॉब रनर आणि डॅशबोर्ड मिळतो. एका सिंगल सर्व्हिससाठी, याला हरवणे कठीण आहे.

मी SavePosty मध्ये ईमेल, webhooks आणि कंटेंट फेचिंग (content fetching) हाताळण्यासाठी Hangfire वापरले होते. प्रत्येक जॉब एकाच पद्धतीने काम करत असे. नवीन कामाची तपासणी करण्यासाठी ते सर्व काही काही सेकंदांनी माझ्या Postgres डेटाबेसचे पोलिंग (polling) करत असत.

शेवटी मी सर्व काही RabbitMQ वर हलवले. मी असे का केले आणि त्यातून काय गमावले, याची माहिती खालीलप्रमाणे आहे.

मी स्थलांतर का केले:

• पोलिंगचा लोड कामावर नाही तर वेळेवर अवलंबून असतो. प्रत्येक Hangfire जॉब एका ठराविक वेळेनंतर तुमच्या डेटाबेसवर हिट करतो. जरी कोणतेही काम नसेल, तरीही डेटाबेस व्यस्त राहतो. जॉबची संख्या आणि पोलिंगची वारंवारता वाढल्यास हा खर्चही वाढत जातो.
• खूप जास्त मॉडेल्स. माझ्या ॲपचा एक भाग आधीच RabbitMQ वापरत होता, तर बाकीचा भाग Hangfire वापरत होता. याचा अर्थ बॅकग्राउंड वर्क मॅनेज करण्यासाठी दोन वेगवेगळ्या पद्धती होत्या. RabbitMQ वर स्थलांतरित झाल्यामुळे सर्व काही एकसमान झाले.
• लॅटन्सी (Latency). ब्रोकर (broker) काम आल्याबरोबर ते पुश करतो. Hangfire पुढच्या पोलिंगची वाट पाहते.

फायदे आणि तोटे (Trade-offs):

Hangfire सेटअप करणे सोपे आहे. ते तुमच्या सध्याच्या SQL टेबल्सचा वापर करते. यामध्ये एक उत्तम इन-बिल्ट डॅशबोर्ड आहे.

RabbitMQ साठी ब्रोकर मॅनेज करावा लागतो. ते डेटाबेस CPU ऐवजी RAM आणि नेटवर्कचा वापर करते. तुम्हाला उत्तम स्केलिंग मिळते, परंतु ऑपरेशनल ओव्हरहेड (operational overhead) वाढते.

मी सुरक्षितपणे स्थलांतर कसे केले:

मी माझे बिझनेस लॉजिक (business logic) तंतोतंत तसेच ठेवले. मी 'थिन कन्स्युमर्स' (thin consumers) तयार केले जे फ्रंट डोअरसारखे काम करतात. कन्स्युमर मेसेज प्राप्त करतो आणि तो अस्तित्वात असलेल्या जॉब क्लासकडे सोपवतो.

मी दोन गोष्टींवर लक्ष केंद्रित केले:

• Retry parity. मी RabbitMQ कन्स्युमरमध्ये Hangfire च्या retry settings शी सुसंगतता ठेवली जेणेकरून मेसेज गमावले जाणार नाहीत.
• Schema safety. मी जुने कॉलम्स nullable ठेवले जेणेकरून डिप्लॉयमेंट दरम्यान डेटाबेसमध्ये काही बिघाड होणार नाही.

मी काय गमावले:

सर्वात मोठा तोटा म्हणजे व्हिजिबिलिटी (visibility). Hangfire मध्ये तुम्ही अयशस्वी (failed) जॉबवर क्लिक करून नेमके काय घडले ते पाहू शकता. RabbitMQ तुम्हाला Dead Letter Queue मध्ये किती मेसेज आहेत हे दाखवते, परंतु ते प्रत्येक जॉबसाठी तसा सोपा व्ह्यू देत नाही. आता मी डॅशबोर्डऐवजी स्ट्रक्चर्ड लॉग्सवर (structured logs) अवलंबून आहे.

माझा सल्ला:

जर खालील गोष्टी लागू असतील तर Hangfire वापरा:

• तुम्ही एक सिंगल सर्व्हिस चालवत असाल.
• तुमची टीम लहान असेल.
• तुम्हाला डीबगिंगसाठी सोप्या डॅशबोर्डची गरज असेल.

जर खालील गोष्टी लागू असतील तर RabbitMQ कडे वळा:

• तुमच्याकडे अनेक सर्व्हिसेस असतील.
• पोलिंगमुळे तुमच्या डेटाबेसवर जास्त लोड येत असेल.
• तुम्हाला pub/sub पॅटर्न वापरायचे असतील.

निर्णय तुमच्या सिस्टमवर अवलंबून असतो, केवळ एका जॉबवर नाही.

स्त्रोत: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4

पर्यायी लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi