Веб аппд дэвсгэр ажлыг хэрхэн ажиллуулах вэ: дараалал, товлогч ба cron

Веб аппд дэвсгэр ажлыг ажиллуулахын тулд эхлээд ажлыг хоёр төрөлд хуваа. Өдөөгдсөн ажлууд (тавтай морилно уу имэйл илгээх, байршуулсан файлыг боловсруулах) нь ажлын дараалал-д, ихэвчлэн таны өгөгдлийн сан дахь хүснэгтэд хадгалагдаж, дахин оролдлоготой worker-оор боловсруулагдана. Товлогдсон ажлууд (өдөр тутмын тайлан, 15 минут тутмын сануулга) цагийн хуваарьт гал авах зүйл хэрэгтэй: хостын cron функц эсвэл таны аппын хамгаалагдсан endpoint-г дуудах гадны товлогч. Үргэлж ажлыг давтан ажиллахад аюулгүй болгож, алдааг бүртгэж, унтаж эсвэл дахин асаж болох сервер дотор таймерт хэзээ ч найдуулахгүй бай.

Энэ гарын авлага сонголтуудыг, аль нь хэзээ тохирохыг, мөн AI аппын бүтээгчтэй тэдгээрийг хэрхэн тохируулахыг тайлбарлана, түүний дотор тэг хүртэл буулгадаг хостууд дээр.

Дэвсгэр ажил гэж юуг хэлэх вэ

Удаан, найдваргүй, эсвэл хэрэглэгчийн шууд хариунд шаардлагагүй аливаа ажил:

• Имэйл болон түлхэх мэдэгдэл илгээх
• Зураг хэмжээсэлэх, видео хөрвүүлэх, PDF бэлтгэх
• Удаан гуравдагч талын API дуудах, урт ажилд AI загвар орно
• Өөр системээс өгөгдөл импортлох эсвэл синк хийх
• Шөнийн цэвэрлэгээ, тайлан, сануулга

Хүсэлтийн дотор ийм ажил хийвэл хуудас удаашралтай, мөртлөө эвдрэлд өртөмтгий болдог: имэйлийн үйлчилгээ унтарвал хэрэглэгчийн бүртгэл ч бүтэлгүйтэнэ. Дэвсгэрт шилжүүлбэл хэрэглэгч шууд хариу авч, ажил дахин оролдогдож болно.

Сонголтууд

Нэг зөв хариулт байдаггүй. Жижиг апп ихэвчлэн өгөгдлийн сангийн дараалал плюс гадны товлогч хэрэгтэй.

Scale-to-zero хостууд яагаад өөрчилдөг вэ

Олон орчин үеийн хостууд хэн ч ашиглаагүй үед аппыг унтуулж, дараагийн хүсэлтээр сэрээдэг. Энэ нь мөнгө хэмнэдэг ч унтаж буй сервер код ажиллуулдаггүй: таймерууд гал авдаггүй, worker-ууд санал авдаггүй. Эдгээр хостууд дээр товлогдсон ажил ирж буй хүсэлтээр эхлэх ёстой бөгөөд хамгийн хялбар эх сурвалж нь гадны товлогч юм. Дуудлага бүр аппыг (ихэвчлэн өгөгдлийн санг хамт) сэрээдэг тул минут тутам дуудвал 15 минут тутмын дуудлагаас илүү зардалтай. Шаардлагыг хангах хамгийн удаан хуваарийг сонго.

Хэв маяг 1: Өгөгдлийн сангийн ажлын дараалал

Өдөөгдсөн ажлуудад:

1. jobs хүснэгт үүсгэ: төрөл, payload (JSON), статус (pending, running, done, failed), attempts, 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-ийг юу ажиллуулдаг вэ? Үргэлж ажилладаг серверт — тусдаа процесс дотор loop. Scale-to-zero хостод — Хэв маяг 2-ын товлогдсон endpoint нь дуудлага бүр дээр хугацаа болсон ажлын багцыг боловсруулж чадна.

