Милдеттердин кезектери жана тең салмактуулук

1) Эмне үчүн милдеттерди кезек

• Чокуларды тегиздейт: фронт менен оор подсистемалардын ортосундагы буфер.
• SLA турукташтырат: артыкчылыктар жана жүк класстарын изоляциялоо.
• Иштен чыгууга туруктуулукту жөнөкөйлөтөт: ретра, DLQ, кайра коюу.
• Горизонталдуу масштабдалат: API алмаштыруусуз воркерлерди кошуу.

Типтүү домендер: төлөмдөрдү иштетүү, нотификация, отчетторду/медианы түзүү, ETL/ML-пост-процессинг, тышкы API менен интеграция.

2) Модель жана негизги түшүнүктөр

Продюсер: тапшырманы жарыялайт (payload + метадеректер: idempotency key, артыкчылык, мөөнөт).
Кезек/топик: буфер/логин тапшырмалар.
Worker: тапшырманы кабыл алат, иштетет, тастыктайт (ack) же ката менен кайтарат.
Visibility Timeout/Lease: "ижара" кайра иштетүү учурунда милдеттери, андан кийин - auto-кайра жеткирүү.
DLQ (Dead Letter Queue): аракет/өлүмгө ката чегинен кийин милдеттерди "көмүү".
Rate Limit/Concurrency: per-worker/per-кезек/per-tenant керектөө боюнча чектөөлөр.

• Pull: Воркер өзү тапшырманы сурайт (жүктү дозалайт).
• Push: брокер пушит; алсыз воркерлерди "куюудан" коргоо керек.

3) Семантика жеткирүү жана тастыктоо

At-most-once: retrains жок; тез, бирок жоготуу мүмкүн.
At-least-once (көпчүлүк кезектери үчүн дефолт): Мүмкүн дубликаттар → Иштеп чыгуучунун демпотенттиги талап кылынат.
Effectively exactly-once: колдонмо деъгээлинде жетишилет (демпотенттик, дедуп-стор, бүтүмдөр/autbox). Брокер жардам берет, бирок эмес, "сыйкырдуу ок".

• Ack/Nack: айкын натыйжасы.
• Requeue/Retry: с backoff + jitter.
• Poison message: DLQга жөнөтүү.

4) Баланстоо жана пландаштыруу

4. 1 Кезектүүлүк жана алгоритмдер

FIFO: жөнөкөй жана болжолдонгон.
Priority Queue: артыкчылыктуу класстар (P0... P3).
WRR/WSR (Weighted Round-Robin/Random): класстардын ортосундагы CPU/cherezput үлүштөрү.
WFQ/DRR (тармактардагы "адилет" кезектердин аналогу): per-tenant/кардар үлүштөрү.
Deadline/EDF: мөөнөтү менен тапшырмалар үчүн.
Fair Share: чектөө "ызы-чуу кошуналар" (per-tenant quotas).

4. 2 иштетүү агымдары

Single-flight/Coalescing: негизги тапшырманы кайталоону бириктирүү.
Concurrency caps: милдеттер/интеграциялардын түрлөрү боюнча параллелизмге катуу чектөөлөр (тышкы API).

4. 3 Гео жана шардана

Шардалар ачкыч (tenant/id) → маалыматтардын локалдуулугу, шардалардын ичинде туруктуу тартип.
Sticky кэш/ресурстар: "тиркелген" абалы менен Workers боюнча хеш-роутинг.

5) Retrains, backoff жана DLQ

Экспоненциалдык backoff + jitter: 'base 2 ^ attempt ± random'.
Максаттуу аракет жана жалпы мөөнөтү (убакыт-үчүн-die) тапшырма.
Каталардын классификациясы: 'retryable' (тармак/лимит), 'retryable' (валидация/бизнес тыюу салуу).
Parking/Delay Queue: кийинкиге калтырылган тапшырмалар (мисалы, 15 мүнөттөн кийин кайталаңыз).
DLQ саясаты: "уулуу" билдирүү кайда жана кандай шарттарда түшөөрүн көрсөтүңүз; reprocessor камсыз кылуу.

