Hangfire ਤੋਂ RabbitMQ ਤੱਕ: Database Polling ਨੂੰ ਖਤਮ ਕਰਨਾ

Hangfire ਛੋਟੀਆਂ ਟੀਮਾਂ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਤੁਸੀਂ ਇੱਕ NuGet package ਜੋੜਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ database ਵੱਲ ਮੋੜ ਦਿੰਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਮੁਫ਼ਤ ਵਿੱਚ ਇੱਕ job runner ਅਤੇ ਇੱਕ dashboard ਮਿਲ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਸਿੰਗਲ service ਲਈ, ਇਸਦਾ ਮੁਕਾਬਲਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ।

ਮੈਂ SavePosty ਵਿੱਚ emails, webhooks, ਅਤੇ content fetching ਨੂੰ ਸੰਭਾਲਣ ਲਈ Hangfire ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ। ਹਰ job ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦੀ ਸੀ। ਉਹ ਸਾਰੇ ਨਵੇਂ ਕੰਮ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਮੇਰੇ Postgres database ਨੂੰ poll ਕਰਦੇ ਸਨ।

ਅੰਤ ਵਿੱਚ ਮੈਂ ਸਭ ਕੁਝ RabbitMQ 'ਤੇ ਬਦਲ ਦਿੱਤਾ। ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਮੈਂ ਅਜਿਹਾ ਕਿਉਂ ਕੀਤਾ ਅਤੇ ਮੈਂ ਕੀ ਗੁਆ ਲਿਆ।

ਮੈਂ ਕਿਉਂ ਬਦਲਿਆ:

• Polling load ਸਮੇਂ ਦੇ ਨਾਲ ਵਧਦਾ ਹੈ, ਕੰਮ ਦੇ ਨਾਲ ਨਹੀਂ। ਹਰ Hangfire job ਇੱਕ timer 'ਤੇ ਤੁਹਾਡੇ database ਨੂੰ hit ਕਰਦੀ ਹੈ। ਭਾਵੇਂ ਕੋਈ ਕੰਮ ਨਾ ਹੋਵੇ, database ਵਿਅਸਤ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਲਾਗਤ ਤੁਹਾਡੇ job count ਅਤੇ poll frequency ਦੇ ਨਾਲ ਵਧਦੀ ਜਾਂਦੀ ਹੈ।
• ਬਹੁਤ ਸਾਰੇ models। ਮੇਰੀ app ਦਾ ਇੱਕ ਹਿੱਸਾ ਪਹਿਲਾਂ ਹੀ RabbitMQ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਸੀ। ਬਾਕੀ Hangfire ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਨ। ਇਸਦਾ ਮਤਲਬ ਸੀ background work ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੇ ਦੋ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ। RabbitMQ 'ਤੇ ਜਾਣ ਨਾਲ ਸਭ ਕੁਝ ਇੱਕਸਾਰ ਹੋ ਗਿਆ।
• Latency। ਇੱਕ broker ਕੰਮ ਆਉਂਦੇ ਹੀ ਉਸਨੂੰ push ਕਰ ਦਿੰਦਾ ਹੈ। Hangfire ਅਗਲੇ poll ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।

ਸਮਝੌਤੇ (Trade-offs):

Hangfire ਨੂੰ set up ਕਰਨਾ ਆਸਾਨ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਮੌਜੂਦਾ SQL tables ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕ ਵਧੀਆ built-in dashboard ਹੈ।

RabbitMQ ਲਈ ਇੱਕ broker ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ database CPU ਦੀ ਬਜਾਏ RAM ਅਤੇ network ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਬਿਹਤਰ scaling ਮਿਲਦੀ ਹੈ, ਪਰ operational overhead ਵਧ ਜਾਂਦਾ ਹੈ।

ਮੈਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ migrate ਕੀਤਾ:

ਮੈਂ ਆਪਣੀ business logic ਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਰੱਖਿਆ। ਮੈਂ thin consumers ਬਣਾਏ ਜੋ ਇੱਕ front door ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ। Consumer ਮੈਸੇਜ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਮੌਜੂਦਾ job class ਨੂੰ ਸੌਂਪ ਦਿੰਦਾ ਹੈ।

ਮੈਂ ਦੋ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ:

• Retry parity। ਮੈਂ RabbitMQ consumer ਵਿੱਚ Hangfire retry settings ਨੂੰ ਮਿਲਾ ਦਿੱਤਾ ਤਾਂ ਜੋ ਮੈਸੇਜ ਗੁਆ ਨਾ ਦਿੱਤੇ ਜਾਣ।
• Schema safety। ਮੈਂ ਪੁਰਾਣੇ columns ਨੂੰ nullable ਰੱਖਿਆ ਤਾਂ ਜੋ deploy ਦੌਰਾਨ database ਖਰਾਬ ਨਾ ਹੋਵੇ।

ਮੈਂ ਕੀ ਗੁਆ ਲਿਆ:

ਸਭ ਤੋਂ ਵੱਡਾ ਨੁਕਸਾਨ visibility ਦਾ ਹੈ। Hangfire ਤੁਹਾਨੂੰ ਇੱਕ ਫੇਲ ਹੋਏ job 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਅਤੇ ਇਹ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਬਿਲਕੁਲ ਕੀ ਹੋਇਆ ਸੀ। RabbitMQ ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ Dead Letter Queue ਵਿੱਚ ਕਿੰਨੇ ਮੈਸੇਜ ਹਨ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਦਾ ਆਸਾਨ per-job view ਨਹੀਂ ਦਿੰਦਾ। ਹੁਣ ਮੈਂ dashboard ਦੀ ਬਜਾਏ structured logs 'ਤੇ ਨਿਰਭਰ ਹਾਂ।

ਮੇਰੀ ਸਲਾਹ:

Hangfire 'ਤੇ ਹੀ ਰਹੋ ਜੇਕਰ:

• ਤੁਸੀਂ ਇੱਕ ਸਿੰਗਲ service ਚਲਾਉਂਦੇ ਹੋ।
• ਤੁਹਾਡੀ ਟੀਮ ਛੋਟੀ ਹੈ।
• ਤੁਹਾਨੂੰ debugging ਲਈ ਇੱਕ ਆਸਾਨ dashboard ਦੀ ਲੋੜ ਹੈ।

RabbitMQ 'ਤੇ ਜਾਓ ਜੇਕਰ:

• ਤੁਹਾਡੀਆਂ ਕਈ services ਹਨ।
• Polling ਕਾਰਨ ਤੁਹਾਡੇ database 'ਤੇ load ਜ਼ਿਆਦਾ ਹੈ।
• ਤੁਸੀਂ pub/sub patterns ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਫੈਸਲਾ ਤੁਹਾਡੇ ਸਿਸਟਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਕਿਸੇ ਇੱਕ job 'ਤੇ ਨਹੀਂ।

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

ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi