Schemalagda och periodiska jobb med Celery Beat

Fasta intervall är grova. För riktig kalenderlogik — ”varje vardag klockan 07:30” — använder ni celery.schedules.crontab. Den följer Unix crons fält: minute, hour, day_of_week, day_of_month, month_of_year.

• crontab(minute=0, hour=0) — midnatt varje dag.
• crontab(minute="*/15") — var 15:e minut.
• crontab(hour=7, minute=30, day_of_week="1-5") — 07:30 måndag–fredag.

Fält som inte anges får standardvärdet * (alla värden), precis som på en crontab-rad.

Varje schemapost kan innehålla argument och alternativ för det enskilda anropet. Använd args (positionsargument) eller kwargs (namngivna argument) för att parametrera samma task på olika sätt i olika poster. Med dict-objektet options kan ni dirigera en periodisk task till en specifik queue, ange expires eller åsidosätta prioriteten.

expires är viktigt för periodiska jobb: om Beat lägger en task i kön men workers har mycket att göra kastas ett utgånget meddelande bort i stället för att köras för sent och byggas på i kön.

I stället för ett enda stort beat_schedule-dict kan ni registrera poster nära taskerna med signalen on_after_configure och app.add_periodic_task. Då hålls schemat nära koden som det utlöser och ni undviker inaktuella strängsökvägar.

add_periodic_task(schedule, signature, name=...) tar först intervallet eller crontab-uttrycket och därefter task-signaturen. Ni kan skicka task.s(arg) för att bädda in argument.

Som standard tolkar Celery crontab-tider i UTC. Om ni skriver crontab(hour=7) och förväntar er lokal tid 07:00 körs jobbet vid fel klockslag. Ange alltid tidszonen uttryckligen och fatta detta beslut medvetet.

• timezone — den zon som crontab-tiderna utvärderas i.
• enable_utc=True — behåll interna tidsstämplar i UTC (rekommenderas) samtidigt som crontab-uttryck utvärderas i den valda timezone.

Fastställ tidszonen i konfigurationen så att alla utvecklare och servrar använder samma, oavsett värdens lokala TZ.

Ni startar schemaläggaren som en egen process. Standardschemaläggaren sparar tillståndet för ”senaste körningen” i en liten fil, så att den inte kör om allt efter en omstart.

• celery -A app beat -l info — kör Beat.
• --schedule /var/run/celerybeat-schedule — anger var shelve-tillståndsfilen finns.
• Ni kan köra worker och Beat tillsammans i utvecklingsmiljö med celery -A app worker -B, men använd aldrig -B i produktion — då kopplas klockan till en enda workers livscykel.

I produktion ska ni köra exakt en Beat-process. Två Beats innebär att varje periodisk task körs två gånger.

Ni kan skala workers horisontellt till dussintals pods, och Celery hanterar det: brokern distribuerar varje köat meddelande till exakt en worker. Men Beat är klockan, och ni måste bara köra en klocka.

Om två Beat-processer körs avgör var och en självständigt att en task ska köras och publicerar den. Därför ser prenumeranter dubbla körningar. Vanliga sätt detta råkar hända på är:

• Två repliker av en pod som båda startar beat.
• Att använda worker -B och sedan skala den worker-distributionen till 2 eller fler repliker.

Åtgärd: använd en dedikerad Beat-Deployment med replicas: 1, separat från den worker-Deployment som ni skalar fritt.

Även med en enda Beat uppstår dubbletter — en omstart av Beat i fel sekund, en återleverans från en broker som levererar minst en gång eller ett operatörsfel. Det robusta skyddet är att göra periodiska tasks idempotenta: att köra dem två gånger ska ha samma effekt som att köra dem en gång.

Ett enkelt mönster är ett kortlivat distribuerat lås i Redis med SET NX och en sluttid. Den som får låset utför arbetet; samtidiga eller dubbla körningar hoppar säkert över det.

Standardschemaläggaren som använder en fil innebär att ni måste ändra kod och starta om Beat för att ändra ett schema. För dynamiska scheman behöver ni en backendlagring som ni kan redigera under körning.

• RedBeat — sparar scheman i Redis och passar utmärkt för en FastAPI-stack som endast använder Redis. Ange beat_scheduler = "redbeat.RedBeatScheduler".
• django-celery-beat — sparar poster i SQL-tabeller som kan redigeras via ett admin-gränssnitt.

RedBeat tillhandahåller också ett Redis-baserat lås, så att endast en schemaläggare är aktiv om ni råkar starta två Beats — ett skydd för regeln om en enda klocka.

För att skapa en intuitiv förståelse av vad Beat gör vid varje tidsintervall kommer här en liten fristående simulering: givet en lista med cron-liknande jobb (intervall i sekunder och en tidsstämpel för senaste körningen) avgör den vilka som ska köras nu. Detta är kärnloopen som Beat utför — jämför ”nu” med ”nästa körning” — utan någon broker.

Ni kan nu schemalägga återkommande arbete med Celery Beat:

• Beat schemalägger, workers kör — Beat publicerar förfallna uppgifter till meddelandeförmedlaren; en Beat, många workers.
• Scheman finns i beat_schedule eller via add_periodic_task; använd timedelta för intervall och crontab() för kalenderlogik.
• Args/alternativ per post parameteriserar uppgifter och anger queue/expires för att undvika ansamling av inaktuella uppgifter.
• Tidszoner är UTC som standard — ange uttryckligen timezone + enable_utc.
• Endast en klocka — använd aldrig worker -B i produktion; kör en enda dedikerad Beat-replik.
• Idempotens (Redis-lås med SET NX) skyddar mot duplicerade eller återlevererade körningar.
• RedBeat / django-celery-beat ger redigerbara, beständiga och låsskyddade scheman under körning.