Hangfire થી RabbitMQ સુધી: Database Polling નો અંત

Hangfire નાની ટીમો માટે ઉત્તમ છે. તમે એક NuGet પેકેજ ઉમેરો છો અને તેને તમારા ડેટાબેઝ સાથે જોડો છો. તમને મફતમાં જ એક job runner અને dashboard મળે છે. એક સિંગલ સર્વિસ માટે, તેને પછાડવું મુશ્કેલ છે.

મેં SavePosty માં ઈમેલ, webhooks અને content fetching હેન્ડલ કરવા માટે Hangfire નો ઉપયોગ કર્યો હતો. દરેક job એક જ રીતે કામ કરતું હતું. નવા કામની તપાસ કરવા માટે તે બધા દર થોડી સેકન્ડે મારા Postgres ડેટાબેઝને poll કરતા હતા.

અંતે મેં બધું RabbitMQ પર ખસેડ્યું. મેં આવું શા માટે કર્યું અને મેં શું ગુમાવ્યું તેની વિગતો અહીં છે.

મેં શા માટે સ્થાનાંતર કર્યું:

  • Polling લોડ કામના આધારે નહીં, પણ સમય સાથે વધતો જાય છે. દરેક Hangfire job એક ટાઈમર પર તમારા ડેટાબેઝને એક્સેસ કરે છે. જો કોઈ કામ ન હોય તો પણ, ડેટાબેઝ વ્યસ્ત રહે છે. આ ખર્ચ તમારા job ની સંખ્યા અને poll ની આવૃત્તિ (frequency) સાથે વધતો જાય છે.
  • ઘણા બધા models. મારા એપનો એક ભાગ પહેલેથી જ RabbitMQ નો ઉપયોગ કરતો હતો. બાકીનો ભાગ Hangfire નો ઉપયોગ કરતો હતો. આનો અર્થ એ હતો કે બેકગ્રાઉન્ડ વર્ક મેનેજ કરવા માટે બે અલગ અલગ રીતો હતી. RabbitMQ પર સ્થાનાંતરિત થવાથી બધું એકીકૃત (unified) થઈ ગયું.
  • Latency. બ્રોકર (broker) કામ આવે કે તરત જ તેને પુશ કરે છે. Hangfire આગલા poll ની રાહ જુએ છે.

The trade-offs:

Hangfire સેટઅપ કરવું સરળ છે. તે તમારા હાલના SQL ટેબલ્સનો ઉપયોગ કરે છે. તેમાં એક ઉત્તમ built-in dashboard છે.

RabbitMQ માં બ્રોકર મેનેજ કરવાની જરૂર પડે છે. તે ડેટાબેઝ CPU ને બદલે RAM અને નેટવર્કનો ઉપયોગ કરે છે. તમને વધુ સારું scaling મળે છે, પરંતુ ઓપરેશનલ ઓવરહેડ (operational overhead) પણ વધે છે.

મેં સુરક્ષિત રીતે કેવી રીતે માઈગ્રેશન કર્યું:

મેં મારું business logic બિલકુલ એ જ રાખ્યું. મેં thin consumers બનાવ્યા જે ફ્રન્ટ ડોર તરીકે કામ કરે છે. કન્ઝ્યુમર મેસેજ મેળવે છે અને તેને હાલના job ક્લાસને સોંપે છે.

મેં બે બાબતો પર ધ્યાન કેન્દ્રિત કર્યું:

  • Retry parity. મેં RabbitMQ કન્ઝ્યુમરમાં Hangfire ની retry settings સાથે મેળ બેસાડી જેથી મેસેજ ગુમાવવાનો ડર ન રહે.
  • Schema safety. મેં જૂના કોલમ્સને nullable રાખ્યા જેથી ડિપ્લોયમેન્ટ દરમિયાન ડેટાબેઝમાં કોઈ સમસ્યા ન આવે.

મેં શું ગુમાવ્યું:

સૌથી મોટો ગેરફાયદો વિઝિબિલિટી (visibility) નો છે. Hangfire તમને નિષ્ફળ ગયેલા job પર ક્લિક કરવા અને બરાબર શું થયું તે જોવા દે છે. RabbitMQ તમને બતાવે છે કે Dead Letter Queue માં કેટલા મેસેજ છે, પરંતુ તે તમને દરેક job માટે તેટલો સરળ વ્યુ (view) આપતું નથી. હવે હું dashboard ને બદલે structured logs પર આધાર રાખું છું.

મારી સલાહ:

Hangfire પર જ રહો જો:

  • તમે સિંગલ સર્વિસ ચલાવો છો.
  • તમારી પાસે નાની ટીમ છે.
  • તમને ડિબગિંગ (debugging) માટે સરળ dashboard ની જરૂર છે.

RabbitMQ પર સ્થાનાંતરિત થાઓ જો:

  • તમારી પાસે મલ્ટીપલ સર્વિસ છે.
  • polling ને કારણે તમારા ડેટાબેઝ પર લોડ વધારે છે.
  • તમે pub/sub patterns નો ઉપયોગ કરવા માંગો છો.

નિર્ણય તમારી સિસ્ટમ પર આધાર રાખે છે, કોઈ એક જૉબ પર નહીં.

Source: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4

વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi