როგორ გავუშვათ ფონური სამუშაოები ვებ-აპში: რიგები, დამგეგმავები და cron

ვებ-აპში ფონური სამუშაოების გასაშვებად ჯერ სამუშაო ორ სახეობად გაყავით. ამოქმედებული სამუშაოები (მისასალმებელი ელფოსტის გაგზავნა, ატვირთვის დამუშავება) შეიძლება შეინახოთ სამუშაოების რიგში, ხშირად თქვენი მონაცემთა ბაზის ცხრილში, და გაიშვას worker-ის მიერ განმეორებებით. დაგეგმილი სამუშაოები (ღამის ანგარიში, შეხსენებები ყოველ 15 წუთში) საჭიროებს რაღაცას, რაც დაგეგმილ დროს ჩაირთვება: ჰოსტის cron ფუნქციას ან გარე დამგეგმავს, რომელიც თქვენს აპში დაცულ ენდპოინტს გამოიძახებს. ყოველთვის გააკეთეთ სამუშაოები უსაფრთხო ორჯერ გასაშვებად, ჩაიწერეთ შეცდომები და არასდროს დაეყრდნოთ ტაიმერს სერვერში, რომელიც შეიძლება დაიძინოს ან გადაიტვირთოს.

ეს გზამკვლევი განმარტავს ვარიანტებს, როდის ჯდება თითოეული და როგორ დააყენოთ ისინი AI აპის ამშენებლით, მათ შორის ნულამდე მასშტაბირებად ჰოსტებზე.

რა ჩაითვლება ფონურ სამუშაოდ

ყველაფერი, რაც ნელია, არასანდოა ან მომხმარებლის მყისიერ პასუხს არ სჭირდება:

• ელფოსტების, შეტყობინებებისა და ქვითრების გაგზავნა
• სურათების ზომის შეცვლა, ვიდეოს გადაკოდირება, PDF-ების გენერირება
• ნელი მესამე მხარის API-ების გამოძახება, მათ შორის AI მოდელების გრძელი ამოცანებისთვის
• მონაცემების იმპორტი ან სინქრონიზება სხვა სისტემიდან
• ღამის გასუფთავება, ანგარიშები და შეხსენებები

ეს ყველაფერი მოთხოვნის შიგნით რომ გააკეთოთ, გვერდები ნელი და მყიფე ხდება: თუ ელფოსტის პროვაიდერი გათიშულია, მომხმარებლის რეგისტრაცია ჩაიშლება. ფონში გადატანა ნიშნავს, რომ მომხმარებელი მყისიერ პასუხს იღებს და სამუშაოს განმეორება შეიძლება.

ვარიანტები

ერთი სწორი პასუხი არ არსებობს. პატარა აპს ხშირად სჭირდება მხოლოდ მონაცემთა ბაზის რიგი და გარე დამგეგმავი.

რატომ ცვლის ნულამდე მასშტაბირებადი ჰოსტი სურათს

ბევრი თანამედროვე ჰოსტი აძინებს თქვენს აპს, როცა არავინ იყენებს, და შემდეგ მოთხოვნაზე აღვიძებს. ეს ფულს ზოგავს, მაგრამ ძინავს სერვერი კოდს ვერ გაუშვებს: ტაიმერები არ ირთვება და worker-ები არ ამოწმებენ რიგს. ამ ჰოსტებზე დაგეგმილი სამუშაო შემომავალი მოთხოვნით უნდა დაიწყოს, და ყველაზე მარტივი წყარო ამ მოთხოვნისთვის გარე დამგეგმავია. ყოველი გამოძახება აღვიძებს აპს (და ხშირად მის ბაზასაც), ამიტომ ყოველწუთიერი გამოძახება ყოველ 15 წუთში გამოძახებაზე მეტს ღირს. აირჩიეთ ყველაზე ნელი გრაფიკი, რომელიც საჭიროებას აკმაყოფილებს.

შაბლონი 1: მონაცემთა ბაზის სამუშაოების რიგი

ამოქმედებული სამუშაოებისთვის:

1. შექმენით jobs ცხრილი: ტიპი, payload (JSON), სტატუსი (pending, running, done, failed), მცდელობები, run_after, last_error, დროის ნიშნულები.
2. როცა რაიმე ხდება, ჩასვით სამუშაოს სტრიქონი იმავე ტრანზაქციაში, რაც ცვლილებას იწვევს, რომ ისინი ერთად წარმატდნენ ან ჩავარდნენ.
3. worker იღებს დროული სამუშაოებს, ნიშნავს running-ად, ასრულებს მათ და ნიშნავს done-ად.
4. ჩავარდნისას გაზარდეთ attempts, დააყენეთ run_after უფრო გვიან (მაგალითად 1, 5, შემდეგ 30 წუთი) და შეინახეთ შეცდომა. მაქსიმუმის შემდეგ ნიშნავთ failed-ად და აფრთხილებთ ვინმეს.

თუ ერთდროულად შეიძლება რამდენიმე worker მუშაობდეს, სამუშაოები უსაფრთხოდ უნდა იყოს აღებული. Postgres-ზე SELECT ... FOR UPDATE SKIP LOCKED საშუალებას აძლევს თითოეულ worker-ს აიღოს სხვადასხვა სტრიქონი, კონფლიქტის გარეშე.

