Apache Pulsar¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Apache Pulsar 4.0.0 LTS; subscription/transaction settings явно. Проверка источников: 2026-11-02. Baselines не объявляются latest/security recommendations.

Архитектура и роль¶

FACT. Brokers обслуживают topics/subscriptions, BookKeeper bookies сохраняют ledgers, metadata service управляет coordination. Разделение serving/storage меняет scaling/recovery paths, но добавляет operational components. Subscription cursor — progress конкретного потребителя/группы, не SQL transaction.

Внутренние механизмы и движение данных¶

Topic partitions хранят managed ledgers; broker dispatch доставляет messages согласно subscription type. Exclusive/Failover/Shared/Key_Shared дают разные ordering/parallelism contracts. Key_Shared требует правильного key и batching configuration (key-based batching/отключение несовместимого batching), иначе routing assumptions нарушаются.

flowchart TB
  Producer --> Broker[Pulsar broker and topic partitions]
  Broker --> Bookies[BookKeeper durable ledgers]
  Broker --> Cursor[Subscription cursor]
  Cursor --> Dispatch[Subscription-type dispatch]
  Dispatch --> Consumers
  Metadata[Metadata coordination] --> Broker

Ordering и guarantees¶

Producer deduplication требует настройки broker/topic и стабильной producer identity/sequence protocol; application resend не автоматически исчезает. Pulsar transactions связывают publish/ack в поддерживаемых Pulsar resources, но не произвольную external DB transaction. Redelivery at-least-once требует downstream idempotency.

Версия и первичная документация.

Масштабирование и backpressure¶

Partitioned topics, bundle placement, broker dispatch и bookie disk/network/quorums ограничивают scale. Storage/serving separation не делает один hot key параллельным. Subscription backlog и retention/expiry policies влияют на стоимость и доступность replay. Geo-replication имеет отдельные async/conflict/failover semantics.

Failure / recovery / replay¶

Broker failover восстанавливает serving из durable managed ledgers и metadata; потеря quorum bookies либо metadata нарушает доступность. Ack потерян после target commit — replay. Cursor reset/reconsume/backfill требует новых subscription/generation и управления downstream effects; retention уже удалённых acked data не восстановить magic reset.

Версия и первичная документация.

Эксплуатация и мониторинг¶

Наблюдать backlog bytes/age per subscription, unacked/redelivery, storage write/read latency, bookie availability/disk, metadata health, offload errors, transaction coordinator и geo replication backlog. Отличать TTL expiry от successful business processing: backlog может исчезнуть без исполнения эффектов.

Ограничения и критерии выбора¶

Выбирать при выгоде от subscription models, storage separation и multi-tenant messaging и готовности сопровождать BookKeeper/metadata. Не объявлять универсальную дешевизну относительно Kafka без сравнения hardware, ops, retention и recovery.

FinTech / iGaming и реальные источники¶

FACT ограниченного уровня: официальный каталог Pulsar case studies содержит Intuit и Tencent game-data workloads. Это adoption evidence, не независимый benchmark и не доказательство нашего financial EOS. INFERENCE: highload event distribution и независимые subscriptions.

Практический пример¶

Сравнение topology/replay находится в Kafka/RabbitMQ/Pulsar. Native Pulsar runtime example в обязательный список не входит и не запускался; гарантии здесь документированы по4.0.x.

Типичные ошибки проектирования¶

Shared subscription как гарантированный per-key order; dedup без persistent producer identity; broker availability без BookKeeper quorum; cursor reset как восстановление удалённого log.

Вопросы на собеседовании¶

Shared сохраняет key ordering? Не как автоматическое обещание Key_Shared; выбирать тип по contract.

Transaction ack включает SQL commit? Нет.

Separation устраняет ops? Нет, меняет компоненты и failure domains.

Практические упражнения¶

Для двух независимых subscription задайте backlog retention, reset protocol и outage bookie quorum. Опишите обработку duplicate после ack loss.