6) Демпотенттүүлүк жана дедупликация

• seen → skip/merge/result-cache.
• Natural keys: 'order _ id/ payment_id' ордуна туш келди UUID колдонуу.
• Outbox: бизнес-операция менен бир DD-бүтүмүндө тапшырма жана анын статусун жазуу.
• Exactly-once көк: "UPSERT" ачкычы боюнча, нускасын текшерүү, "ат-least-once" кезекте + DB-жылы боштондук.

7) Көп тенанттуулук жана SLA класстары

"critical", "standard", "bulk".
Квоталар жана артыкчылыктар per-tenant (Gold/Silver/Bronze).
Изоляция: P0 астында dedicate-бассейндер; фондук - өзүнчө кластерде.
Admission control: мөөнөтүнөн мурда иштеп чыгуу мүмкүн эмес.

8) Автоскейлинг Воркерлер

Скейлинг үчүн метриктер: queue depth, arrival rate, processing time, SLA мөөнөтү.
KEDA/Horizontal Pod Autoscaler: SQS/Rabbit/Kafka lag.
Тоскоолдук: тышкы API rate limits, маалымат базасы (backend жок).

9) технологиялык параметрлери жана үлгүлөрү

9. 1 RabbitMQ/AMQP

Exchanges: direct/topic/fanout; Queues с ack/ttl/DLQ (dead-letter exchange).
Prefetch (QoS) "worker боюнча канча милдеттерди" жөнгө салат.

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

9. 2 SQS (жана аналогдору)

Visibility Timeout, DelaySeconds, RedrivePolicy (DLQ).
Демпотенттүүлүк - тиркемеде (дедуп-таблица).
Лимиттер: 1-10 билдирүүлөр; демпотенттик көгүчкөндөргө көңүл буруңуз.

9. 3 Kafka/NATS JetStream

масштабдуу бөлүштүрүү үчүн: жогорку өткөрүү, retenshn/реплика.
Тегиздердин үстүнөн кезек: бир маселе = бир билдирүү; партиялаштыруу/subject аркылуу "ачкычка бир воркер" башкаруу.
Retrays: backoff менен өзүнчө топик/subject-суффикстер.

9. 4 Redis кезек (Sidekiq/Resque/Bull/Celery-Redis)

Өтө төмөн жашыруун; туруктуу (RDB/AOF), retry ачкычтары жана single-flight үчүн lock-keys.
"Жеңил" тапшырмалар үчүн ылайыктуу, узак мөөнөттүү retenshn үчүн эмес.

9. 5 Frameworks

Celery (Python), Sidekiq (Ruby), RQ/BullMQ (Node), Huey/Resque - даяр ретра, график, орто, метрика.

10) Багыттоо жана баланстоо схемалары

Round-Robin: бирдей, бирок милдеттерди "оордугу" эске албайт.
Weighted RR: Worker/Pool кубаттуулугу боюнча бөлүштүрүү.
Fair/Backpressure-aware: Воркер жаңы тапшырманы даяр болгондо гана алат.
Priority lanes: класска өзүнчө кезек; воркерлер тартипте окушат [P0 →... → Pn] бар болсо.
Hash-routing: 'hash (key)% shards' - stateful/кэш иштетүү үчүн.

11) Таймауттар, мөөнөттөр жана SLA

Per-task timeout: ички "ижара" иш (Воркер коду) ≤ Visibility убакыт брокер.
Global deadline: T убакыт кийин маселе мааниси жок - NACK → DLQ.
Budget-aware: иш кыскартуу (brownout) мөөнөтү жакындаганда (жарым-жартылай натыйжалары).

12) Байкоо жана башкаруу

12. 1 Метрика

