Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: Распределённые системы · Уровень: Senior+ ## TL;DR - Kafka — это распределённый, реплицируемый, persistent **commit log**, а не классическая очередь. Сообщения не удаляются после чтения; консьюмеры читают по своему оффсету (pull-модель). - **Топик → партиции**. Партиция — единица параллелизма и единственная единица упорядочивания. Глобального порядка между партициями нет. - **Consumer group**: одна партиция в конкретный момент обрабатывается ровно одним консьюмером группы. Параллелизм группы ограничен числом партиций. - Гарантии порядка — только внутри партиции; ключ сообщения определяет партицию (`hash(key) % partitions`), поэтому одинаковый ключ → одна партиция → порядок. - Delivery: по умолчанию **at-least-once**. **Exactly-once** (EOS) достигается idempotent producer + transactions + `read_committed`. At-most-once — если коммитить оффсет до обработки. - Надёжность: `acks=all` + `min.insync.replicas>=2` + `replication.factor>=3`. ISR — синхронные реплики. - Ребалансировка: eager (stop-the-world) vs cooperative/incremental (KIP-429). Ретеншн: по времени/размеру или **log compaction** (хранит последнее значение на ключ). - Go-клиенты: **franz-go** (предпочтительно, нативный, поддержка свежих KIP, EOS) vs **sarama** (зрелый, но тяжелее и с историей багов). ## Теория ### Лог как структура данных Партиция — это append-only лог сегментов на диске. Каждое сообщение получает монотонный **offset** (int64) — порядковый номер в партиции. Это центральная идея Kafka: брокер не отслеживает, кто что прочитал, он лишь хранит лог и текущие границы. ``` Партиция P0 (топик "orders"): offset: 0 1 2 3 4 5 6 ... (log-end-offset) [m0] [m1] [m2] [m3] [m4] [m5] [m6] ^ ^ consumer A producer пишет committed=3 в конец (append) ``` Сегменты: лог нарезается на segment-файлы (`*.log` + индексы `*.index` по offset, `*.timeindex` по времени). Ретеншн и compaction работают на уровне сегментов — удалять/чистить можно целыми файлами, что дёшево. Активный сегмент не трогается до ротации. Запись последовательная (sequential I/O) + **zero-copy** (`sendfile`) при отдаче — отсюда высокий throughput: данные идут page cache → socket, минуя userspace. ### Топики, партиции, оффсеты - **Топик** — логическое имя потока. Делится на N партиций (число задаётся при создании, увеличивать можно, уменьшать — нет). - **Партиция** — упорядоченная неизменяемая последовательность. Единица: репликации, параллелизма, упорядочивания. - **Offset** — позиция консьюмера. Хранится не у брокера-per-message, а коммитится консьюмером в служебный топик `__consumer_offsets` (или вручную во внешнее хранилище). Ключевые оффсеты партиции: `log-start-offset` (после ретеншна), `high-watermark` (HW — максимальный реплицированный во все ISR оффсет; консьюмер в `read_committed`/обычном режиме не видит дальше HW), `log-end-offset` (LEO — конец лога лидера). ### Распределение по партициям и роль ключа Producer выбирает партицию: - Есть ключ → `partition = murmur2(key) % numPartitions` (детерминированно). Гарантия: все сообщения с одним ключом попадают в одну партицию → сохраняют относительный порядок. - Нет ключа → sticky partitioner (батчит в одну партицию пока батч не закроется), затем меняет — для равномерности и эффективности батчинга. Senior-нюанс: **число партиций менять опасно** для семантики ключа — `% numPartitions` поменяется, и существующие ключи "переедут" в другие партиции, ломая порядок и locality. Поэтому партиционирование планируют заранее с запасом. ### Consumer groups Группа определяется `group.id`. Брокер-координатор раздаёт партиции топика членам группы так, что **каждая партиция назначена ровно одному консьюмеру в группе**. ``` Топик orders: 4 партиции. Группа "billing" = 3 консьюмера. P0 -> C1 P1 -> C1 P2 -> C2 P3 -> C3 C1 держит 2 партиции (партиций больше, чем консьюмеров) Если консьюмеров 5 при 4 партициях -> один консьюмер простаивает. ``` Следствия: - Максимальный параллелизм группы = число партиций. Хотите больше воркеров — добавляйте партиции. - Разные группы читают независимо, каждая со своим набором оффсетов (fan-out): один топик читают и `billing`, и `analytics`. ### Гарантии упорядочивания - **Внутри партиции** — строгий порядок (по offset). - **Между партициями** — порядка НЕТ. "Глобального порядка" в Kafka не существует без single-partition (что убивает параллелизм). - Практика: выбирайте ключ так, чтобы события, требующие порядка, попадали в одну партицию (например `order_id`). Тогда порядок per-order сохранён, а параллелизм есть между разными order_id. Гарантия порядка от producer'а ломается при ретраях, если `max.in.flight.requests.per.connection > 1` без идемпотентности: ретрай батча может переупорядочить запись. С idempotent producer (`enable.idempotence=true`) порядок при ретраях сохраняется до in-flight=5. ### Delivery semantics - **At-most-once**: коммит оффсета ДО обработки. Падение после коммита → потеря сообщения. Редко нужно. - **At-least-once (по умолчанию)**: обработать → потом коммитить оффсет. Падение после обработки до коммита → повторная доставка. Требует **идемпотентных** консьюмеров (дедуп по бизнес-ключу, upsert). - **Exactly-once (EOS)**: достигается комбинацией: - **Idempotent producer** (`enable.idempotence=true`): PID + sequence number на партицию, брокер отбрасывает дубликаты ретраев. Защищает producer→broker. - **Transactions** (`transactional.id`): атомарно пишем в несколько партиций/топиков И коммитим consumer-оффсеты в одной транзакции (паттерн consume-process-produce). Коммит оффсета через `sendOffsetsToTransaction`. - Консьюмеры читают с `isolation.level=read_committed` — видят только закоммиченные транзакции (фильтруют aborted). - EOS работает строго в рамках Kafka (Kafka→Kafka, например Kafka Streams). При записи во внешнюю БД нужна транзакция/идемпотентность на стороне приёмника (outbox-паттерн). ### acks, ISR, репликация Каждая партиция: один **leader** + N-1 **followers**. Producer и consumer работают только с лидером. Followers пуллят данные с лидера. **ISR (In-Sync Replicas)** — набор реплик, не отстающих от лидера больше `replica.lag.time.max.ms`. HW продвигается только когда запись реплицирована во все ISR. `acks`: - `acks=0` — fire-and-forget, возможна потеря. - `acks=1` — лидер записал (в свой лог/page cache). Потеря, если лидер упал до репликации. - `acks=all`(=-1) — все ISR подтвердили. Надёжно ТОЛЬКО в паре с `min.insync.replicas`. **Ключевая ловушка**: `acks=all` + `replication.factor=3` + `min.insync.replicas=1` — если ISR схлопнулся до лидера, "all" = 1 реплика, потеря при падении лидера остаётся. Правильно: `replication.factor=3`, `min.insync.replicas=2`, `acks=all` — переживает падение одной реплики и не теряет данные. Если ISR < min.insync — producer получает `NotEnoughReplicas` (отказ записи, а не тихая потеря). ### Ребалансировка Когда состав группы или партиций меняется (consumer присоединился/упал/`max.poll.interval.ms` истёк), координатор запускает ребаланс. - **Eager (старый, RangeAssignor/RoundRobin)**: stop-the-world — ВСЕ консьюмеры отдают ВСЕ партиции, потом получают новое назначение. Простоя на время ребаланса = плохо при больших группах. - **Cooperative / incremental (KIP-429, CooperativeStickyAssignor)**: за два рывка отдаются только те партиции, что реально переезжают; остальные продолжают обрабатываться. Резко снижает downtime. Сейчас рекомендуемый. Дополнительно **static membership** (KIP-345, `group.instance.id`) — при кратковременном рестарте пода (k8s rolling) консьюмер сохраняет назначение и не триггерит ребаланс (в пределах `session.timeout.ms`). Liveness: консьюмер должен слать heartbeat (фон, `heartbeat.interval.ms`/`session.timeout.ms`) И регулярно вызывать poll (`max.poll.interval.ms`). Долгая обработка батча между poll'ами → консьюмер считается мёртвым → ребаланс → дубликаты. ### Ретеншн и compaction - **Delete retention** (`cleanup.policy=delete`): удаляет сегменты старше `retention.ms` или когда суммарный размер > `retention.bytes`. Это про "лог как буфер на N дней". - **Log compaction** (`cleanup.policy=compact`): хранит как минимум последнее значение для каждого ключа. Tombstone (значение `null`) помечает ключ на удаление. Это превращает топик в "снимок последнего состояния по ключу" — основа changelog'ов (Kafka Streams state stores, `__consumer_offsets`, CDC снапшоты). - Можно `compact,delete` одновременно. ### Ключевые настройки (шпаргалка) | Параметр | Сторона | Назначение | |---|---|---| | `acks=all` | producer | подтверждение от всех ISR | | `enable.idempotence=true` | producer | дедуп ретраев, порядок | | `min.insync.replicas=2` | topic/broker | минимум ISR для записи при acks=all | | `replication.factor=3` | topic | число реплик партиции | | `retention.ms` / `retention.bytes` | topic | политика хранения | | `cleanup.policy` | topic | delete / compact | | `max.poll.records` | consumer | размер батча на один poll | | `max.poll.interval.ms` | consumer | дедлайн между poll до считания мёртвым | | `enable.auto.commit` | consumer | авто-коммит оффсетов (часто off для контроля) | | `isolation.level` | consumer | read_committed для EOS | | `partition.assignment.strategy` | consumer | cooperative-sticky | `enable.auto.commit=true` коммитит периодически в фоне (`auto.commit.interval.ms`) — удобно, но даёт at-least-once с риском потери при auto-commit перед обработкой (точнее — коммитится оффсет уже выданных, но, возможно, не обработанных записей). Для контроля семантики на проде обычно `false` + ручной commit после обработки. ### Go-клиенты: franz-go vs sarama - **sarama** (IBM/Shopify): исторически дефолт. Зрелый, много кода вокруг. Минусы: тяжёлый API, исторические баги в consumer group/ребалансе, медленнее догоняет новые KIP, ручная работа с EOS неудобна. - **franz-go** (twmb): современный, один из самых полных по покрытию протокола и KIP (cooperative ребаланс, EOS/transactions, KIP-345 static membership, сжатие). Чистый pull-API, хорошая производительность, активная поддержка. **Предпочтителен для нового кода на senior-уровне.** - (confluent-kafka-go — cgo-обёртка над librdkafka; максимально совместима, но cgo усложняет сборку/кросс-компиляцию.) Пример консьюмера на franz-go (at-least-once, ручной коммит, cooperative): ```go package main import ( "context" "log" "github.com/twmb/franz-go/pkg/kgo" ) func main() { cl, err := kgo.NewClient( kgo.SeedBrokers("localhost:9092"), kgo.ConsumerGroup("billing"), kgo.ConsumeTopics("orders"), // cooperative incremental ребаланс вместо stop-the-world kgo.Balancers(kgo.CooperativeStickyBalancer()), // ручной коммит: не коммитим до успешной обработки kgo.DisableAutoCommit(), ) if err != nil { log.Fatal(err) } defer cl.Close() ctx := context.Background() for { fetches := cl.PollFetches(ctx) // pull-модель: тянем батч if errs := fetches.Errors(); len(errs) > 0 { log.Printf("fetch errors: %v", errs) continue } fetches.EachRecord(func(r *kgo.Record) { // порядок гарантирован внутри партиции (r.Partition) // обработка должна быть идемпотентной (at-least-once!) if err := handle(r.Key, r.Value); err != nil { log.Printf("handle %s/%d@%d: %v", r.Topic, r.Partition, r.Offset, err) return } }) // коммитим только после успешной обработки батча if err := cl.CommitUncommittedOffsets(ctx); err != nil { log.Printf("commit: %v", err) } } } func handle(key, val []byte) error { return nil } ``` Producer с idempotence + acks=all (franz-go включает идемпотентность по умолчанию): ```go cl, _ := kgo.NewClient( kgo.SeedBrokers("localhost:9092"), kgo.RequiredAcks(kgo.AllISRAcks()), // acks=all // идемпотентность включена по умолчанию; для строгого EOS: kgo.TransactionalID("billing-tx-1"), ) ``` ## Подводные камни / gotchas - **`acks=all` без `min.insync.replicas>=2` не спасает от потери** — классическая ошибка. Нужно настраивать на топике/брокере. - **Изменение числа партиций ломает key→partition** для существующих ключей: порядок и locality нарушаются. Планируйте партиции заранее. - **Долгая обработка между poll'ами** превышает `max.poll.interval.ms` → консьюмер выкидывается из группы → ребаланс → повторная обработка батча (дубликаты). Лечится уменьшением `max.poll.records`, выносом обработки или паузой партиций. - **"Exactly-once" в Kafka — это Kafka→Kafka.** При записи во внешние системы нужна идемпотентность/транзакция на приёмнике (outbox, dedup-таблица). EOS не магия для side-effects. - **Auto-commit ≠ at-least-once автоматически.** Может коммитить оффсет до завершения обработки → at-most-once-подобная потеря при падении. Для строгого контроля — ручной коммит. - **Hot partition / skew**: плохой ключ (например `country=US` для 80% трафика) делает одну партицию узким местом; параллелизм группы простаивает. - **Rebalance storms**: частые join/leave (нестабильные поды, маленький `session.timeout.ms`) → постоянные ребалансы → деградация. Static membership + cooperative помогают. - **Consumer lag** — главная метрика здоровья: `log-end-offset - committed-offset`. Растёт → консьюмеры не успевают. - **Zero-copy ломается**, если включить TLS или сделать преобразование формата на брокере — throughput падает. - **Retention vs compaction путают**: для топиков-состояний (changelog) нужен `compact`, для топиков-событий — `delete` по времени. ## Вопросы на собеседовании **В:** Почему Kafka называют логом, а не очередью, и что это меняет? **О:** Сообщения не удаляются при чтении; брокер хранит append-only лог, а позицию (offset) держит консьюмер (pull). Это даёт: повторное чтение/replay, fan-out нескольким независимым группам, отвязку throughput'а консьюмера от producer'а, дешёвый ретеншн целыми сегментами. Классическая очередь удаляет сообщение после ack и не даёт replay. **В:** Как Kafka гарантирует порядок? Можно ли получить глобальный порядок? **О:** Порядок строгий только внутри партиции (по offset). Глобального порядка между партициями нет; единственный способ — одна партиция, что убивает параллелизм. Практически: выбираем ключ (например order_id), чтобы связанные события шли в одну партицию — порядок per-key при сохранении общего параллелизма. **В:** Чем определяется максимальный параллелизм consumer group? **О:** Числом партиций топика: партиция в момент времени обрабатывается ровно одним консьюмером группы. Консьюмеров больше, чем партиций — лишние простаивают. Масштабирование = увеличение партиций (с оговоркой про key→partition). **В:** Как настроить надёжную доставку без потерь? **О:** На producer — `acks=all`, `enable.idempotence=true`. На топике/брокере — `replication.factor=3`, `min.insync.replicas=2`. Тогда запись подтверждается минимум двумя ISR и переживает падение одной реплики; при недоступности кворума ISR producer получает ошибку вместо тихой потери. Консьюмер — at-least-once с идемпотентной обработкой. **В:** Что такое exactly-once и где его границы? **О:** EOS = idempotent producer (PID+seq, дедуп ретраев) + transactions (атомарная запись в партиции + коммит оффсетов через sendOffsetsToTransaction) + `read_committed` на консьюмере. Работает в пределах Kafka (consume-process-produce, Kafka Streams). Для side-effects во внешние системы exactly-once требует идемпотентности/транзакции на приёмнике (outbox). **В:** Eager vs cooperative ребаланс? **О:** Eager — stop-the-world: все отдают все партиции и переназначаются, есть полный простой. Cooperative/incremental (KIP-429) — переезжают только реально перераспределяемые партиции в два прохода, остальные продолжают обрабатываться, downtime минимален. Cooperative — текущая рекомендация. **В:** Что такое ISR и high-watermark? **О:** ISR — реплики, синхронные с лидером (отставание < `replica.lag.time.max.ms`). High-watermark — максимальный offset, реплицированный во все ISR; консьюмеры не видят дальше HW. acks=all ждёт подтверждения всех ISR; min.insync.replicas задаёт минимальный размер ISR для приёма записи. **В:** Delete retention vs log compaction — когда что? **О:** Delete — хранить лог события N времени/байт, потом удалять сегменты (топики-события). Compaction — хранить последнее значение на ключ (tombstone удаляет ключ); это снимок состояния, нужен для changelog/CDC/state stores. Можно совмещать compact,delete. **В:** Какой Go-клиент выбрать и почему? **О:** franz-go — современный, нативный (без cgo), полное покрытие протокола и свежих KIP (cooperative ребаланс, EOS, static membership), хорошая производительность; рекомендую для нового кода. sarama — зрелый, но тяжёлый и с историей багов в consumer-group логике. confluent-kafka-go — cgo-обёртка над librdkafka, максимально совместима, но усложняет сборку. ## На что копают на senior+ - Понимание разницы между гарантиями producer'а и консьюмера, и того, что end-to-end EOS требует кооперации обеих сторон + приёмника (outbox, дедуп). - Точная настройка durability: связка `acks=all` + `min.insync.replicas` + `replication.factor`, поведение при схлопывании ISR (отказ записи vs потеря). - Влияние in-flight requests и идемпотентности на порядок при ретраях. - Управление ребалансами на проде: cooperative, static membership, тюнинг `session.timeout.ms`/`max.poll.interval.ms`, борьба с rebalance storms и дубликатами при долгой обработке. - Партиционирование как архитектурное решение: выбор ключа, борьба со skew/hot partition, последствия изменения числа партиций. - Operational metrics: consumer lag, под-репликация (under-replicated partitions), HW vs LEO. - Понимание physical layer: sequential I/O, page cache, zero-copy и что их ломает (TLS, конверсия формата). - Outbox/transactional outbox как мост между Kafka EOS и внешними БД.