Vəzifə növbələri və balans

1) Niyə vəzifə növbələri

• Zirvələri hamarlaşdırır: ön və ağır alt sistemlər arasındakı bufer.
• SLA sabitləşdirir: prioritetlər və yük siniflərinin izolyasiyası.
• Uğursuzluğa davamlılığı asanlaşdırır: retralar, DLQ, təkrar istehsal.
• Üfüqi olaraq ölçülür: API dəyişdirmədən işçilər əlavə edin.

Standart domenlər: ödənişlərin emalı, notifikasiyalar, hesabatların/medianın yaradılması, ETL/ML post-prosessinq, xarici API-lərlə inteqrasiya.

2) Model və əsas anlayışlar

Prodüser: tapşırığı dərc edir (payload + metadata: idempotency key, prioritet, son tarix).
Növbə/topik: tampon/log tapşırıqları.
Worker: tapşırıq alır, emal edir, təsdiq (ack) və ya səhv ilə qaytarır.
Visibility Timeout/Lease: emal zamanı «icarə» vəzifələri, sonra - avto reduksiya.
DLQ (Dead Letter Queue): cəhdlər/ölümcül səhvlər limitindən sonra tapşırıqların «basdırılması».
Rate Limit/Concurrency: per-worker/per-line/per-tenant istehlak məhdudiyyətləri.

• Pull: Vorker özü tapşırığı tələb edir (yükü doza edir).
• Push: broker pushit; zəif işçilərin «doldurulmasından» qorunmaq lazımdır.

3) Çatdırılma semantikası və təsdiqləri

At-most-once: retrajsız; daha sürətli, lakin mümkün itki.
At-least-once (əksər növbələr üçün defolt): dublikatlar mümkündür → prosessor idempotentliyi tələb olunur.
Effectively exactly-once: tətbiq səviyyəsində əldə edilir (idempotentlik, dedupstore, əməliyyatlar/autbox). Broker kömək edə bilər, lakin «sehrli güllə» deyil.

• Ack/Nack: aydın nəticə.
• Requeue/Retry: с backoff + jitter.
• Poison message: DLQ-yə göndərmə.

4) Balans və planlaşdırma

4. 1 Sıra və alqoritmlər

FIFO: sadə və proqnozlaşdırıla bilən.
Priority Queue: prioritet siniflər (P0... P3).
WRR/WSR (Weighted Round-Robin/Random): siniflər arasında CPU/çerezput payları.
WFQ/DRR (şəbəkələrdə «ədalətli» növbələrin analoqu): per-tenant/müştəri payları.
Deadline/EDF: Limitli tapşırıqlar üçün.
Fair Share: «səs-küylü qonşuların» məhdudlaşdırılması (per-tenant quotas).

4. 2 Emal axını

Single-flight/Coalescing: açar tapşırığının təkrarlarını birləşdirin.
Concurrency caps: tapşırıq/inteqrasiya növlərinə (xarici API) görə paralellik üçün sərt limitlər.

4. 3 Geo və Şardlaşdırma

Şardlar açar (tenant/id) → məlumatların lokallığı, şardlar daxilində sabit nizam.
Sticky Caches/Resources: «bağlı» vəziyyəti ilə workers hash-routing.

5) Retray, backoff və DLQ

Eksponent backoff + jitter: 'base 2 ^ attempt ± random'.
Maksimum cəhd və ümumi son tarix (time-to-die).
Səhvlərin təsnifatı: 'retryable' (şəbəkə/limit), 'non-retryable' (validasiya/biznes qadağası).
Parking/Delay Queue: gecikmiş vəzifələr (məsələn, 15 dəqiqə sonra təkrar).
DLQ siyasəti: «zəhərli» mesajın hara və hansı şərtlərlə gəldiyini qeyd edin; reprocessor təmin edin.

6) İdempotentlik və duplikasiya

