Hangfire থেকে RabbitMQ: ডাটাবেস পোলিং (Polling) বন্ধ করা

ছোট টিমের জন্য Hangfire দারুণ। আপনি একটি NuGet প্যাকেজ যোগ করবেন এবং এটিকে আপনার ডাটাবেসের সাথে যুক্ত করবেন। আপনি বিনামূল্যে একটি job runner এবং একটি dashboard পেয়ে যাবেন। একটি সিঙ্গেল সার্ভিসের জন্য এর চেয়ে ভালো কিছু পাওয়া কঠিন।

আমি SavePosty-তে ইমেল, webhook এবং কন্টেন্ট ফেচিং (fetching) হ্যান্ডেল করার জন্য Hangfire ব্যবহার করতাম। প্রতিটি job একইভাবে কাজ করত। নতুন কোনো কাজ আছে কি না তা পরীক্ষা করার জন্য সেগুলো প্রতি কয়েক সেকেন্ড অন্তর আমার Postgres ডাটাবেস পোলিং (poll) করত।

অবশেষে আমি সবকিছু RabbitMQ-তে সরিয়ে নিয়েছি। কেন আমি এটি করেছি এবং এর ফলে কী কী হারিয়েছি, তা নিচে দেওয়া হলো।

কেন আমি পরিবর্তন করলাম:

  • পোলিং লোড কাজের পরিমাণের ওপর নয়, বরং সময়ের ওপর নির্ভর করে বাড়ে। প্রতিটি Hangfire job একটি টাইমারের মাধ্যমে আপনার ডাটাবেসে হিট করে। এমনকি যদি কোনো কাজ না-ও থাকে, তবুও ডাটাবেস ব্যস্ত থাকে। আপনার job সংখ্যা এবং পোলিং ফ্রিকোয়েন্সি বাড়ার সাথে সাথে এই খরচও বাড়তে থাকে।
  • অনেক বেশি মডেল। আমার অ্যাপের একটি অংশ ইতিমধ্যে RabbitMQ ব্যবহার করছিল। বাকি অংশটি ব্যবহার করছিল Hangfire। এর মানে হলো ব্যাকগ্রাউন্ড ওয়ার্ক ম্যানেজ করার জন্য দুটি ভিন্ন পদ্ধতি ছিল। RabbitMQ-তে চলে আসার ফলে সবকিছু একীভূত (unified) হয়ে গেছে।
  • ল্যাটেন্সি (Latency)। একটি ব্রোকার (broker) কাজ আসার সাথে সাথেই তা পুশ করে দেয়। অন্যদিকে Hangfire পরবর্তী পোলিংয়ের জন্য অপেক্ষা করে।

সুবিধা ও অসুবিধা (Trade-offs):

Hangfire সেটআপ করা সহজ। এটি আপনার বিদ্যমান SQL টেবিল ব্যবহার করে। এতে একটি চমৎকার বিল্ট-ইন dashboard রয়েছে।

RabbitMQ-এর জন্য একটি ব্রোকার ম্যানেজ করতে হয়। এটি ডাটাবেস CPU-এর পরিবর্তে RAM এবং নেটওয়ার্ক ব্যবহার করে। আপনি এতে আরও ভালো স্কেলিং পাবেন, তবে অপারেশনাল ওভারহেড (operational overhead) বা বাড়তি কাজের চাপও বাড়বে।

আমি কীভাবে নিরাপদে মাইগ্রেট করলাম:

আমি আমার বিজনেস লজিক একদম একই রেখেছি। আমি কিছু 'thin consumers' তৈরি করেছি যা ফ্রন্ট ডোর হিসেবে কাজ করে। কনজিউমার মেসেজটি গ্রহণ করে এবং সেটি বিদ্যমান job class-এর কাছে পাঠিয়ে দেয়।

আমি দুটি বিষয়ের ওপর ফোকাস করেছি:

  • Retry parity। আমি RabbitMQ কনজিউমারে Hangfire-এর retry সেটিংসের সাথে মিল রেখেছি যাতে কোনো মেসেজ হারিয়ে না যায়।
  • Schema safety। আমি পুরনো কলামগুলোকে nullable রেখেছি যাতে ডেপ্লয়মেন্টের সময় ডাটাবেসে কোনো সমস্যা না হয়।

আমি কী হারিয়েছি:

সবচেয়ে বড় অসুবিধা হলো ভিজিবিলিটি (visibility)। Hangfire আপনাকে একটি ফেইলড job-এ ক্লিক করে ঠিক কী ঘটেছে তা দেখার সুযোগ দেয়। RabbitMQ আপনাকে দেখায় Dead Letter Queue-তে কতগুলো মেসেজ আছে, কিন্তু এটি আপনাকে প্রতিটি job-এর জন্য সেই একই সহজ ভিউ দেয় না। এখন আমি dashboard-এর পরিবর্তে structured logs-এর ওপর নির্ভর করি।

আমার পরামর্শ:

Hangfire ব্যবহার চালিয়ে যান যদি:

  • আপনি একটি সিঙ্গেল সার্ভিস চালান।
  • আপনার একটি ছোট টিম থাকে।
  • ডিবাগিংয়ের জন্য আপনার একটি সহজ dashboard প্রয়োজন হয়।

RabbitMQ-তে চলে যান যদি:

  • আপনার একাধিক সার্ভিস থাকে।
  • পোলিংয়ের কারণে আপনার ডাটাবেস লোড অনেক বেশি হয়।
  • আপনি pub/sub প্যাটার্ন ব্যবহার করতে চান।

সিদ্ধান্তটি আপনার সিস্টেমের ওপর নির্ভর করে, কোনো একটি নির্দিষ্ট job-এর ওপর নয়।

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

Optional learning community: https://t.me/GyaanSetuAi