ვინ უშვებს worker-ს? მუდმივად ჩართულ სერვერზე — ცალკე პროცესში მარყუჟი. ნულამდე მასშტაბირებად ჰოსტზე შაბლონი 2-ის დაგეგმილი ენდპოინტი შეუძლია ყოველ გამოძახებაზე დაამუშაოს დროული სამუშაოების ბაჩი.

შაბლონი 2: გარე დამგეგმავი, რომელიც თქვენს აპს იძახებს

დაგეგმილი სამუშაოებისთვის:

1. დაამატეთ ენდპოინტი, მაგალითად POST /api/cron/send-reminders.
2. დაიცავით: მოითხოვეთ საიდუმლო ტოკენი სათაურში, შენახული საიდუმლოდ ორივე მხარეს და უარყავით ყველაფერი სხვა.
3. გახადეთ იდემპოტენტური: ერთი და იგივე წუთში ორჯერ გაშვებამ არ უნდა გამოგზავნოს ორი შეხსენება. ჩაიწერეთ, რა გაიგზავნა.
4. შეინარჩუნეთ თითოეული გამოძახება მოკლე: დაამუშავეთ ბაჩი (ვთქვათ, 100 ელემენტი) და შემდეგ გამოძახებაში დანარჩენი აიღეთ.
5. მიუთითეთ დამგეგმავი მისკენ.

დამგეგმავის არჩევანი:

• GitHub Actions დაგეგმილი სამუშაო ნაკადები. უფასოა GitHub-ის გამოყენების ლიმიტებში. 2026 წლის სექტემბრის მდგომარეობით GitHub-ის დოკუმენტაცია ამბობს, რომ უმოკლესი ინტერვალი ყოველ 5 წუთში ერთხელაა, გაშვებები შეიძლება დაგვიანდეს დატვირთულ დროს (განსაკუთრებით ყოველი საათის დასაწყისში), გრაფიკები ნაგულისხმევად UTC-ზეა, ხოლო საჯარო რეპოზიტორიაში დაგეგმილი სამუშაო ნაკადები გამოირთვება, თუ რეპოზიტორიაში 60 დღე აქტივობა არ ყოფილა.
• ჰოსტირებული cron სერვისები. არსებობს ბევრი სერვისი, რომლის ერთადერთი დანიშნულებაა გრაფიკით URL-ის გამოძახება. შეამოწმეთ საიმედოობა, მინიმალური ინტერვალი და შეტყობინებები, სანამ მას დაეყრდნობით.
• თქვენი cloud პროვაიდერის დამგეგმავი. თუ უკვე იყენებთ დიდ cloud პროვაიდერს, მას აქვს მართული დამგეგმავი, რომელსაც შეუძლია HTTPS ენდპოინტის გამოძახება.
• ჰოსტირებული სამუშაო ან workflow სერვისი. ისინი აერთიანებენ დაგეგმვას, რიგებსა და განმეორებებს და თითოეულ ნაბიჯზე თქვენს ენდპოინტებს იძახებენ. ფასები და ლიმიტები შეადარეთ თითოეული მომწოდებლის საიტზე.

შაბლონი 3: დაანდეთ პროვაიდერს

ზოგჯერ საუკეთესო ფონური სამუშაო საერთოდ არ არის საჭირო:

• გადახდები. Stripe ახალ ცდას აკეთებს წარუმატებელ საბაზისო გადახდებზე და აგზავნის webhook-ებს; თქვენ რეაგირებთ, ნაცვლად იმისა, რომ გამოკითხოთ. იხილეთ რა არის webhook.
• ელფოსტა. პროვაიდერები რიგში აყენებენ და ახალ ცდას აკეთებენ მიწოდებისას, როგორც კი შეტყობინებას გადასცემთ.
• მასობრივი AI სამუშაო. OpenAI და Anthropic გთავაზობენ batch API-ებს არაგადაუდებელი მოთხოვნებისთვის, რომლებსაც მოგვიანებით აგზავნით და აგროვებთ.

მოთხოვნები თქვენი AI ამშენებლისთვის

რიგისთვის:

დაამატე ფონური სამუშაოების რიგი ჩვენს მონაცემთა ბაზაში jobs ცხრილით (ტიპი, payload JSON, სტატუსი, მცდელობები, run_after, last_error). როცა მომხმარებელი რეგისტრირდება, ჩასვი send_welcome_email სამუშაო იმავე ტრანზაქციაში, ნაცვლად იმისა, რომ ელფოსტა პირდაპირ გააგზავნო. დაამატე processJobs(limit) ფუნქცია, რომელიც დროულ სამუშაოებს იღებს SELECT ... FOR UPDATE SKIP LOCKED-ით, ატარებს მათ და იმეორებს ჩავარდნებს 1, 5 და 30 წუთის შემდეგ, ხოლო 4 მცდელობის შემდეგ ნიშნავს მათ failed-ად.

დაგეგმილი გამშვებისთვის:

დაამატე POST /api/cron/tick, დაცული bearer ტოკენით საიდუმლოდან CRON_SECRET; უარყავი ყველა მოთხოვნა, რომელსაც ის არ აქვს. ყოველი გამოძახება უშვებს processJobs(100)-ს და აგზავნის ჯავშნის შეხსენებებს, რომლებიც მომდევნო 24 საათში უნდა გაიგზავნოს და ჯერ არ გაგზავნილა, ხოლო გაგზავნილი შეხსენებები ინახება, რომ არაფერი გაიგზავნოს ორჯერ. დააბრუნე JSON შეჯამება იმის შესახებ, რაც გაეშვა. შემდეგ დაწერე GitHub Actions სამუშაო ნაკადი, რომელიც ამ ენდპოინტს ყოველ 15 წუთში გამოიძახებს, URL-ს და ტოკენს კი repository secrets-იდან წაიკითხავს.

გავრცელებული შეცდომები

• setInterval-ზე დაყრდნობა. ის უხმოდ ჩერდება, როცა სერვერი იძინებს ან გადაიტვირთება, და ორმაგდება, როცა ორი ასლი მუშაობს.
• დაუცავი cron ენდპოინტი. ვინც მას იპოვის, შეძლებს თქვენი სამუშაოების ან ელფოსტის გადასახადის გაშვებას.
• არაიდემპოტენტური სამუშაოები. განმეორებები და დუბლირებული დამგეგმავის გამოძახებები მოხდება. დააპროექტეთ მათზე.
• ჩავარდნების უხილავობა. სამუშაო, რომელიც კვირის განმავლობაში უხმოდ ჩავარდება, უარესია, ვიდრე ხმამაღლა ჩავარდნილი. ჩაწერეთ შეცდომები და განმეორებადი ჩავარდნებისას აფრთხილეთ.
• გრძელი გაშვებები ერთ მოთხოვნაში. მოთხოვნები დროს ამოიწურება. დაამუშავეთ ბაჩებად.
• ძალიან ხშირი დაგეგმვა. ნულამდე მასშტაბირებად ჰოსტზე ყოველი გამოძახება აღვიძებს და ახარჯავს აპს. მოარგეთ ინტერვალი რეალურ საჭიროებას.
• დროის სარტყელი. „9 საათი“ სხვადასხვას ნიშნავს თქვენი დამგეგმავისთვის (ხშირად UTC) და თქვენი მომხმარებლებისთვის. შეინახეთ დრო UTC-ში და გადაიყვანეთ თითოეული მომხმარებლისთვის.
• საიდუმლოები სამუშაო ნაკადის ფაილში. ტოკენები დამგეგმავის საიდუმლოების საცავში შეინახეთ. იხილეთ როგორ შევინახოთ API გასაღებები უსაფრთხოდ.

საკონტროლო სია

• ნელი სამუშაო გატანილია მომხმარებლის მოთხოვნებიდან
• სამუშაოები მდგრადად ინახება, არა მხოლოდ მეხსიერებაში
• განმეორებები მზარდი შუალედებით და მაქსიმუმით
• ყოველი სამუშაო უსაფრთხოდ ორჯერ გასაშვებია
• დაგეგმილი ენდპოინტი დაცულია საიდუმლო ტოკენით
• ყოველი გაშვება ამუშავებს შეზღუდულ ბაჩს
• ჩავარდნილი სამუშაოები ხილულია, შეტყობინებებით
• გრაფიკის ინტერვალი შერჩეულია ჰოსტინგის ხარჯის გათვალისწინებით
• დრო შენახულია UTC-ში

ფონური სამუშაოები Mythex-ში

Mythex-ის დოკუმენტაცია არ აღწერს დაგეგმილ ან cron სამუშაოებს, ხოლო გამოქვეყნებული აპები და მათი ბაზები უმოქმედოდ იძინებენ და შემდეგ მოთხოვნაზე იღვიძებენ (იხილეთ ჰოსტინგის ლიმიტები). ამიტომ ნუ დაეყრდნობით ტაიმერებს თქვენს აპში. მუშა მიდგომა არის ზემოთ აღწერილი: აგენტს სთხოვეთ სამუშაოების ცხრილი და ტოკენით დაცული ენდპოინტი, შემდეგ გარე დამგეგმავი მიუთითეთ თქვენს გამოქვეყნებულ URL-ზე. ტოკენი შეინახეთ პროექტის საიდუმლოდ და გაითვალისწინეთ, რომ ყოველი გაღვიძება კრედიტებს ხარჯავს აპისა და ბაზის ღვიძილის დროისთვის, ამიტომ აირჩიეთ გონივრული ინტერვალი. თუ თქვენს აპს ამისთვის API backend სჭირდება, REST API backend რეცეპტი დასაწყისისთვის გამოგადგებათ, ხოლო როგორ ავაშენოთ REST API ენდპოინტების დაპროექტებას ეხება. თუ თქვენი პროდუქტის ბირთვი მუდმივად მომუშავე worker-ები ან ბოტებია, პროცესების მუდმივი გაშვებისთვის შექმნილი ჰოსტი შეიძლება უფრო შესაფერისი იყოს.

კითხვები