• seen → skip/merge/result-cache.
• Natural keys: təsadüfi UUID əvəzinə 'order _ id/ payment_id' istifadə edin.
• Outbox: tapşırıq faktını və onun statusunu biznes əməliyyatı ilə bir DB əməliyyatında qeyd edin.
• Sinkdə Exactly-once: «UPSERT» açar, versiyaların yoxlanılması, növbədə «at-least-once» + DB-də idempotentlik.

7) Çox tenant və SLA sinifləri

Növbələri/axınları siniflərə bölün: 'critical', 'standard', 'bulk'.
per-tenant kvotaları və prioritetləri (Gold/Silver/Bronze).
İzolyasiya: P0 altında dedicate hovuzları; fon - ayrı bir klasterdə/nodlarda.
Admission control: Müddətdən artıq qəbul etməyin.

8) Avtoskeylinq oxucuları

Skeylinq üçün metriklər: queue depth, arrival rate, processing time, SLA müddəti.
KEDA/Horizontal Pod Autoscaler: SQS/Rabbit/Kafka lag dərinliyində tetikləyicilər.
Maneə törədən faktorlar: xarici API rate limits, verilənlər bazası (arxa planı məhv etməyin).

9) Texnoloji variantlar və nümunələr

9. 1 RabbitMQ/AMQP

Exchanges: direct/topic/fanout; Queues с ack/ttl/DLQ (dead-letter exchange).
Prefetch (QoS) «nə qədər iş tapşırığını» tənzimləyir.

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

9. 2 SQS (və analoqları)

Visibility Timeout, DelaySeconds, RedrivePolicy (DLQ).
İdempotentlik - tətbiqdə (dedup cədvəl).
Limitlər: 1-10 mesaj batches; İdempotent çəngəllərə diqqət yetirin.

9. 3 Kafka/NATS JetStream

Böyük miqyaslı paylaynlar üçün: yüksək keçid, retenshn/replay.
Log üzərində Task-növbə: bir vəzifə = bir mesaj; partizan/subject vasitəsilə «açar üçün bir worker» nəzarət.
Retrailer: backoff ilə ayrı-ayrı topiklər/subject şəkilçiləri.

9. 4 Redis-növbələr (Sidekiq/Resque/Bull/Celery-Redis)

Çox aşağı gecikmə; davamlı (RDB/AOF), retry açarları və single-flight üçün lock-keys.
Uzun müddətli retenshn üçün deyil, «yüngül» vəzifələr üçün uyğundur.

9. 5 Frameworks

Celery (Python), Sidekiq (Ruby), RQ/BullMQ (Node), Huey/Resque - hazır retrajlar, cədvəllər, orta ölçü, metriklər.

10) Marşrut və balans sxemləri

Round-Robin: bərabər, lakin vəzifələrin «ağırlığı» nəzərə alınmır.
Weighted RR: işçilərin/hovuzun gücünə görə paylanması.
Fair/Backpressure-aware: worker yalnız hazır olduqda yeni bir vəzifə alır.
Priority lanes: sinif üçün ayrı-ayrı növbələr; Vorkers [P0 →... → Pn] qaydasında oxuyur.
Hash-routing: 'hash (key)% shards' - stateful/cached emal üçün.

11) Taymautlar, müddətlər və SLA

Per-task timeout: daxili «icarə» iş (worker kodu) ≤ broker Visibility Timeout.
Global deadline: T vaxt sonra problem mənası yoxdur - NACK → DLQ.
Budget-aware: Bir müddət (qismən nəticələr) yaxınlaşdıqda (brownout) işinizi azaltın.

12) Müşahidə və nəzarət

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 Log/Trace

Korrelyasiya: 'job _ id', 'correlation _ id', deduplikasiya açarı.
Hadisə kimi 'retry/backoff/dlq' qeyd edin; span ilkin sorğu ilə linking.

12. 3 Daşbordlar/Alertlər

Tetikləyicilər: dərinlik> X, p99> SLO, DLQ böyüməsi, «bitmiş» tapşırıqlar (visibility> N), «isti» açarlar.