`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 Логи/Трейсинг

Корреляция: 'job _ id', 'correlation _ id', дедупликация ачкычы.
иш-чаралар катары 'retry/backoff/dlq' белгилөө; span баштапкы суроо менен линковка.

12. 3 Dashbord/Алерт

Триггерлер: тереңдик> X, p99> SLO, DLQ өсүшү, "жабышып" милдеттери (visibility мөөнөтү> N), "ысык" ачкычтар.

13) Коопсуздук жана шайкештик

Ижарачылардын изоляциясы: жеке кезектер/ачкыч мейкиндиктери, ACL, квоталар.
транспорт жана/же "тынч" боюнча шифрлөө.
payload PII-минималдаштыруу; чийки PII ордуна хэш/ID.
Сырлар: тапшырмалардын денесине токендерди салбоо, vault/refs колдонуу.

14) Анти-үлгүлөрү

Idempotentity жок Retray → эки бүтүм/акча "эки жолу".
Бир чоң кезек "бардык" → эч кандай обочолонуу, күтүүсүз кечигүү.
DLQ → түбөлүк "уулуу" милдеттери жок чексиз Retray.
Visibility Timeout <иштетүү убактысы → каскаддык кайталоо.
Чоң PayLoad кезек → басым тармак/эс; жакшыраак сактоо жана шилтемени өткөрүп берүү.
backpressure жок Push модели → Workers муунтуп.
критикалык жана түйүндүү тапшырмаларды бир Worker пулда аралаштыруу.

15) Киргизүү чек-тизмеси

• SLA (P0/P1/P2) жана көлөмү боюнча милдеттерди классификациялоо.
• каалаган семантика жана retenshn менен брокер/Framework тандоо.
• Ачкычтарды, артыкчылыктарды жана багыттоону долбоорлоо (hash/shards/priority lanes).
• backoff + jitter жана DLQ саясаты менен Retray кирет.
• Idempotentity ишке ашыруу (ачкычтар, upsert, TTL менен Дедуп).
• Таймауттарды орнотуу: per-task, visibility, жалпы мөөнөтү.
• Concurrency жана rate интеграциялоо/тенант боюнча чектөө.
• Автоскейлинг тереңдиги/сактагычтар менен.
• Метрика/соода/Алерт; runbooks боюнча "бороон" жана толуп DLQ.
• Fail тесттер: Worker кулап, "уулуу" билдирүү, ашыкча жүктөө, узак тапшырмалар.

16) Конфигурация жана код мисалдары

16. 1 Celery (Redis/Rabbit) - негизги 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 - деңгээл боюнча retrais

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

(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: Качан pull каршы push тандоо?
A: Pull табигый backpressure жана "чынчыл" балансын берет; push төмөн ылдамдыкта жана минималдуу TTFB керек болгондо, бирок чектөө талап кылат.

Q: Кантип "ысык" ачкычын качуу керек?
A: компоненттик ачкычы ('order _ id% N') боюнча шардана, буфер жана batch-иштетүү, per-ачкыч чектерин киргизүү.

Q: "exactly-once" болушу мүмкүнбү?
A: Иш жүзүндө - демпотенттик жана транзакциялык аутбокс аркылуу. Толугу менен "математикалык" бардык жолдо exactly-once сейрек жетүүгө болот жана кымбат.

Q: Кайда чоң салым милдеттери сактоо?
A: Объект сактоодо (S3/GCS), ал эми тапшырмада - шилтеме/ID; брокер жана тармак боюнча басымды азайтат.

Q: Кантип TTL/visibility тандоо керек?
A: Visibility ≥ p99 иштетүү убактысы × запасы 2-3 ×. TTL милдеттери - аз бизнес мөөнөтү.

18) натыйжалары

Күчтүү кезек системасы жеткирүү семантикасы, артыкчылыктары жана чектөөчүлөрдүн ортосундагы тең салмактуулук болуп саналат. Ачкычтарды жана багыттоону долбоорлоо, идемпотенттүүлүктү камсыз кылуу, backoff жана DLQ менен ретрациялоо, ресурстарды SLA класстарына бөлүштүрүү жана метриктерди көзөмөлдөө. Анда сиздин фон процесстериңиз алдын ала айтууга болот, туруктуу жана масштабдуу болот - чокулардын астында сюрпризсиз.