Dari Hangfire ke RabbitMQ: Menghentikan Polling Database

Hangfire sangat bagus untuk tim kecil. Anda cukup menambahkan paket NuGet dan mengarahkannya ke database Anda. Anda mendapatkan job runner dan dashboard secara gratis. Untuk satu layanan, ini sulit dikalahkan.

Saya menggunakan Hangfire untuk SavePosty guna menangani email, webhook, dan pengambilan konten. Setiap job bekerja dengan cara yang sama. Semuanya melakukan polling ke database Postgres saya setiap beberapa detik untuk memeriksa pekerjaan baru.

Akhirnya saya memindahkan semuanya ke RabbitMQ. Berikut adalah alasan mengapa saya melakukannya dan apa yang saya korbankan.

Mengapa saya pindah:

  • Beban polling meningkat seiring waktu, bukan seiring beban kerja. Setiap job Hangfire membebani database Anda berdasarkan timer. Meskipun tidak ada pekerjaan, database tetap sibuk. Biaya ini tumbuh seiring dengan jumlah job dan frekuensi polling Anda.
  • Terlalu banyak model. Satu bagian dari aplikasi saya sudah menggunakan RabbitMQ. Sisanya menggunakan Hangfire. Ini berarti ada dua cara berbeda untuk mengelola pekerjaan latar belakang. Berpindah ke RabbitMQ menyatukan semuanya.
  • Latensi. Sebuah broker mendorong pekerjaan saat itu juga ketika pesan tiba. Hangfire menunggu polling berikutnya.

Trade-offs:

Hangfire mudah untuk dikonfigurasi. Ia menggunakan tabel SQL yang sudah ada. Ia memiliki dashboard bawaan yang hebat.

RabbitMQ memerlukan pengelolaan broker. Ia menggunakan RAM dan jaringan alih-alih CPU database. Anda mendapatkan skalabilitas yang lebih baik, tetapi dengan overhead operasional yang lebih tinggi.

Cara saya bermigrasi dengan aman:

Saya menjaga logika bisnis saya tetap sama persis. Saya membangun thin consumer yang bertindak sebagai pintu depan. Consumer tersebut menerima pesan dan menyerahkannya ke class job yang sudah ada.

Saya fokus pada dua hal:

  • Paritas retry. Saya menyamakan pengaturan retry Hangfire di consumer RabbitMQ agar saya tidak kehilangan pesan.
  • Keamanan skema. Saya membiarkan kolom lama tetap nullable agar tidak merusak database selama proses deployment.

Apa yang saya korbankan:

Kekurangan terbesarnya adalah visibilitas. Hangfire memungkinkan Anda mengklik job yang gagal dan melihat apa yang sebenarnya terjadi. RabbitMQ menunjukkan berapa banyak pesan yang ada di Dead Letter Queue, tetapi tidak memberikan tampilan per-job yang mudah seperti itu. Sekarang saya mengandalkan log terstruktur alih-alih dashboard.

Saran saya:

Tetap gunakan Hangfire jika:

  • Anda menjalankan satu layanan tunggal.
  • Anda memiliki tim kecil.
  • Anda membutuhkan dashboard yang mudah untuk debugging.

Pindah ke RabbitMQ jika:

  • Anda memiliki banyak layanan.
  • Beban database Anda akibat polling sangat tinggi.
  • Anda ingin menggunakan pola pub/sub.

Keputusan tersebut bergantung pada sistem Anda, bukan pada satu job saja.

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

Komunitas belajar opsional: https://t.me/GyaanSetuAi