Vazifalar navbatlari va balanslash

1) Nima uchun vazifalar navbati

• Front va og’ir quyi tizimlar orasidagi bufer cho’qqilarni tekislaydi.
• SLAni barqarorlashtiradi: ustuvorliklar va yuklama sinflarini izolyatsiya qilish.
• Muvaffaqiyatsizlikka chidamliligini soddalashtiradi: retralar, DLQ, qayta qo’yish.
• Gorizontal miqyosda kattalashtiriladi.

Namunaviy domenlar: to’lovlarni qayta ishlash, notifikatsiyalar, hisobotlar/media yaratish, ETL/ML-postprotsessing, tashqi API bilan integratsiya.

2) Model va asosiy tushunchalar

Prodyuser: vazifani nashr etadi (payload + meta maʼlumotlar: idempotency key, ustuvorlik, muddat).
Navbat/topik: vazifalar buferi/log.
Worker: vazifani oladi, qayta ishlaydi, tasdiqlaydi (ack) yoki xato bilan qaytaradi.
Visibility Timeout/Lease: qayta ishlash vaqtida vazifalarni «ijaraga olish», so’ngra - avto-qayta yetkazib berish.
DLQ (Dead Letter Queue): urinishlar/halokatli xatolar chegarasidan keyin vazifalarni «koʻmish».
Rate Limit/Concurrency: per-vorker/per-navbat/per-tenant iste’moliga cheklovlar.

• Pull: Vorkerning oʻzi vazifani soʻraydi (yukni doza qiladi).
• Push: broker pushit; zaif vorkerlarni «quyishdan» himoya qilish kerak.

3) Yetkazib berish semantikasi va tasdiqnomalar

At-most-once: retrajsiz; tezroq, lekin yo’qotish mumkin.
At-least-once (ko’pgina navbatlar uchun defolt): dublikatlar bo’lishi mumkin → ishlov beruvchining idempotentligi talab qilinadi.
Effectively exactly-once: ilova darajasida erishiladi (idempotentlik, dedup-stor, tranzaksiyalar/autbox). Broker yordam berishi mumkin, lekin «sehrli o’q» emas.

• Ack/Nack: aniq natija.
• Requeue/Retry: с backoff + jitter.
• Poison message: DLQga joʻnatish.

4) Balanslashtirish va rejalashtirish

4. 1 Navbat va algoritmlar

FIFO: sodda va prognoz.
Priority Queue: ustuvor sinflar (P0... P3).
WRR/WSR (Weighted Round-Robin/Random): sinflar orasidagi CPU/cherezput ulushlari.
WFQ/DRR (tarmoqlardagi «adolatli» navbatlar analogi): per-tenant/mijoz ulushlari.
Deadline/EDF: muddatlar bilan vazifalar uchun.
Fair Share: shovqinli qoʻshnilarni cheklash (per-tenant quotas).

4. 2 Ishlov berish oqimlari

Single-flight/Coalescing: vazifaning dublikatlarini birlashtiring.
Concurrency caps: vazifalar/integratsiyalar (tashqi API) turlari bo’yicha parallelizm uchun qattiq limitlar.

4. 3 Geo va shardlash

Shardlar (tenant/id) → ma’lumotlarning lokalligi, shardlar ichidagi barqaror tartib.
Sticky kesh/resurs: «biriktirilgan» holatdagi vorkerlarga xash-routing.

5) Retrai, backoff va DLQ

Eksponensial backoff + jitter:’base 2 ^ attempt ± random’.
Vazifaga maksimal urinishlar va umumiy muddat (time-to-die).
Xatolar tasnifi:’retryable’(tarmoq/limit),’non-retryable’(validatsiya/biznes-taqiq).
Parking/Delay Queue: kechiktirilgan vazifalar (masalan, 15 daqiqadan keyin takrorlash).
DLQ-siyosat: «zaharli» xabar qayerga va qanday shartlarda tushishini albatta ko’rsating; reprocessor.

6) Idempotentlik va deduplikatsiya

• seen → skip/merge/result-cache.
• Natural keys: tasodifiy UUID oʻrniga’order _ id/ payment_id'’dan foydalaning.
• Outbox: biznes-operatsiya bilan bitta DB-tranzaksiyada vazifa faktini va uning maqomini yozish.
• Sinkdagi Exactly-once: «UPSERT» kaliti bo’yicha, versiyalarni tekshirish, navbatdagi «at-least-once» + DBdagi idempotentlik.

7) Multi-tenantlik va SLA sinflari

