{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "i-am-roma 🪬 analyst: заметки с тегом брокеры", "_rss_description": "i-am-roma 🪬 analyst", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/i-am-roma.com\/tags\/brokery\/", "feed_url": "https:\/\/i-am-roma.com\/tags\/brokery\/json\/", "icon": false, "authors": [ { "name": "i-am-roma", "url": "https:\/\/i-am-roma.com\/", "avatar": false } ], "items": [ { "id": "3", "url": "https:\/\/i-am-roma.com\/all\/kafka-eto-ne-ochered-eto-zhurnal-kotory-nikto-ne-stiraet-2\/", "title": "Kafka — это не очередь. Это журнал, который никто не сотрёт", "content_html": "
\n\"\"\n<\/div>\n

Если вы работали с очередями вроде RabbitMQ или SQS, у Kafka есть одна особенность, которая ломает привычную интуицию: прочитанное сообщение никуда не девается. Разберёмся, как это устроено и что из этого следует — на простых примерах, без воды.<\/p>\n

\n\"\"\n
Слева — как работает очередь. Справа — как работает Kafka<\/div>\n<\/div>\n

Почему это не очередь<\/h2>\n

В очереди сообщение живёт до первого прочтения: воркер забрал — брокер удалил. Удобно для задач «сделай что-то один раз», но плохо подходит, если один и тот же поток данных нужен нескольким системам сразу.<\/p>\n

Kafka устроена иначе. Сообщение дописывается в конец файла на диске — такой файл называют логом<\/b>, или commit log — и хранится там столько, сколько настроено, независимо от того, кто и сколько раз его уже прочитал.<\/p>\n

\n\"\"\n
Продюсер только дописывает справа. Потребители читают с любой позиции (offset) и не удаляют прочитанное<\/div>\n<\/div>\n

Отсюда главный практический эффект: пять разных систем — аналитика, поиск, антифрод, уведомления, аудит — могут читать один и тот же поток независимо, каждая в своём темпе, не мешая друг другу.
\n▫️O(1)<\/b> — чтение и запись это последовательный доступ к диску, не поиск по индексу
\n▫️N×<\/b> — сколько угодно независимых читателей без доп. нагрузки на источник
\n▫️TTL \/ ∞<\/b> — хранение настраивается: от часов до бессрочного<\/p>\n

Из чего состоит кластер<\/h2>\n

Три термина, без которых дальше не разобраться:<\/p>\n

    \n
  • Topic<\/b> — логический поток событий, например dialog-events<\/b>.<\/li>\n
  • Partition<\/b> — топик физически режется на партиции: независимые упорядоченные логи. Это единица параллелизма.<\/li>\n
  • Broker<\/b> — сервер кластера, хранящий партиции. У каждой партиции один лидер и несколько реплик-фолловеров на других брокерах.<\/li>\n<\/ul>\n
    \n\"\"\n
    Топик на 3 партиции с replication factor = 2 — у каждой партиции один лидер и реплики на других брокерах<\/div>\n<\/div>\n

    Тут есть два правила, которые часто путают:<\/p>\n

    Порядок гарантирован только внутри партиции.<\/b> Между партициями — нет. Нужен строгий порядок между конкретными событиями (например, все события одного диалога) — они должны попадать в одну партицию.<\/p>\n

    За отказоустойчивость отвечают реплики, а не партиции.<\/b> Продюсеры и консьюмеры общаются только с лидером. Фолловеры молча копируют его лог. Упал лидер — один из синхронных фолловеров (ISR) становится новым лидером автоматически.<\/p>\n

    Как не потерять порядок<\/h2>\n

    У каждого сообщения есть необязательный key<\/b>. Если он задан, Kafka всегда кладёт сообщения с одинаковым ключом в одну и ту же партицию — это единственный способ гарантировать порядок между ними.<\/p>\n

      \n
    • Нужен порядок внутри диалога или у одного юзера → задайте key = dialog_id<\/b> (или user_id<\/b>).<\/li>\n
    • Порядок не важен, важна равномерная нагрузка → не задавайте key — Kafka раскидает сообщения round-robin.<\/li>\n<\/ul>\n

      Число партиций топика нельзя безболезненно уменьшить, а увеличение задним числом рвёт гарантию порядка для уже написанных данных. Планируйте количество партиций с запасом, а не наращивайте реактивно.<\/p>\n

      Кто и как читает<\/h2>\n

      Консьюмеры объединяются в consumer group<\/b> по общему group.id<\/b>. Правило простое: одну партицию внутри группы читает только один консьюмер одновременно — это и есть встроенный механизм масштабирования обработки.<\/p>\n

      \n\"\"\n
      Четыре партиции распределены между двумя консьюмерами одной группы; добавление третьего вызовет rebalance<\/div>\n<\/div>\n

      Партиций больше, чем консьюмеров — лишние простаивают. Число партиций стоит планировать исходя из желаемого параллелизма обработки, а не только из throughput записи.<\/p>\n

      Офсет, который коммитит консьюмер — это отметка «докуда я дочитал», а не команда на удаление. Тот же топик в любой момент может независимо перечитать другая consumer group.<\/p>\n

      Насколько надёжна доставка<\/h2>\n

      «Exactly-once» в Kafka — это не волшебная кнопка, а комбинация настроек, за которую вы платите производительностью. По умолчанию включён средний по надёжности вариант.<\/p>\n

      \n\"\"\n
      Три уровня гарантий доставки — от самого быстрого до самого надёжного<\/div>\n<\/div>\n

      Две настройки, которые управляют этим спектром:<\/p>\n

        \n
      • acks<\/b> — сколько реплик должны подтвердить запись: 0<\/b> (никого не ждать), 1<\/b> (только лидер), all<\/b> (все синхронные реплики).<\/li>\n
      • enable.idempotence<\/b> — брокер присваивает каждому сообщению номер и сам отбрасывает дубли от повторной отправки при сетевых ретраях.<\/li>\n<\/ul>\n

        Retention: два способа не хранить всё вечно<\/h2>\n

        По умолчанию<\/b> (cleanup.policy=delete) сообщения стираются по возрасту или объёму — обычный поток событий, где старое со временем не нужно.<\/p>\n

        Log compaction<\/b> (cleanup.policy=compact) — Kafka хранит только последнее значение для каждого ключа. Топик превращается в снэпшот текущего состояния, а не в историю: удобно для восстановления состояния сервиса после падения (event sourcing) или для «текущего профиля пользователя».<\/p>\n

        Масштабирование в двух словах<\/h2>\n

        Разные оси дают разный эффект, и их легко перепутать:<\/p>\n

          \n
        • Больше партиций<\/b> → выше throughput записи и параллелизм чтения. Но больше файловых дескрипторов на брокер и дольше выборы лидера при отказе.<\/li>\n
        • Больше реплик (replication factor)<\/b> → надёжнее, но не быстрее. Клиенты всегда общаются только с лидером — реплики не ускоряют ни чтение, ни запись.<\/li>\n<\/ul>\n

          min.insync.replicas — недооценённая настройка: сколько реплик должно быть «в синхроне», чтобы запись с acks=all считалась успешной. При replication.factor=3 и min.insync.replicas=2 кластер переживёт отказ одного брокера без остановки записи; при отказе двух — запись остановится вместо тихой потери данных.<\/p>\n

          Экосистема вокруг Kafka<\/h2>\n
            \n
          • Kafka Connect<\/b> — готовые коннекторы для загрузки данных в Kafka и выгрузки из неё (например, Debezium для CDC из Postgres).<\/li>\n
          • Kafka Streams<\/b> — библиотека для потоковой обработки прямо поверх топиков, обычное JVM-приложение.<\/li>\n
          • ksqlDB<\/b> — те же потоковые трансформации, но на SQL, без кода.<\/li>\n
          • Schema Registry<\/b> — версионирование схем сообщений и проверка обратной совместимости для команд, которые пишут\/читают один топик.<\/li>\n<\/ul>\n

            Когда Kafka уместна, а когда нет<\/h2>\n

            Хорошо подходит, если:<\/b><\/p>\n

              \n
            • нужно, чтобы несколько систем читали один поток независимо;<\/li>\n
            • важен большой throughput на обычном железе;<\/li>\n
            • нужна возможность переиграть историю (реплей) после бага в обработке.<\/li>\n<\/ul>\n

              Плохо подходит, если:<\/b><\/p>\n

                \n
              • нужны SQL-запросы и фильтрация по произвольному полю — Kafka не хранилище, только последовательное чтение;<\/li>\n
              • сообщений мало и они очень мелкие — overhead на каждое делает лёгкие очереди вроде SQS эффективнее;<\/li>\n
              • нет ресурсов на операционную поддержку — свой кластер это ZooKeeper\/KRaft, мониторинг ISR и ребалансировка.<\/li>\n<\/ul>\n\n\n\n\n\n\n\n
                Инструмент<\/td>\nЧто сильнее у него<\/td>\nКогда взять вместо Kafka<\/td>\n<\/tr>\n
                Kafka<\/td>\nthroughput, независимые консьюмеры, реплей<\/td>\n—<\/td>\n<\/tr>\n
                RabbitMQ<\/td>\nгибкая маршрутизация, приоритеты<\/td>\nTask-очередь: сообщение нужно ровно одному воркеру<\/td>\n<\/tr>\n
                Amazon SQS<\/td>\nzero-ops, простота в AWS<\/td>\nПростой pipeline без своей инфраструктуры<\/td>\n<\/tr>\n
                Redis Streams<\/td>\nминимальная latency<\/td>\nНебольшой объём, лёгкий кейс, Redis уже в стеке<\/td>\n<\/tr>\n
                Apache Pulsar<\/td>\nмультиарендность<\/td>\nНужно масштабировать storage отдельно от compute<\/td>\n<\/tr>\n<\/table>\n

                Где Kafka встречается в реальных проектах<\/h2>\n
                  \n
                1. Шина событий между микросервисами<\/b> — вместо синхронных вызовов друг друга.<\/li>\n
                2. CDC<\/b> — Debezium стримит изменения из Postgres\/MySQL в реальном времени.<\/li>\n
                3. Приём потока в аналитику<\/b> — события пишутся в Kafka, оттуда попадают в ClickHouse и подобные хранилища.<\/li>\n
                4. Log aggregation<\/b> — центральный буфер логов и метрик перед системами мониторинга.<\/li>\n<\/ol>\n

                  Минимальный рабочий пример<\/h2>\n
                  kafka-topics.sh --create --topic dialog-events \\\n  --partitions 6 --replication-factor 3 \\\n  --config retention.ms=2592000000   # 30 дней\n\n# producer.properties — надёжная запись\nacks=all\nenable.idempotence=true\nlinger.ms=5   # небольшая задержка ради батчинга — выше throughput<\/code><\/pre>
                  \/\/ пишем с ключом dialog_id — порядок гарантирован внутри диалога\nproducer.send(new ProducerRecord<>("dialog-events", dialogId, eventJson));\n\n\/\/ коммитим offset после обработки, а не до — at-least-once\nwhile (true) {\n    var records = consumer.poll(Duration.ofMillis(500));\n    for (var record : records) process(record);\n    consumer.commitSync();\n}<\/code><\/pre>",
            "summary": "В очереди сообщение живёт до первого прочтения: воркер забрал — брокер удалил. Удобно для задач «сделай что-то один раз», но плохо подходит, если один и тот же поток данных нужен нескольким системам сразу",
            "date_published": "2026-08-11T19:16:35+04:00",
            "date_modified": "2026-08-11T20:35:51+04:00",
            "tags": [
                "kafka",
                "брокеры"
            ],
            "image": "https:\/\/i-am-roma.com\/pictures\/cover.jpg",
            "_date_published_rfc2822": "Tue, 11 Aug 2026 19:16:35 +0400",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "3",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/i-am-roma.com\/pictures\/cover.jpg",
                    "https:\/\/i-am-roma.com\/pictures\/diagram-queue-vs-log.jpg",
                    "https:\/\/i-am-roma.com\/pictures\/diagram-commit-log.jpg",
                    "https:\/\/i-am-roma.com\/pictures\/diagram-cluster-anatomy.jpg",
                    "https:\/\/i-am-roma.com\/pictures\/diagram-consumer-groups.jpg",
                    "https:\/\/i-am-roma.com\/pictures\/diagram-delivery-spectrum.jpg"
                ]
            }
        }
    ],
    "_e2_version": 4199,
    "_e2_ua_string": "Aegea 11.5 (v4199)"
}