Крипто-казино
Torrent Gear
Оптимізація відгуку backend: черги, async, backpressure
1) Навіщо: цілі та SLO
Мета - стабільний швидкий відгук навіть під сплесками. Бізнес висловлює це SLO:- API (CRUD/каталоги): p95 ≤ 250–400 мс, error rate < 1%.
- Платіж/сеттлмент (асинхронно): внутрішній SLA на підтвердження ≤ 2-5 хв, а клієнту - миттєвий 202/Accepted + статус-полер/вебхук.
- WS/real-time: RTT p95 ≤ 120 мс, disconnect ≤ 0. 5%.
Ключ: розв'язати «повільні» кроки (провайдери, БД, зовнішні API) від користувацького відгуку через черги і грамотне обмеження навантаження.
2) Базова картина: де береться латентність
Вузькі місця: БД (пули/індекси), зовнішні провайдери (PSP/ігрові), що блокують I/O, GC/стоп-світ, серіалізація JSON, «важкі» агрегації.
Симптоми: ріст p99, черга з'єднань до БД, сплески ретраїв, тайм-аути ланцюжком (retry storm).
Антидот: асинхронні конвеєри + backpressure + тайм-аути/ретраї + ідемпотентність.
3) Асинхронні патерни: SEDA и CQRS
SEDA (staged event-driven architecture): розбийте обробку на стадії (ingress → валідація → запис → інтеграція → повідомлення). На кожній - своя черга і ліміти паралелізму.
CQRS: розділіть читання і записи. Запис - в журнал/базу, читання - з проекцій/кешів.
Outbox: подія публікується атомарно разом із записом (уникаємо «втрачених» повідомлень).
Saga: довгі бізнес-процеси з компенсуючими транзакціями замість глобальних.
4) Черги і стріми: вибір і тюнінг
RabbitMQ/NATS JetStream - команди завдань (work queues), Kafka - події/стріми з реплеєм.
Налаштування, які впливають на відгук:- Prefetch / max in-flight: обмежте кількість одночасно оброблюваних повідомлень на воркера (наприклад, 16-64), щоб не «забити» БД/зовнішній API.
- Акер/повтори: 'ack'після ідемпотентного запису; повтори з експоненціальною затримкою і джиттером.
- DLQ/parking lot: безкінечних ретраїв немає - після N спроб йде в Dead Letter Queue.
- Партіонування (Kafka): ключ по суті (userId/txnId) для впорядкованості; паралелізм через кількість партій.
5) Зворотний тиск (backpressure) - як не потонути
Ідея: приймати тільки стільки, скільки зможете обробити в межах латентності SLO.
Техніки:- Admission control: обмежуйте конкуренцію (semaphore/worker-pool) на кожну зовнішню залежність: БД, PSP, провайдер ігор.
- Шейпінг трафіку: token-bucket/leaky-bucket на вході сервісу і на критичних маршрутах.
- Черги з верхньою межею: при заповненні - відрізаємо хвіст (429/503 + Retry-After) або переводимо в asap-batch.
- Adaptive concurrency (AIMD): ростіть паралелізм при успіху, знижуйте при тайм-аутах.
- Circuit Breaker: 'closed → open → half-open'помилково/тайм-аутам зовнішнього API; при open - деградація (кеш/стаб).
go sem:= make (chan struct {}, 64 )//ліміт конкуренції до БД/PSP
func handle(req) {
select {
case sem <- struct{}{}:
defer func(){ <-sem }()
ctx, cancel:= context. WithTimeout(req. ctx, 300time. Millisecond)
defer cancel()
res, err:= db. Do(ctx, req)
if err == context. DeadlineExceeded { metrics. Timeouts. Inc(); return TooSlow() }
return Ok(res)
default:
metrics. Backpressure. Inc()
return TooBusy(429, "Retry-After: 0. 2")
}
}6) Тайм-аути, ретраї і джиттер: «Три кити виживання»
Тайм-аути коротше SLO: якщо SLO 400 мс, тайм-аут до БД/провайдера 250-300 мс; загальний тайм-аут запиту <400-600 мс.
Ретраї обмежені і розумні: 1-2 спроби max, тільки для безпечних операцій (ідемпотентних), з експонентою і джиттером.
Коалесинг: агрегуйте повтори для одного ключа.
Псевдокод (експонента + джиттер):python for attempt in range(0, 2):
try:
return call(dep, timeout=0. 3)
except Timeout:
backoff = (0. 05 (2attempt)) + random. uniform(0, 0. 05)
sleep(backoff)
raise UpstreamUnavailable7) Ідемпотентність і дедуплікація
Idempotency-Key на HTTP (депозити, виплати),'operation _ id'в БД (унікальний індекс).
Inbox/Outbox: вхідні вебхуки - завжди через незмінну inbox-таблицю з dedupe по'event _ id'; вихідні - з outbox по транзакції.
Exactly-once «за змістом»: допускаємо повторні доставку/виконання, але ефект один.
8) Швидкий API для повільних операцій
Синхронний відгук: 201/202 + URL статусу ('/status/{ id}'), ETA і підказки ретрая.
Вебхукі/Server-Sent Events/WS - пуш стейта при готовності.
Клієнтська дисципліна: 'Retry-After', ідемпотентність, ліміт опитування.
Приклад відповіді:json
HTTP/1. 1 202 Accepted
Location: /v1/withdrawals/req_9f2/status
Retry-After: 2
{
"request_id": "req_9f2", "state": "processing", "next_check_sec": 2
}9) Мінімізуємо роботу в гарячому шляху
Винесіть важкі штуки в фон: перетворення, агрегації, повідомлення, запис в DWH.
Кеш і проекції: часто читається - cache-aside з коротким TTL і подієвою інвалідацією.
Batch-патерни: групуйте зовнішні виклики (наприклад, запит лімітів провайдера раз на N мс).
Серіалізація: швидкі кодеки (protobuf/msgpack) для міжсервісних зв'язків; JSON тільки на edge.
10) БД під контролем
Пули з'єднань: верхні межі (виходячи з ядер/IO), черги до пулу включені.
Індекси та план: p95 explain + автотести регресії планів.
Тайм-аути запитів: короткі,'statement _ timeout'( Postgres).
Hot rows/locks: шардування по ключу, оптимістичні блокування (версія балансу), saga замість «монолітної» транзакції.
11) WebSocket/real-time
Обмежувач на розсилку: batched broadcast, max msgs/sec per connection.
Внутрішній backpressure: черга вихідних повідомлень з капом; при переповненні - drop low-priority.
Sticky-routing і PDB при релізах - щоб не плодити reconnect-шторм.
12) Спостережуваність, щоб не гадати
Метрики (RED/USE + backpressure):- 'request _ rate','error _ ratio','latency _ p95/p99'за маршрутами.
- `queue_depth`, `lag_seconds`, `consumer_inflight`, `retries_total`, `dlq_rate`.
- `backpressure_drops`, `admission_rejects`, `circuit_open`.
- Для БД: `connections_in_use/max`, `locks`, `slow_queries`.
- Трейси: спани'queue → worker → db/psp'з тегами'operation _ id','partition','retry'.
- Логи: структурні, з'trace _ id', без PII; окремі події «open/close circuit».
13) Тестування під навантаженням
Open-model (arrivals/sec) для сплесків; Closed-model (VUs) для сесій.
Профілі: короткі burst 60-120 с і soak 1-4 ч.
Ін'єкції відмов: сповільніть зовнішнє API на + 200-500 мс, подивіться на р99/ретраї/черги.
Критерії зеленої зони: без зростання'queue _ lag', стабільні p95,'dlq_rate≈0'.
14) Безпека і надійність
Черги по TLS/mTLS, підпис повідомлень, контроль схеми (Avro/Protobuf + Schema Registry).
Idempotent producer (Kafka), exactly-once tx там, де виправдано.
Хаос-режим: періодично «роняйте» залежність і дивіться на деградацію (circuit, fallback).
15) Приклади «шматочків» конфігурацій
Nginx/Envoy вхідний шейпінг:nginx limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
location /api/ {
limit_req zone=api burst=40 nodelay;
proxy_read_timeout 0. 6s; # коротше SLO proxy_connect_timeout 0. 2s;
}
}
basic. qos (prefetch_count = 32) # баланс CPU/IOjava props. put(ConsumerConfig. MAX_POLL_RECORDS_CONFIG, 200);
props. put(ConsumerConfig. FETCH_MAX_BYTES_CONFIG, 5_000_000);
props. put(ConsumerConfig. MAX_POLL_INTERVAL_MS_CONFIG, 60_000);16) Чек-лист впровадження (prod-ready)
- Критичні шляхи розділені на синхронний відгук і асинхронну обробку (SEDA).
- Admission control і ліміти конкуренції на зовнішні залежності.
- Тайм-аути коротше SLO; ретраї ≤ 2, з експонентою і джиттером; Коалісинг.
- Circuit breaker + деградація (кеш/стаб), політика half-open.
- Черги/стріми: prefetch/in-flight, DLQ, партії за ключами.
- Ідемпотентність (operation_id/Idempotency-Key), Outbox/Inbox, дедуплікація.
- Кеш: cache-aside, короткі TTL + подієва інвалідація.
- БД: ліміти пулів, statement_timeout, індекси, анти-lock стратегії.
- WS: ліміти повідомлень, батчинг, sticky-routing, PDB.
- Спостережуваність: метрики backpressure/queues/retries, трейси end-to-end, дашборди.
- Навантажувальні та відмовні тести (open + closed, burst + soak), критерії зеленої зони.
Резюме
Швидкий бекенд - це не «зробити ще один кеш», а керований потік: вхід обмежений, важкий - у фон, кожен етап з чергою і лімітами, ретраї рідкісні і розумні, а ланцюжки захищені circuit breaker і ідемпотентністю. Додайте дисципліну тайм-аутів, спостережуваність і регулярні стрес-тести - і ваші p95/p99 залишаться зеленими навіть під бурстами і примхами зовнішніх провайдерів.