\u00c7o\u011fu ki\u015fi i\u00e7in scheduler denince ak\u0131llarda \u015fu canlanmaktad\u0131r; “her gece 02:00’da rapor \u00fcret”<\/p>\n

Ancak scheduler bundan \u00e7ok daha fazlas\u0131na kar\u015f\u0131l\u0131k gelmektedir; bir i\u015flemden 10 dakika sonra e-posta g\u00f6ndermeden tutun sipari\u015f verildikten 24 saat sonra \u00f6deme gelmediyse iptal edilmesine kadar davran\u0131\u015fsal planlamalar\u0131n \u00f6tesinde, belirli bir zamanda \u00e7al\u0131\u015facak i\u015flerin delayed event olarak planlanmas\u0131, periyodik g\u00f6revlerin ne zaman \u00e7al\u0131\u015faca\u011f\u0131n\u0131 belirlemek \u00fczere cron yap\u0131land\u0131rmalar\u0131n\u0131n tan\u0131mlanmas\u0131 ve hatta bu planlamalar\u0131n s\u00fcrd\u00fcr\u00fclebilirli\u011fini sa\u011flamak amac\u0131yla persistence mekanizmalar\u0131n\u0131n kullan\u0131lmas\u0131 gibi yetenekler de scheduler’\u0131n temel sorumluluk alan\u0131na girmektedir. Dolay\u0131s\u0131yla bunlar\u0131n tamam\u0131, scheduler’\u0131n ihtiya\u00e7 duydu\u011fu yard\u0131mc\u0131 kabiliyetlerdir.<\/p>\n

Ancak scheduler’\u0131n bu sorumluluklar\u0131 yerine getirebilmesi, beraberinde \u00e7\u00f6z\u00fclmesi gereken birtak\u0131m tasar\u0131m problemlerini ve \u00e7al\u0131\u015fma zaman\u0131 risklerini de ortaya \u00e7\u0131karmaktad\u0131r. \u015eimdi gelin bu riskleri tek tek masaya yat\u0131rarak fark\u0131ndal\u0131k olu\u015fturmaya \u00e7al\u0131\u015fal\u0131m;<\/p>\n

Uygulaman\u0131n yeniden ba\u015flarsa ne olacak?<\/em><\/strong>
\nDiyelim ki; 02:00’da rapor \u00fcretilecek. Ya uygulama 01:59’da \u00e7\u00f6ker ve 02:00’da \u00e7al\u0131\u015fmayarak 02:15’te tekrar aya\u011fa kalkarsa! B\u00f6yle bir durumda ideal olan scheduler’\u0131n planlanan i\u015fi kaybetmemesi gerekmektedir. Dolay\u0131s\u0131yla schedule bilgisinin sadece RAM’de tutulmas\u0131 yeterli de\u011fildir.\n<\/li>\n
Uygulaman\u0131n birden fazla instance’\u0131 varsa?<\/em><\/strong>\n
\n
\n Load Balancer
\n \u2502
\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510
\n \u2193 \u2193 \u2193
\nAPI #1 API #2 API #3\n<\/div>\n
\nModern uygulamalar genellikle yandaki gibi load balancer e\u015fli\u011finde \u00f6l\u00e7eklendirilerek tasarlanmaktad\u0131r. Haliyle t\u00fcm instance’lar da scheduler yap\u0131land\u0131r\u0131lmaktad\u0131r. B\u00f6yle bir tasar\u0131mdaki en b\u00fcy\u00fck risk ayn\u0131 i\u015fin \u00f6l\u00e7eklendirilmenin yap\u0131ld\u0131\u011f\u0131 instance say\u0131s\u0131 kadar \u00e7al\u0131\u015fabilme ihtimalidir.\n<\/div>\n<\/div>\n
Dolay\u0131s\u0131yla burada scheduler’\u0131n \u00e7\u00f6zmesi gereken bir problem ortaya \u00e7\u0131kmaktad\u0131r: “bu i\u015fi hangi instance \u00e7al\u0131\u015ft\u0131racakt\u0131r?”<\/em>\n<\/li>\n
Job ba\u015far\u0131s\u0131z olursa ne olacak?<\/em><\/strong>
\nScheduler taraf\u0131ndan \u00e7al\u0131\u015ft\u0131r\u0131lan i\u015f exception f\u0131rlat\u0131rsa e\u011fer bu taktirde yine ideal olan i\u015fin tekrar \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 olacakt\u0131r. B\u00f6yle durumlarda scheduler’\u0131n kendisinden ziyade job execution\/retry politikalar\u0131 devreye girecektir.\n<\/li>\n

