Hangfire alternatifi: .NET'te BackgroundService ve Channel
Bir geliştirici, yeniden yazım sırasında Hangfire'ı tamamen bırakıp kanallarla beslenen iki BackgroundService worker'a geçişini ve recurring job'ların çoğunun aslında bir sorgu filtresi olduğunu anlatıyor. Hangfire veya Quartz.NET'in hâlâ ne zaman gerektiğini, ne zaman built-in runtime'ın yettiğini karşılaştıran pratik bir yazı.
Kilit noktalar
- Hangfire tamamen kaldırıldı: yazarın veritabanında 31 tablo var ve hiçbiri Hangfire'a ait değil.
- Zamanlanmış yayınlama, IsPublished ve ScheduledAt <= utcNow isteyen bir EF Core expression'a taşındı; her dakika çalışan job ve gecikmesi ortadan kalktı.
- Görüntüleme takibi 10.000 kapasiteli Channel.CreateBounded ve DropWrite kullanıyor; yoğunlukta HTTP istekleri bloklanmıyor, satırlar düşüyor.
- Worker her 5 saniyede en fazla 200 olayı yeni bir DI scope içinde yazıyor ve görüntüleme başına değil post başına tek UPDATE için ExecuteUpdateAsync kullanıyor.
- Exception'ları ExecuteAsync içinde yakalayın: .NET 6+ varsayılanı BackgroundServiceExceptionBehavior.StopHost ve host kapanır.
- PeriodicTimer basit sabit aralıklı işleri karşılıyor; dayanıklı, retry'lı ve çok sunuculu işler için Quartz.NET veya Hangfire doğru seçim olmaya devam ediyor.
Bir .NET geliştiricisi, ASP.NET Core sitesinden Hangfire'ı kaldırıp yerine bounded System.Threading.Channels ile beslenen iki BackgroundService sınıfı koyma sürecini anlatıyor. Beş recurring job'ın çoğu aslında gereksizmiş: zamanlanmış yayınlama ScheduledAt üzerinde bir EF Core WHERE koşuluna dönüşmüş, yedekleme hosting panelinin işine geçmiş, temizlik ise worker döngüsünün içine taşınmış. Gerçek arka plan işi olarak yalnızca sayfa görüntüleme sayacı ve gerçek kullanıcı hız verileri kalmış.
Desen küçük ama dikkat isteyen noktaları var. Kanal Channel.CreateBounded ve FullMode = DropWrite ile oluşturuluyor; böylece yoğunluk anında istekler bloklanmak yerine analytics satırları düşürülüyor. Worker 5 saniye boyunca en fazla 200 olay toplayıp tek seferde yazıyor ve bunu yeni bir DI scope içinde yapıyor, çünkü hosted service'ler singleton, DbContext ise scoped. Exception'lar döngünün içinde yakalanmalı: .NET 6'dan beri ExecuteAsync içindeki yakalanmamış bir hata host'u durduruyor. Feragat edilenler ise dayanıklılık, otomatik retry ve dashboard.
Gerçek dünyada kullanımı
- Her sayfa isteğinde görüntüleme sayacı veya analytics olayı yazan ve okuyucuyu uzak bir INSERT bekletmek istemeyen bir blog veya içerik sitesi.
- Yoğun trafikte değeri düşük yazmaları (telemetri, hız verisi, log satırları) toplu işleyen ve yoğunluk altında birkaçını kaybetmeyi kabul edebilen bir ASP.NET Core API.
- Yalnızca zamanlanmış yayınlama için kullanılan scheduler'ı sorgu zamanı filtresiyle değiştirmek; böylece postlar job olmadan ve dakika gecikmesi olmadan yayına girer.
- Tek sunuculu bir uygulamada 90 günden eski satırları silmek gibi saklama süresi temizliğini job kütüphanesi olmadan gece çalıştırmak.
Neden önemli
Bir job kütüphanesi eklemek kendi veritabanını, polling trafiğini, retry mekanizmasını ve izlenecek bir dashboard'u da getirir. Önce her zamanlanmış job'ı sorgulayın: zamanı hesaba katan bir sorgu veya kısa ömürlü in-process bir görev olarak yazılabiliyorsa altyapıyı yönetmek yerine ortadan kaldırmış olursunuz.