Navbat/oqimlarni’critical’,’standard’,’bulk’sinflariga ajrating.
Per-tenant kvotalari va ustuvorliklari (Gold/Silver/Bronze).
Izolyatsiya: P0 ostidagi vorkerlarning dedicate-pullari; fonli - alohida klasterda/nodlarda.
Admission control: iloji boricha muddatsiz qabul qilmaslik.

8) Vorkerlarning avtoskeylingi

Skeyling uchun metriklar: queue depth, arrival rate, processing time, SLA-muddatlar.
KEDA/Horizontal Pod Autoscaler: SQS/Rabbit/Kafka lag.
To’xtatuvchi omillar: tashqi API rate limits, ma’lumotlar bazasi (orqa qismini yo’q qilmang).

9) Texnologik variantlar va patternlar

9. 1 RabbitMQ/AMQP

Exchanges: direct/topic/fanout; Queues с ack/ttl/DLQ (dead-letter exchange).
Prefetch (QoS) «vorkerda qancha vazifalarni» boshqaradi.

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.failed x-message-ttl=60000

9. 2 SQS (va analoglari)

Visibility Timeout, DelaySeconds, RedrivePolicy (DLQ).
Idempotentlik - ilovada (dedup-jadval).
Limitlar: batchi 1-10 ta xabar; idempotent ko’kraklarga e’tibor bering.

9. 3 Kafka/NATS JetStream

Masshtabli payplaynlar uchun: yuqori o’tkazish, retenshn/replay.
Task-log ustidagi navbat: bitta vazifa = bitta xabar; partiyalashtirish/subject orqali «bitta vorker» ni nazorat qilish.
Retralar: alohida topiklar/subject-qoʻshimchalar bilan backoff.

9. 4 Redis-navbatlar (Sidekiq/Resque/Bull/Celery-Redis)

Juda past latentlik; (RDB/AOF), retry kalitlari va single-flight uchun lock-keys.
«Oson» vazifalar uchun mos keladi, uzoq muddatli retenshn uchun emas.

9. 5 Fraymvorkalar

Celery (Python), Sidekiq (Ruby), RQ/BullMQ (Node), Huey/Resque - tayyor retralar, jadvallar, middleware, metriklar.

10) Yo’naltirish va balanslash sxemalari

Round-Robin: bir tekis, ammo vazifalarning «og’irligini» hisobga olmaydi.
Weighted RR: vorker/hovuz quvvati bo’yicha taqsimlash.
Fair/Backpressure-aware: worker yangi vazifani faqat tayyor boʻlsagina oladi.
Priority lanes: sinfga alohida navbatlar; vorkerlar agar mavjud bo’lsa [P0 →... → Pn] tartibida o’qiydilar.
Hash-routing:’hash (key)% shards’- stateful/keshlash uchun.

11) Taymautlar, muddatlar va SLA

Per-task timeout: ishning ichki «ijara» (vorker kodida) ≤ brokerning Visibility Timeout.
Global deadline: vazifa T vaqtidan keyin mantiqiy emas - NACK → DLQ.
Budget-aware: muddat yaqinlashganda (brownout) ishni qisqartiring (qisman natijalar).

12) Kuzatuv va boshqaruv

12. 1 Metrika

`queue_depth`, `arrival_rate`, `service_rate`, `lag` (Kafka), `invisible_messages` (SQS).
`success/failed/retired_total`, `retry_attempts`, `dlq_in_total`, `processing_time_ms{p50,p95,p99}`.
`idempotency_hit_rate`, `dedup_drops_total`, `poison_total`.

12. 2 Logi/treysing

Korrelyatsiya:’job _ id’,’correlation _ id’, deduplikatsiya kaliti.
’retry/backoff/dlq’ ni hodisa sifatida belgilang; dastlabki so’rovning spanidan linkovka qilish.

12. 3 Dashbord/alert

Triggerlar: chuqurlik> X, p99> SLO, DLQ balandligi, «yopishgan» vazifalar (visibility> N), «issiq» kalitlar.

13) Xavfsizlik va muvofiqlik

Ijarachilarni izolyatsiya qilish: alohida navbatlar/kalitlar, ACL, kvotalar.
Transportda shifrlash va/yoki «tinch».
payload da PII-minimallashtirish; xom PII o’rniga xesh/ID.
Sirlar: vazifalar tanasiga tokenlarni qoʻymaslik, vault/refs dan foydalanish.

14) Anti-patternlar