Job’\u0131n state’i bir yerde tutulmal\u0131d\u0131r!<\/em><\/strong>
\nJob’\u0131n ne zaman \u00e7al\u0131\u015faca\u011f\u0131, en son ne zaman \u00e7al\u0131\u015ft\u0131\u011f\u0131, ba\u015far\u0131l\u0131 m\u0131yd\u0131, ba\u015far\u0131s\u0131z m\u0131yd\u0131, ka\u00e7 kere retry edildi\u011fi yahut bir sonraki \u00e7al\u0131\u015fman\u0131n ne zaman oldu\u011fu gibi sorular\u0131n cevaplar\u0131n\u0131 bir yerden alabiliyor olmam\u0131z gerekmektedir. E\u011fer ki bu sorular\u0131n cevaplar\u0131 RAM’de tutuluyorsa bu ciddi bir risk te\u015fkil etmektedir. Haliyle SQL Server, PostgreSQL yahut Redis gibi persistence mekanizmalar\u0131yla kal\u0131c\u0131 hale getirilmelidir!\n<\/li>\n<\/ul>\n
Peki t\u00fcm bunlar neden problemdir?<\/strong><\/em>
\nEn saf haliyle ba\u015flang\u0131\u00e7taki amac\u0131m\u0131z her gece 02:00\u2019da rapor \u00fcretmekti<\/em>. Ancak olay \u00f6yle bir noktaya geliyor ki production’da Schedule \u2192 Persistence \u2192 Concurrency \u2192 Distributed Execution \u2192 Retry \u2192 Failure Handling \u2192 Recovery \u2192 Monitoring<\/span> gibi bir sisteme ihtiya\u00e7 oldu\u011fu ortaya \u00e7\u0131k\u0131yor!<\/p>\n
Evet, Quartz.NET ve Hangfire’\u0131n tam da \u00e7\u00f6zd\u00fc\u011f\u00fc problem bu ihtiya\u00e7 silsilesidir…<\/p>\n
Peki Quartz.NET ve Hangfire neye yetmiyor?<\/strong><\/em>
\nAsl\u0131nda Quartz.NET ve Hangfire’\u0131n \u00e7\u00f6zemedi\u011fi temel bir scheduling problemi yoktur! \u0130kisi de bu tarz ihtiya\u00e7 s\u00fcre\u00e7lerinde tercih edilebilecek kadar olgun \u00e7\u00f6z\u00fcmlerdir. Zaten TickerQ’nun da ortaya \u00e7\u0131k\u0131\u015f\u0131n\u0131 “Quartz.NET ve Hangfire yetersizdi, TickerQ geldi” \u015feklinde anlatmak hem niyet hem de teknik olarak olduk\u00e7a yan\u0131lt\u0131c\u0131 olacakt\u0131r! Do\u011frusu \u015fudur; Quartz.NET ve Hangfire’\u0131n \u00e7\u00f6zd\u00fc\u011f\u00fc problemlere kar\u015f\u0131n TickerQ daha modern bir yakla\u015f\u0131m sergileyerek \u00e7\u00f6z\u00fcm getirmektedir…<\/p>\n
\u015e\u00f6yle ki; Quartz.NET ve Hangfire geleneksel reflection altyap\u0131s\u0131na sahipken, TickerQ’nun yap\u0131s\u0131 ise .NET d\u00fcnyas\u0131nda de\u011fi\u015fiklik g\u00f6steren source generators, native AOT vs. gibi beklentilere ayak uydurabilmektedir… <\/p>\n
<\/span>TickerQ’nun Quartz.NET ve Hangfire’dan Fark\u0131 Nedir?<\/span><\/h4>\n
TickerQ, Quartz.NET ve Hangfire ile ayn\u0131 temel probleme \u00e7\u00f6z\u00fcm getirmektedir. Yani \u00fc\u00e7\u00fc de, bir i\u015fi \u015fimdi de\u011fil, belirli bir zamanda veya belirli aral\u0131klarla g\u00fcvenli \u015fekilde \u00e7al\u0131\u015ft\u0131rmaya odakl\u0131d\u0131rlar. Ama \u00e7\u00f6z\u00fcm s\u00fcre\u00e7lerindeki yakla\u015f\u0131mlar\u0131 olduk\u00e7a farkl\u0131d\u0131r:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
<\/th>\n Quartz.NET<\/th>\n Hangfire<\/th>\n TickerQ<\/th>\n<\/tr>\n<\/thead>\n
Ana fikir<\/td>\n G\u00fc\u00e7l\u00fc scheduler<\/td>\n Persistent background jobs<\/td>\n Modern .NET scheduler<\/td>\n<\/tr>\n
Job ke\u015ffi<\/td>\n Runtime\/reflection<\/td>\n Runtime\/reflection<\/td>\n Compile-time source generator<\/td>\n<\/tr>\n
Native AOT<\/td>\n \u274c<\/td>\n \u274c<\/td>\n \u2705<\/td>\n<\/tr>\n
Persistence<\/td>\n ADO.NET JobStore<\/td>\n SQL\/Redis vb.<\/td>\n EF Core \/ Redis<\/td>\n<\/tr>\n
Dashboard<\/td>\n Yerle\u015fik de\u011fil<\/td>\n \u2705<\/td>\n \u2705<\/td>\n<\/tr>\n
Cron<\/td>\n \u00c7ok g\u00fc\u00e7l\u00fc<\/td>\n G\u00fc\u00e7l\u00fc<\/td>\n \u2705<\/td>\n<\/tr>\n
Delayed job<\/td>\n \u2705<\/td>\n \u2705<\/td>\n \u2705<\/td>\n<\/tr>\n
Retry<\/td>\n \u2705 \/ yap\u0131land\u0131r\u0131labilir<\/td>\n \u2705 \u00e7ok g\u00fc\u00e7l\u00fc<\/td>\n \u2705<\/td>\n<\/tr>\n
Job chaining<\/td>\n Listener vb.<\/td>\n Continuations<\/td>\n Parent\/child<\/td>\n<\/tr>\n
Modern .NET yakla\u015f\u0131m\u0131<\/td>\n Orta<\/td>\n Orta<\/td>\n \u00c7ok g\u00fc\u00e7l\u00fc<\/td>\n<\/tr>\n
Olgunluk<\/td>\n \ud83d\udfe2 \u00c7ok y\u00fcksek<\/td>\n \ud83d\udfe2 \u00c7ok y\u00fcksek<\/td>\n \ud83d\udfe1 Yeni<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
TickerQ’nun en b\u00fcy\u00fck numaras\u0131 source generator’d\u0131r! Kodu otomatik \u00fcretmekte ve compile etmektedir.<\/em><\/p><\/blockquote>\n
Quartz.NET ve Hangfire etraf\u0131nda y\u0131llarca olu\u015fmu\u015f (persistence, recovery, concurrency, retry, clustering, scheduling semantics, monitoring, job lifecycle vs. gibi)<\/span> kocaman bir ekosistem mevcuttur. Haliyle bu k\u00fct\u00fcphanelerin \u00e7\u00f6zd\u00fc\u011f\u00fc scheduling\/background-job problemlerini TickerQ, modern .NET’in compile-time ve AOT d\u00fcnyas\u0131na daha uygun bir mimariyle \u00e7\u00f6zmeye \u00e7al\u0131\u015fmakta ve bu ekosistemin \u00f6nemli bir b\u00f6l\u00fcm\u00fcn\u00fc sunmaktad\u0131r.<\/p>\n
<\/span>Quartz.NET, Hangfire ve TickerQ Tam Olarak Ayn\u0131 \u015eey mi?<\/span><\/h4>\n
Hay\u0131r, ayn\u0131 \u015fey de\u011filler! Ama ayn\u0131 problem alan\u0131nda kesi\u015fmektedirler.<\/p>\n
Quartz.NET, Hangfire ve TickerQ birbirlerinin birebir alternatifleri de\u011fildir; fakat \u00fc\u00e7\u00fcn\u00fcn de “zamanlanm\u0131\u015f\/arka plan i\u015flerini g\u00fcvenilir bi\u00e7imde \u00e7al\u0131\u015ft\u0131rma” yetenekleri vard\u0131r.<\/em><\/p><\/blockquote>\n
Dolay\u0131s\u0131yla \u00fc\u00e7\u00fc de scheduler m\u0131? diye sorarsan\u0131z, evet \u00fc\u00e7\u00fcn\u00fcn de scheduler yeteni vard\u0131r. Ancak \u00fc\u00e7\u00fc ayn\u0131 scheduler’\u0131n \u00fc\u00e7 farkl\u0131 implementasyonu de\u011fildir! <\/p>\n
<\/span>Avantajlar\u0131 & Dezavantajlar\u0131<\/span><\/h4>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
<\/th>\n Quartz.NET<\/th>\n Hangfire<\/th>\n TickerQ<\/th>\n<\/tr>\n<\/thead>\n
En g\u00fc\u00e7l\u00fc taraf\u0131<\/td>\n \u00c7ok geli\u015fmi\u015f scheduling<\/td>\n Kullan\u0131m kolayl\u0131\u011f\u0131 + dashboard<\/td>\n Modern .NET + source generation<\/td>\n<\/tr>\n
En b\u00fcy\u00fck avantaj\u0131<\/td>\n Scheduling konusunda \u00e7ok olgun<\/td>\n Background job y\u00f6netimi \u00e7ok rahat<\/td>\n Reflection’s\u0131z, AOT uyumlu yakla\u015f\u0131m<\/td>\n<\/tr>\n
En b\u00fcy\u00fck dezavantaj\u0131<\/td>\n Karma\u015f\u0131k ve a\u011f\u0131r gelebilir<\/td>\n Scheduler’dan \u00e7ok job platformu yakla\u015f\u0131m\u0131<\/td>\n Daha gen\u00e7 ekosistem<\/td>\n<\/tr>\n
\u00d6\u011frenme<\/td>\n \ud83d\udd34 Zor<\/td>\n \ud83d\udfe2 Kolay<\/td>\n \ud83d\udfe2 Kolay \/ Orta<\/td>\n<\/tr>\n
Dashboard<\/td>\n \u274c<\/td>\n \u2705 \u00c7ok iyi<\/td>\n \u2705<\/td>\n<\/tr>\n
Cron<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50<\/td>\n<\/tr>\n
Persistence<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50<\/td>\n<\/tr>\n
Retry<\/td>\n \u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50<\/td>\n<\/tr>\n
Native AOT<\/td>\n \u274c<\/td>\n \u274c<\/td>\n \u2705<\/td>\n<\/tr>\n
Ekosistem<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50<\/td>\n<\/tr>\n
Production ge\u00e7mi\u015fi<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50\u2b50\u2b50\u2b50<\/td>\n \u2b50\u2b50<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Yukar\u0131daki tablodan da g\u00f6r\u00fclece\u011fi \u00fczere scheduling i\u015flemlerinde kullanabilece\u011fimiz bu k\u00fct\u00fcphanelerin avantaj ve dezavantajlar\u0131n\u0131 gayet g\u00fczel bir \u015fekilde mukayese etmi\u015f bulunuyoruz. Ancak konuya dair daha iyi sindirilebilmesi i\u00e7in bir ka\u00e7 kelam s\u00f6ylemekte fayda g\u00f6rmekteyim. \u00d6ncelikle Quartz.NET’i ele alal\u0131m. Bu k\u00fct\u00fcphanenin en b\u00fcy\u00fck avantaj\u0131 \u00e7ok olgun olmas\u0131d\u0131r. Y\u0131llard\u0131r mevzu bahis olan problemler \u00fczerine odaklanmas\u0131 ve scheduling senaryolar\u0131nda say\u0131s\u0131z kez varl\u0131k g\u00f6stermesi bu k\u00fct\u00fcphaneyi ister istemez \u00e7ok g\u00fc\u00e7l\u00fc k\u0131lmaktad\u0131r. Ancak bu g\u00fcc\u00fcn en b\u00fcy\u00fck bedeli ise getirdi\u011fi karma\u015f\u0131kl\u0131kt\u0131r. Basit bir i\u015f i\u00e7in bile Quartz.NET’te abstraction’larla u\u011fra\u015fmak ikrah ettirecek derecede ka\u00e7\u0131n\u0131lmaz olacakt\u0131r.<\/p>\n
Hangfire’a gelirsek e\u011fer kullan\u0131m\u0131n\u0131n kolay olmas\u0131 en b\u00fcy\u00fck avantaj\u0131d\u0131r. \u00dcstelik \u00e7ok g\u00fczel bir dashboard’a sahiptir. Ancak bu kolayl\u0131k Quartz.NET’e nazaran biraz y\u00fczeysel kalmas\u0131na sebebiyet vermekte ve scheduling s\u00fcre\u00e7lerinde derin yap\u0131land\u0131rmalara kadar inememektedir. Yani demek istedi\u011fim o ki, \u00e7ok karma\u015f\u0131k scheduling politikalar\u0131n\u0131n s\u00f6z konusu oldu\u011fu senaryolarda Hangfire’a nazaran Quartz daha rahat e\u015flik edebilmektedir.<\/p>\n
TickerQ ise modern .NET yakla\u015f\u0131mlar\u0131yla yap\u0131land\u0131r\u0131lm\u0131\u015f yeni bir scheduling k\u00fct\u00fcphanesidir. \u00d6nceki sat\u0131rlarda vurguland\u0131\u011f\u0131 gibi en b\u00fcy\u00fck avantaj\u0131 source generator altyap\u0131s\u0131na sahip olmas\u0131d\u0131r. Yani job’lar\u0131 runtime’da reflection ile ke\u015ffetmektense compile-time’da bulup, \u00e7al\u0131\u015ft\u0131rabilmektedir. Bu da s\u00fcre\u00e7te bizlere ciddi performans getirmekte ve maliyeti d\u00fc\u015f\u00fcrmektedir.<\/p>\n
TickerQ kesinlikle Quartz.NET’ten daha h\u0131zl\u0131d\u0131r!<\/em><\/p><\/blockquote>\n
Ancak TickerQ’nun hen\u00fcz yeni tasarlanm\u0131\u015f olmas\u0131 daha k\u00fc\u00e7\u00fck community ve daha az tecr\u00fcbe getirmektedir. Bu tecr\u00fcbe yoksunlu\u011fundan kaynakl\u0131 Quartz.NET ve Hangfire’da oldu\u011fu gibi t\u00fcrl\u00fc ihtiya\u00e7 senaryolar\u0131na kar\u015f\u0131 \u00f6rnek olaylar\u0131n bulunabilmesi pek m\u00fcmk\u00fcn de\u011fildir!<\/p>\n
Bundan kaynakl\u0131 TickerQ’nun se\u00e7iminde k\u0131stas\u0131n performans odakl\u0131 de\u011fil, mimarisel yakla\u015f\u0131m odakl\u0131 olmas\u0131 gerekti\u011fine dikkatinizi \u00e7ekerim…<\/p>\n
<\/span>Asp.NET Core’da TickerQ Nas\u0131l Kullan\u0131l\u0131r?<\/span><\/h4>\n
TickerQ’yu scheduling i\u015flemlerinde kullanabilmek i\u00e7in tabi ki de \u00f6ncelikle TickerQ<\/a> k\u00fct\u00fcphanesinin y\u00fcklenmesi ve ard\u0131ndan a\u015fa\u011f\u0131daki yap\u0131land\u0131rma ile projeye entegrasyonu ger\u00e7ekle\u015ftirilmelidir:<\/p>\n
\n
\r\nvar builder = WebApplication.CreateBuilder(args);\r\n\r\nbuilder.Services.AddTickerQ();\r\n\r\nvar app = builder.Build();\r\n\r\n.\r\n.\r\n.\r\n\r\napp.UseTickerQ();\r\n\r\napp.Run();\r\n<\/pre>\n<\/div>\n
Bu temel yap\u0131land\u0131rmadan sonra genel mant\u0131k job tan\u0131mlama ve \u00e7al\u0131\u015ft\u0131rma \u00fczerine kuruludur. Dolay\u0131s\u0131yla en yal\u0131n haliyle a\u015fa\u011f\u0131daki gibi bir job tan\u0131mlamas\u0131n\u0131 ger\u00e7ekle\u015ftirebiliriz:<\/p>\n
\n
\r\n public class OrderJobs\r\n {\r\n [TickerFunction(FunctionNames.SendOrderEmail)]\r\n public async Task SendOrderEmailAsync(TickerFunctionContext<SendOrderEmailRequest> tickerFunctionContext, CancellationToken cancellationToken)\r\n {\r\n await Task.Delay(500, cancellationToken);\r\n\r\n await Console.Out.WriteLineAsync(@$"Sipari\u015f e-postas\u0131 g\u00f6nderildi. Job Id : {tickerFunctionContext.Id}\r\nOrder Id : {tickerFunctionContext.Request.OrderId} | E-posta : {tickerFunctionContext.Request.Email}");\r\n }\r\n }\r\n<\/pre>\n<\/div>\n
Burada dikkat edilirse e\u011fer TickerQ’da tan\u0131mlanan job’lar TickerFunction<\/code> attribute’u ile i\u015faretlenmektedir. TickerQ’nun source generator’\u0131 bu attribute’u compile-time’da ke\u015ffedecektir ve ilgili job’\u0131n dependency injection \u00fczerinden resolve edilmesi ve \u00e7a\u011fr\u0131labilmesi i\u00e7in gerekli olan wiring’i \u00fcretecektir.<\/p>\n
Ard\u0131ndan yap\u0131lmas\u0131 gereken job’\u0131n a\u015fa\u011f\u0131daki gibi \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131d\u0131r:<\/p>\n
\n\r\napp.MapPost("\/orders\/schedule-email", async (SendOrderEmailRequest sendOrderEmailRequest, ITimeTickerManager<TimeTickerEntity> timeTickerManager) =>\r\n{\r\n var result = await timeTickerManager.AddAsync(new TimeTickerEntity\r\n {\r\n Function = FunctionNames.SendOrderEmail,\r\n ExecutionTime = DateTime.UtcNow.AddSeconds(15),\r\n Request = TickerHelper.CreateTickerRequest(sendOrderEmailRequest)\r\n });\r\n\r\n return Results.Ok(new\r\n {\r\n sendOrderEmailRequest.OrderId,\r\n jobId = result.Result?.Id\r\n });\r\n});\r\n<\/pre>\n<\/div>\nDikkat ederseniz \u00e7al\u0131\u015ft\u0131r\u0131lacak job’\u0131n ne zaman \u00e7al\u0131\u015faca\u011f\u0131 da ExecutionTime<\/code> property’siyle belirlenmektedir.<\/a>G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere ilgili endpoint’e istek att\u0131\u011f\u0131m\u0131z zaman job hedeflenen zamanda \u00e7al\u0131\u015ft\u0131r\u0131lacak \u015fekilde yap\u0131land\u0131r\u0131lmaktad\u0131r.<\/p>\n Peki hoca! Belirlenen periyotta bir \u00e7al\u0131\u015fan job nas\u0131l yap\u0131land\u0131rabiliriz?<\/strong><\/em> diye sordu\u011funuzu duyar gibiyim… Diyelim ki her gece saat 02:00’da eski sipari\u015f kay\u0131tlar\u0131 temizlensin. Bunun i\u00e7in a\u015fa\u011f\u0131daki gibi bir job’\u0131n tan\u0131mlanmas\u0131 gerekmektedir:<\/p>\n \n\r\n public class OrderJobs\r\n {\r\n .\r\n .\r\n .\r\n\r\n [TickerFunction(FunctionNames.CleanupOrders, cronExpression: "0 0 2 * * *")]\r\n public async Task CleanupOrdersAsync(TickerFunctionContext<SendOrderEmailRequest> tickerFunctionContext, CancellationToken cancellationToken)\r\n {\r\n await Console.Out.WriteLineAsync(@$"Sipari\u015f temizleme ba\u015flad\u0131. {DateTime.UtcNow}");\r\n\r\n await Task.Delay(500, cancellationToken);\r\n\r\n await Console.Out.WriteLineAsync(@$"Sipari\u015f temizleme tamamland\u0131. {DateTime.UtcNow}");\r\n }\r\n }\r\n<\/pre>\n<\/div>\nBurada, job’a attribute \u00fczerinden tan\u0131mlanm\u0131\u015f olan cronExpression<\/em> ile bu job’\u0131n hangi periyotta bir \u00e7al\u0131\u015faca\u011f\u0131n\u0131 cron format\u0131nda ifade etmekteyiz. Ayr\u0131ca burada dikkat ederseniz e\u011fer attribute \u00fczerinden verilen bu cron de\u011feri ile bu recurring schedule’\u0131 ekstradan herhangi bir yap\u0131land\u0131rmaya gerek duymaks\u0131z\u0131n startup s\u0131ras\u0131nda otomatik seed edebilmekteyiz.<\/p>\n Peki hoca! T\u00fcm \u00e7al\u0131\u015fmada memory kullan\u0131lmaktad\u0131r \u00f6yle de\u011fil mi?<\/strong><\/em> \nEvet, yani bu vaziyette uygulama kapand\u0131\u011f\u0131 taktirde planlanan t\u00fcm i\u015fler kaybolacakt\u0131r. Haliyle Quartz.NET’te yahut Hangfire’da oldu\u011fu gibi TickerQ’yu kullan\u0131rken de bir persistence provider kullan\u0131lmas\u0131 gerekmektedir.<\/p>\nBunun i\u00e7in TickerQ.EntityFrameworkCore<\/a> k\u00fct\u00fcphanesinden istifade edilebilir. Bu k\u00fct\u00fcphane ile ad\u0131 \u00fczerinde TickerQ’ya uygun Entity Framework Core yap\u0131lanmas\u0131nda bulunabilir ve h\u0131zl\u0131ca veritaban\u0131 i\u015flemlerini y\u00fcr\u00fctebiliriz. Tabi veritaban\u0131 i\u015flemleri i\u00e7in de uygun paketin y\u00fcklenmesi gerekecektir. Misal olarak SQL Server kullan\u0131lacaksa Microsoft.EntityFrameworkCore.SqlServer<\/a> paketinin y\u00fcklenmesi gerekmektedir.<\/p>\n \u015eimdi burada yap\u0131lmas\u0131 gereken olduk\u00e7a basittir. \u015e\u00f6yle ki; Program.cs<\/em>‘de a\u015fa\u011f\u0131daki yap\u0131land\u0131rmada bulunulmal\u0131d\u0131r:<\/p>\n \n\r\nbuilder.Services.AddTickerQ(options =>\r\n{\r\n options.AddOperationalStore(efConfiguration =>\r\n {\r\n efConfiguration.UseTickerQDbContext<TickerQDbContext>(optionsAction =>\r\n {\r\n optionsAction.UseSqlServer(builder.Configuration.GetConnectionString("SQLServer"), sqlServerOptionsAction => sqlServerOptionsAction.MigrationsAssembly(typeof(Program).Assembly.GetName().Name));\r\n });\r\n });\r\n});\r\n<\/pre>\n<\/div>\nBu yap\u0131land\u0131rman\u0131n ard\u0131ndan add-migration mig_1<\/code> ve update-database<\/code> talimatlar\u0131n\u0131n verilmesiyle veritaban\u0131 migrate edilmi\u015f olacakt\u0131r.<\/a>Bu yap\u0131land\u0131rmadan sonra a\u015fa\u011f\u0131daki gibi bir \u00e7al\u0131\u015fma neticesinde olu\u015fturulan job veritaban\u0131na kaydedilecek ve uygulama kapansa dahi, daha sonradan aya\u011fa kald\u0131r\u0131ld\u0131\u011f\u0131nda kald\u0131\u011f\u0131 yerden devam edecektir:<\/p>\n \n\r\napp.MapPost("\/orders\/schedule-email\/persistence", async (SendOrderEmailRequest sendOrderEmailRequest, ITimeTickerManager<TimeTickerEntity> timeTickerManager) =>\r\n{\r\n var result = await timeTickerManager.AddAsync(new TimeTickerEntity\r\n {\r\n Function = FunctionNames.SendOrderEmail,\r\n ExecutionTime = DateTime.UtcNow.AddSeconds(5),\r\n Request = TickerHelper.CreateTickerRequest(sendOrderEmailRequest),\r\n Retries = 3,\r\n RetryIntervals = new[] { 30, 120, 600 }\r\n });\r\n\r\n return Results.Ok(new\r\n {\r\n sendOrderEmailRequest.OrderId,\r\n jobId = result.Result?.Id\r\n });\r\n});\r\n<\/pre>\n<\/div>\n<\/a><\/p>\n <\/span>Concurrency Nas\u0131l Sa\u011flan\u0131r?<\/span><\/h4>\nDiyelim ki, ayn\u0131 anda 10.000 sipari\u015f geldi. Ee haliyle t\u00fcm bu sipari\u015flerin email job’\u0131 devreye girecektir ve hepsinin ayn\u0131 anda girmesi ciddi bir darbo\u011faz yaratacakt\u0131r. \u0130\u015fte b\u00f6yle bir durumda TickerQ’da fonksiyon baz\u0131nda concurrency s\u0131n\u0131r\u0131n\u0131 belirleyebilmekte ve sistemi \u00f6l\u00e7eklendirebilmekteyiz. Bunun i\u00e7in TickerFunction<\/code> attribute’unda a\u015fa\u011f\u0131daki gibi maxConcurrency<\/code> parametresini kullanabiliriz:<\/p>\n\n\r\n[TickerFunction(FunctionNames.SendOrderEmail, maxConcurrency: 3)]\r\n<\/pre>\n<\/div>\nBu durumda;<\/p>\n\nsend-order-email #01 \u2500\u2500\u2510 \nsend-order-email #02 \u2500\u2500\u2524 \u2190 3 i\u015flem e\u015fzamanl\u0131 \nsend-order-email #03 \u2500\u2500\u2518 \n \u2502 \n \u25bc \nsend-order-email #04 \u2500\u2500\u2510 \nsend-order-email #05 \u2500\u2500\u2524 \u2190 \u00f6nceki 3’\u00fcn\u00fcn bitmesini bekler \nsend-order-email #06 \u2500\u2500\u2518 \n \u2502 \n \u25bc \nsend-order-email #07 \u2500\u2500\u2510 \nsend-order-email #08 \u2500\u2500\u2524 \u2190 \u00f6nceki 3’\u00fcn\u00fcn bitmesini bekler \nsend-order-email #09 \u2500\u2500\u2518\n<\/div>\n\u015feklinde \u00e7al\u0131\u015fma sergileyecektir.<\/p>\n<\/span>Dashboard Ekleyelim<\/span><\/h4>\nVe son olarak da job’lar\u0131n \u00e7al\u0131\u015fmas\u0131n\u0131 anl\u0131k olarak g\u00f6zlemleyebilece\u011fimiz ve TickerQ’nun en g\u00fczel \u00f6zelliklerinden biri olan Dashboard’un y\u00fcklenmesini ele alal\u0131m. \u0130lk olarak TickerQ.Dashboard<\/a> paketinin y\u00fcklenmesi gerekmekte ve ard\u0131ndan a\u015fa\u011f\u0131daki yap\u0131land\u0131rmalar Program.cs<\/em>‘de ger\u00e7ekle\u015ftirilmelidir:<\/p>\n \n\r\nbuilder.Services.AddTickerQ(options =>\r\n{\r\n .\r\n .\r\n .\r\n\r\n options.AddDashboard(configure => configure.WithBasicAuth(username: "admin", password: "admin"));\r\n options.AddOperationalStore(configurator => configurator.UseTickerQDbContext<TickerQDbContext>(options => options.UseSqlServer(builder.Configuration.GetConnectionString("SQLServer"))));\r\n});\r\n<\/pre>\n<\/div>\nBu yap\u0131land\u0131rmadan sonra https:\/\/localhost:{port}\/tickerq\/dashboard\/<\/em> adresi \u00fczerinden dashboard’a eri\u015febilir ve job’lar\u0131n s\u00fcrecine dair g\u00f6zlemde bulunabiliriz.<\/a><\/a><\/a><\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n \n\n \n\u00d6rnek \u00e7al\u0131\u015fmaya a\u015fa\u011f\u0131daki GitHub reposundan eri\u015febilirsiniz.<\/div>\nhttps:\/\/github.com\/gncyyldz\/TickerQ.Example<\/div>\n<\/p><\/div>\n<\/p><\/div>\n\n Bu repository, ilgili konuya dair \u00f6rnek \u00e7al\u0131\u015fman\u0131n kaynak kodlar\u0131n\u0131 ve mimari yap\u0131s\u0131n\u0131 i\u00e7ermektedir. Detaylar i\u00e7in GitHub \u00fczerinden incelemede bulunabilirsiniz.\n <\/div>\n \n GitHub\u2019da G\u00f6r\u00fcnt\u00fcle \u2192 \n <\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde son d\u00f6nemlerde zamanlanm\u0131\u015f i\u015fler (scheduled jobs) i\u00e7in ciddi \u015fekilde ilgin\u00e7 bir alternatif haline gelmi\u015f olan TickerQ’yu inceleyecek ve \u00f6zellikle Quartz.NET‘in ve Hangfire‘nin y\u0131llard\u0131r \u00e7\u00f6zemedi\u011fi hangi problemlere dair \u00e7\u00f6z\u00fcmlerle geldi\u011fini de\u011ferlendiriyor olaca\u011f\u0131z....<\/p>\n","protected":false},"author":1,"featured_media":28888,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5206,3102],"tags":[2808,1025,5749],"class_list":["post-28864","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-asp-net-core","tag-hangfire","tag-quartz-net","tag-tickerq"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=28864"}],"version-history":[{"count":17,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28864\/revisions"}],"predecessor-version":[{"id":28887,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28864\/revisions\/28887"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28888"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}