13) Təhlükəsizlik və uyğunluq

Kirayəçilərin izolyasiyası: ayrı-ayrı növbələr/açar məkanları, ACL, kvotalar.
Nəqliyyatda şifrələmə və/və ya «rahat».
payload PII-minimallaşdırma; xam PII əvəzinə hash/ID.
Sirləri: tapşırıqların bədəninə tokenlər qoymayın, vault/refs istifadə edin.

14) Anti-nümunələr

İdempotentlik olmadan retrailer → dubl əməliyyatları/pul «iki dəfə».
Bir nəhəng növbə «hər şey üçün» → heç bir təcrid, gözlənilməz gecikmələr.
DLQ olmadan sonsuz retras → əbədi «zəhərli» vəzifələr.
Visibility Timeout <müalicə vaxtı → kaskad dublikatları.
Böyük payload → şəbəkə/yaddaş əzir; bir obyektdə saxlamaq və linki ötürmək daha yaxşıdır.
Backpressure olmadan push model → workers boğulur.
Kritik və bulk vəzifələri bir hovuz worker qarışdırın.

15) Giriş çek siyahısı

• SLA (P0/P1/P2) və həcminə görə tapşırıqları təsnif edin.
• İstədiyiniz semantika və retenshn ilə broker/framework seçin.
• Açarları, prioritetləri və marşrutları (hash/shards/priority lanes) hazırlayın.
• backoff + jitter və DLQ siyasəti ilə retrayları daxil edin.
• İdempotentliyi həyata keçirin (TTL ilə açarlar, upsert, dedup store).
• Taymautları konfiqurasiya edin: per-task, visibility, ümumi son tarix.
• concurrency və inteqrasiya/tenant rate məhdudlaşdırın.
• Qoruyucularla dərinlik/lag üzrə avtoskeylinq.
• Metriklər/Trace/Alert; runbooks «fırtına» və daşqın DLQ.
• Fayl testləri: worker düşməsi, «zəhərli» mesaj, həddindən artıq yükləmə, uzun tapşırıqlar.

16) Konfiqurasiya və kod nümunələri

16. 1 Celery (Redis/Rabbit) - əsas 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 - səviyyələrə görə retrajlar

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

(Gecikmiş çatdırılma ilə scheduler/cron-consumer vasitəsilə köçürün.)

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: pull qarşı push seçmək üçün nə vaxt?
A: Pull təbii backpressure və «dürüst» balans verir; Aşağı sürətlərdə və minimum TTFB lazım olduqda push daha asandır, lakin məhdudiyyətlər tələb edir.

Q: «isti» açar qarşısını almaq üçün necə?
A: Kompozit açarla ('order _ id% N') şard edin, bufer edin və batch emal edin, per-açar limitlərini daxil edin.

Q: «exactly-once» mümkündür?
A: Praktiki olaraq - idempotentlik və tranzaksiya autbox vasitəsilə. Bütün yolda tam «riyazi» exactly-once nadir hallarda əldə edilə bilər və bahalıdır.

Q: Harada böyük investisiya vəzifələri saxlamaq üçün?
A: Obyektin anbarında (S3/GCS), vəzifədə isə - link/ID; broker və şəbəkəyə təzyiqi azaldır.

Q: TTL/visibility seçmək üçün necə?
A: Visibility ≥ p99 emal vaxt × ehtiyatı 2-3 ×. TTL vəzifələri - daha az iş müddəti.

18) Nəticələr

Güclü növbə sistemi çatdırılma semantikası, prioritetlər və məhdudiyyətlər arasındakı balansdır. Açarları və marşrutları layihələndirin, idempotentliyi təmin edin, backoff və DLQ ilə retrajlar edin, resursları SLA siniflərinə ayırın və metrləri izləyin. Sonra fon prosesləriniz proqnozlaşdırıla bilən, sabit və ölçülü olacaq - zirvələr altında sürprizlər olmadan.