Idempotentsiz retraylar → ikki marta operatsiyalar/pul «ikki marta».
Bitta ulkan «hamma narsa uchun» navbat → izolyatsiya yo’q, oldindan aytib bo’lmaydigan kechikishlar.
DLQ’siz cheksiz retrajlar → abadiy zaharli vazifalar.
Visibility Timeout <ishlash vaqti → kaskadli dublikatlar.
Navbatdagi katta payload → tarmoq/xotirani bosadi; obyekt storasida saqlash va havolani uzatish yaxshiroqdir.
Backpressure bo’lmagan push-model → vorkerlar bo’g’ilib qoladi.
Tanqidiy va bulk-vazifalarni bir hovuzda aralashtirish.

15) Joriy etish chek-varaqasi

• Vazifalarni SLA (P0/P1/P2) va hajm boʻyicha tasniflang.
• Kerakli semantika va retenshn bilan broker/framvorkni tanlang.
• Kalitlar, ustuvorliklar va marshrutlarni loyihalashtiring (hash/shards/priority lanes).
• Backoff + jitter retrajlarini va DLQ siyosatini yoqing.
• Idempotentlikni amalga oshiring (kalitlar, upsert, TTL bilan dedup-stor).
• Taymautlarni moslash: per-task, visibility, umumiy muddat.
• Concurrency va rate integratsiyalarini cheklang.
• Signal bilan chuqurlik/lag bo’yicha avtoskeyling.
• Metriklar/treysing/alertlar; runbooks «bo’ron» va DLQ to’kilishi.
• Feyl testlari: vorkerning yiqilishi, «zaharli» xabar, ortiqcha yuk, uzoq vazifalar.

16) Konfiguratsiyalar va kod namunalari

16. 1 Celery (Redis/Rabbit) - asosiy flow

python app = Celery("jobs", broker="amqp://...", backend="redis://...")
app.conf.task_acks_late = True        # ack после выполнения app.conf.broker_transport_options = {"visibility_timeout": 3600}
app.conf.task_default_retry_delay = 5 app.conf.task_time_limit = 300        # hard timeout

@app.task(bind=True, autoretry_for=(Exception,), retry_backoff=True, retry_jitter=True, max_retries=6)
def process_order(self, order_id):
if seen(order_id): return "ok"      # идемпотентность do_work(order_id)
mark_seen(order_id)
return "ok"

16. 2 RabbitMQ — DLQ/TTL

ini x-dead-letter-exchange=dlx x-dead-letter-routing-key=jobs.dlq x-message-ttl=600000   # 10 минут x-max-priority=10

16. 3 Kafka - darajalar bo’yicha retralar

orders -> orders.retry.5s -> orders.retry.1m -> orders.dlq

(Kechiktirilgan yetkazib berish bilan scheduler/cron-consumer.)

16. 4 NATS JetStream — consumer с backoff

bash nats consumer add JOBS WORKERS --filter "jobs.email" \
--deliver pull --ack explicit --max-deliver 6 \
--backoff "1s,5s,30s,2m,5m"

17) FAQ

Q: Pullga qarshi push ni qachon tanlash kerak?
A: Pull tabiiy backpressure va «halol» muvozanatni beradi; push past tezlikda va minimal TTFB kerak bo’lganda osonroq, lekin cheklovlarni talab qiladi.

Q: Qanday qilib «issiq» kalitdan qochish mumkin?
A: Tarkibiy kalit bo’yicha shard qiling (’order _ id% N’), bufer va batch-ishlov bering, per-kalit limitlarini kiriting.

Q: «exactly-once» bo’lishi mumkinmi?
A: Amalda - idempotentlik va tranzaksion autboks orqali. To’liq «matematik» exactly-once yo’lda kamdan-kam hollarda erishish mumkin va qimmat.

Q: Katta qo’yilmalarni qayerda saqlash kerak?
A: Obyekt omborida (S3/GCS), vazifada esa - havola/ID; broker va tarmoqqa bosimni kamaytiradi.

Q: TTL/visibility ni qanday tanlash kerak?
A: Visibility ≥ p99 qayta ishlash vaqti × zaxirasi 2-3 ×. TTL vazifalari - biznes muddati kamroq.

18) Yakunlar

Navbatlarning kuchli tizimi - bu yetkazib berish semantikasi, ustuvorlik va cheklovlar o’rtasidagi muvozanatdir. Kalitlar va yo’nalishlarni loyihalashtiring, idempotentlikni, backoff va DLQ retrajlarini ta’minlang, resurslarni SLA sinflariga taqsimlang va metriklarga rioya qiling. Shunda sizning fon jarayonlaringiz oldindan aytib bo’ladigan, barqaror va miqyosli bo’ladi - cho’qqilar ostida kutilmagan hodisalarsiz.