Хэв маяг 2: Таны аппыг дуудах гадны товлогч

Товлогдсон ажлуудад:

1. POST /api/cron/send-reminders шиг endpoint нэм.
2. Хамгаалах: толгой дахь нууц токен шаардаж, хоёр талд нууц болгон хадгал, өөр бүх зүйлийг татгалз.
3. Идемпотент болго: нэг минутанд хоёр удаа ажиллахад хоёр сануулга илгээхгүй байх ёстой. Юу илгээсэнээ бүртгэ.
4. Дуудлага бүрийг богино байлга: багц (жишээ нь 100 зүйл) боловсруул, дараагийн дуудлага үлдсэнийг авна.
5. Товлогчийг түүн рүү чиглүүл.

Товлогчийн сонголтууд:

• GitHub Actions товлогдсон workflow. GitHub-ийн ашиглалтын хязгаарт үнэгүй. GitHub-ийн баримтад 2026 оны 9-р сарын байдлаар хамгийн богино интервал 5 минут тутамд нэг удаа, ажлууд ачаалалтай үед (ялангуяа цаг бүрийн эхэнд) саатаж болно, хуваарь нь анхдагчаар UTC, нийтийн репозиторид товлогдсон workflow нь репозиторийн үйл ажиллагаагүй 60 хоногийн дараа идэвхгүй болдог гэж заасан.
• Удирдсан cron үйлчилгээ. Цорын ганц ажил нь цагийн хуваарьт URL дуудах олон үйлчилгээ байдаг. Хамаарлаас өмнө найдвартай байдал, хамгийн бага интервал, сэрэмжлүүлгийг шалга.
• Таны үүлэн үйлчилгээ үзүүлэгчийн товлогч. Том үүлэн үйлчилгээ ашигладаг бол HTTPS endpoint дуудах удирдсан товлогчтой байх болно.
• Удирдсан ажил эсвэл workflow үйлчилгээ. Эдгээр нь товлолт, дараалал, дахин оролдлогыг нэгтгэж, алхам бүрт таны endpoint-уудыг дуудна. Үнэ, хязгаарыг үйлчилгээ нийлүүлэгч бүрийн сайтаас харьцуул.

Хэв маяг 3: Нийлүүлэгчид хийлгэ

Заримдаа хамгийн сайн дэвсгэр ажил огт байдаггүй:

• Төлбөр. Stripe бүтэлгүйтсэн захиалгын төлбөрийг дахин оролдож, webhook илгээдэг; та санал авах биш, хариу үйлдэл хийдэг. Webhook гэж юу вэ харна уу.
• Имэйл. Нийлүүлэгчид мессежийг хүлээж, хүргэлтийг дараалуулж, дахин оролддог — та мессежээ өгсний дараа.
• Олноор AI ажил. OpenAI болон Anthropic нь яаралтай бус хүсэлтэд зориулсан batch API-уудтай, та илгээж, дараа нь цуглуулна.

AI бүтээгчдээ өгөх запросууд

Дарааллын хувьд:

Манай өгөгдлийн санд jobs хүснэгтээр (төрөл, payload JSON, статус, attempts, run_after, last_error) дэвсгэр ажлын дараалал нэм. Хэрэглэгч бүртгүүлэх үед send_welcome_email ажлыг шууд имэйл илгээхийн оронд ижил гүйлгээнд оруул. processJobs(limit) функц нэм: хугацаа болсон ажлуудыг SELECT ... FOR UPDATE SKIP LOCKED-оор авч, ажиллуулж, бүтэлгүйтвэл 1, 5, 30 минутын дараа дахин оролдож, 4 оролдлогын дараа failed гэж тэмдэглэ.

Товлогдсон өдөөлтийн хувьд:

POST /api/cron/tick-ийг CRON_SECRET нууцаас авсан bearer токеноор хамгаал; токенгүй хүсэлт бүрийг татгалз. Дуудлага бүр processJobs(100)-г ажиллуулж, дараагийн 24 цагт явах, илгээгээгүй захиалгын сануулгуудыг илгээж, илгээсэн сануулгыг бүртгэж, хэн ч хоёр удаа илгээхгүй байлга. Ажлын JSON хураангуйг буцаа. Дараа нь энэ endpoint-г 15 минут тутам дуудах GitHub Actions workflow бич, URL болон токенийг репозиторийн нууцаас уншина.

Түгээмэл алдаанууд

• setInterval-д найдах. Сервер унтахад эсвэл дахин асахад дуугүй зогсож, хоёр хуулбар ажиллахад давхардана.
• Хамгаалалтгүй cron endpoint. Хэн ч олж, таны ажлуудыг эсвэл имэйлийн нэхэмжлэхийг өдөөж чадна.
• Идемпотент биш ажлууд. Дахин оролдлого болон давхардсан товлогчийн дуудлага ирэх нь гарцаагүй. Үүнд зориулж загварчлаарай.
• Бүтэлгүйтлийг харах боломжгүй байх. Долоо хоног дуугүй бүтэлгүйтсэн ажил нь чимээтэй бүтэлгүйтсэнээс муу. Алдааг бүртгэж, давтагдсан бүтэлгүйтэлд сэрэмжлүүл.
• Нэг хүсэлтэд урт ажил. Хүсэлт хугацаа дуусдаг. Багцаар боловсруул.
• Хэт олон удаа товлох. Scale-to-zero хост дээрх дуудлага бүр аппыг сэрээж, төлбөр бодуулдаг. Интервалаа хэрэгцээндээ тааруул.
• Цагийн бүс. «9 цаг» таны товлогч (ихэвчлэн UTC) болон хэрэглэгчдэд өөр утгатай. Цагийг UTC-ээр хадгалж, хэрэглэгч бүрт хөрвүүл.
• Нууц workflow файлд. Токеныг товлогчийн нууцын санд байлга. API түлхүүрээ хэрхэн аюулгүй байлгах вэ харна уу.

Жагсаалт

• Удаан ажлуудыг хэрэглэгчийн хүсэлтээс гаргасан
• Ажлууд санах ойд биш, найдвартай хадгалагдсан
• Дахин оролдлого нэмэгдэх хугацаатай, дээд хязгаартай
• Ажил бүр хоёр удаа ажиллахад аюулгүй
• Товлогдсон endpoint нууц токеноор хамгаалагдсан
• Ажиллалт бүр хязгаарлагдсан багцыг боловсруулдаг
• Бүтэлгүйтсэн ажил харагдаж, сэрэмжлүүлэгтэй
• Товлолтын интервалыг хостын зардлыг харгалзан сонгосон
• Цагийг UTC-ээр хадгалдаг

Mythex дээрх дэвсгэр ажил

Mythex-ийн баримт бичигт товлогдсон эсвэл cron ажлыг тайлбарлаагүй, мөн нийтэлсэн апп болон түүний өгөгдлийн сан ажиллахгүй үед унтаж, дараагийн хүсэлтээр сэрдэг (Хостингийн хязгаарлалт харна уу). Тиймээс аппын дотор таймер найдахгүй. Ажилладаг арга бол дээрх: агентаас ажлын хүснэгт болон токеноор хамгаалагдсан endpoint хүс, дараа нь гадны товлогчийг нийтэлсэн URL руугаа чиглүүл. Токеныг төслийн нууц болгон хадгал, мөн дуудлага бүр аппыг болон өгөгдлийн санг сэрээж кредит зарцуулдгийг санаарай, тиймээс боломжийн интервал сонго. Таны апп энэ зорилгоор API backend хэрэгтэй бол REST API backend жор эхлэх цэг болно, мөн REST API хэрхэн бүтээх вэ хуудас endpoint-уудыг зохион бүтээхийг тайлбарлана. Таны бүтээгдэхүүний үндэс нь үргэлж ажилладаг worker эсвэл бот бол үргэлжлэх процессуудад зориулсан хост илүү тохиромжтой байж магадгүй.

Асуултууд