Анатомия Kafka

• Что такое Kafka
• Из чего состоит сообщение
• Быстрый пример
• Топики
• Партиции
• Смещения
• Как это работает
• Почему используются смещения и партиции
• Zookeeper
• Управление брокерами
• Координация смещений
• Выборы лидера партиций
• Мониторинг кластеров
• Асинхронность
• Продюсеры и консьюмеры
• Асинхронная коммуникация
• Распределенное сердце Kafka
• Роль брокеров
• Консьюмеры подписаны на топики
• А если только один консьюмер на топик

«Если вы нашли эту статью, значит эта тема вызвала у вас любопытство — или, возможно, вы так много слышали о платформе Kafka, что теперь решили лучше понять, что это такое и почему все о ней говорят. Вы попали по адресу. 

В этой статье мы подробно рассмотрим «анатомию» этого брокера сообщений, который так широко используется в мире IT. Мы обсудим, как он работает — с иллюстрациями — и почему он стал незаменим для многих компаний.

Что такое Kafka

Не лишним будет узнать об истории Kafka. Платформа была создана в LinkedIn в 2010 году, когда компания столкнулась с проблемой, характерной для многих технологических компаний: как обрабатывать огромное количество данных, генерируемых различными системами в режиме реального времени. 

Брокер Kafka был создан для решения этой проблемы, позволяя различным системам быстро и надежно обмениваться информацией. Он был изначально разработан как масштабируемый, то есть он мог расти вместе с объемом данных и спросом на них, без потери производительности. Позже проект был передан в фонд Apache Software Foundation, со статусом открытого исходного кода, и приобрела еще большую популярность.

Если вы работаете с распределенной системой, то знаете, как сложно обеспечить эффективное взаимодействие различных частей приложения без потери данных и слишком долгой доставки сообщений. Это особенно важно, когда мы говорим об обработке данных в реальном времени.

Представьте себе компанию, занимающуюся электронной коммерцией: каждый заказ, размещенный на сайте, должен быть передан системе инвентаризации, платежной системе, и команде доставки, и все это должно быть синхронизировано, чтобы процесс работал без сбоев. Без такого решения, как Kafka, эти сообщения могут теряться или приходить с опозданием, что ставит под угрозу качество обслуживания пользователей. Kafka решает эту проблему коммуникации между системами быстрым, масштабируемым и надежным способом.

Чтобы лучше понять, как Kafka это делает, мы можем представить ее как почтовую систему. Она получает сообщения от так называемых продюсеров (систем, отправляющих данные) и доставляет их консьюмерам (системам, которым эти данные нужны). Kafka — это платформа, которая обеспечивает эффективный трафик таких сообщений. 

• Продюсеры — это отправители, которые отправляют сообщения. 
• Консьюмеры — это получатели, которые получают эти сообщения. 
• Kafka — это почтовая служба, которая организует, хранит и распределяет эти сообщения в упорядоченном виде.

Теперь поговорим о структуре сообщения в Kafka.

Основные элементы сообщения в Kafka 

При работе с Kafka сообщения (также известные как события или записи) являются сутью всех коммуникаций между системами. Поэтому важно понимать, как эти сообщения формируются и что они содержат.

Обычно сообщения, которые вы отправляете или получаете в Kafka, передаются в формате JSON, то есть в виде JSON-кода с данными, которыми вы хотите поделиться. Этот формат довольно распространен, главным образом потому что он легкий и удобочитаемый как для людей, так и для систем. 

Теперь рассмотрим основные компоненты сообщения:

• Ключ: Эта часть необязательна, но очень полезна, когда нужно обеспечить отправку связанных сообщений в одну и ту партицию (о партициях ниже). Например, если у вас есть сообщения о заказах клиентов, вы можете использовать ID клиента в качестве ключа, чтобы гарантировать, что все заказы от конкретного клиента попадут в одну и ту же партицию и будут обработаны в правильном порядке. 
• Значение: Здесь находится собственно сообщение — реальные данные, которые вы отправляете. Это значение может быть практически любым: событие, статус, ответ на опрос и т. д. В случае с JSON это будет все содержимое сообщения, передаваемого между системами. 
• Временная метка: Каждое сообщение в Kafka имеет временную метку, которая указывает, когда сообщение было создано или зарегистрировано. Это важно для контроля порядка событий и отслеживания времени создания сообщений. Временная метка очень полезна в системах, правильное функционирование которых зависит от времени наступления событий.
• Тип сжатия: В зависимости от объема данных, с которыми вы имеете дело, Kafka позволяет сжимать сообщения с помощью таких алгоритмов, как gzip или snappy. Это помогает уменьшить размер сообщения и повысить эффективность при отправке больших объемов данных без потери целостности.
• Заголовки (опционально): Небольшие необязательные метаданные, которые можно добавить в сообщение, чтобы передать дополнительную информацию, не изменяя основного содержимого. Они предназначены для передачи дополнительных данных, которые консьюмеры могут использовать для принятия решений по обработке, без изменения значения самого сообщения. 
• ID партиции и смещения: После записи сообщения в Kafka оно сохраняется в партиции и ему присваивается смещение. Эти два элемента являются основополагающими в Kafka, обеспечивая правильную доставку и чтение сообщений (далее поговорим об этих двух понятиях гораздо подробнее).

Как сообщение попадает в Кафку

Как я уже говорил, большинство сообщений, проходящих через Kafka, используют JSON в качестве формата полезной нагрузки, но могут быть и другие, в зависимости от конкретного случая. Структура выглядит примерно так:

{
  "key": "survey_123",
  "value": {
    "surveyId": "survey_123",
    "title": "Pesquisa de Preferências de Filmes",
    "question": "Qual é o seu filme favorito?",
    "answers": [
      "A Origem",
      "Interestelar",
      "O Grande Truque",
      "Dunkirk"
    ],
    "responseCount": 457,
    "createdAt": "2024-10-06T12:00:00Z",
    "updatedAt": "2024-10-08T09:45:30Z",
    "isActive": true,
    "metadata": {
      "surveyType": "multipleChoice",
      "maxResponses": 1000
    }
  },
  "timestamp": 1722873600000,
  "headers": {
    "source": "survey-platform",
    "language": "pt-BR",
    "content-type": "application/json",
    "event-type": "surveyResponse",
    "transaction-id": "f4d9a1b3-67d2-49b8-915b-df1dcee3bdf9"
  }
}

Топики

В Kafka «топики» — это категории или темы, которые эффективно упорядочивают сообщения. Каждый топик объединяет сообщения, относящиеся к одному и тому же вопросу, облегчая доступ к нужной информации и ее обработку. 

Например, в онлайн-магазине может быть один топик для заказов, другой — для платежей, третий — для уведомлений. Внутри каждого топика сообщения располагаются в хронологическом порядке, от самых старых к самым новым.

Технически топик — это место, где продюсеры отправляют (публикуют) сообщения о чем-то, а консьюмеры их читают. Таким образом, Kafka гарантирует, что информация всегда находится в нужном месте, и системы могут получить к ней быстрый и правильный доступ.

Важная деталь: организуя сообщения в топики, Kafka позволяет нескольким консьюмерам получать доступ к сообщениям одновременно и независимо друг от друга. Каждый консьюмер может «подписаться» на определенный топик и получать нужные ему сообщения, не мешая другим. 

Это особенно важно, когда мы говорим о масштабируемости. Представьте себе торговый сайт, на котором ежесекундно размещаются тысячи заказов. Если бы все заказы сбрасывались в единое неорганизованное пространство, обработка этих данных была бы хаотичной. Но с помощью топиков Kafka позволяет обрабатывать данные организованными партиями, делая коммуникацию между системами быстрой и эффективной.

Теперь, когда мы это поняли, давайте посмотрим, как Kafka делит эти сообщения на партиции, позволяя обрабатывать данные еще быстрее и масштабируемее.

Партиции

Когда мы говорим о «партициях» в Kafka, мы имеем в виду интеллектуальный способ разделения работы, чтобы сделать систему быстрее и эффективнее. Представьте, что вам нужно постоянно обрабатывать миллионы входящих сообщений. Если бы все обрабатывалось на одном конвейере, это заняло бы много времени. Именно здесь на помощь приходят партиции. 

Воспринимайте партиции как небольшие секции внутри одного топика. Хорошим примером может служить упорядочивание документов в папке. Представьте, что у вас есть папка под названием «Счета» (топик), а внутри нее вы создаете различные разделы, например «Вода», «Электричество» и «Телефон» (партиции). Вместо того чтобы сваливать все документы вперемешку, разделение их на партиции упрощает организацию и позволяет находить и обрабатывать документы гораздо быстрее.

Точно так же в Kafka партиции помогают разделить сообщения внутри топиков, что делает доступ к ним и их обработку гораздо более эффективной.

Возьмем пример с картинки выше: представьте, что у вас есть система, которая собирает ответы на опросы. Каждый раз, когда пользователь отвечает на опрос, эта система отправляет сообщение в топик Kafka под названием survey-responses. Если одновременно поступают тысячи ответов, будет очень медленно обрабатывать все последовательно, один ответ за другим. Поэтому Kafka автоматически разделяет эти ответы на партиции. 

• В партицию 0 может поступить несколько ответов от группы пользователей. 
• В партицию 1 могут поступить другие ответы, либо случайные, либо основанные на ключе (например ID опроса). 
• В партицию 2 может поступить больше ответов, что обеспечивает эффективное распределение рабочей нагрузки между различными партициями.

Эти партиции помогают распределить нагрузку на обработку между несколькими консьюмерами. Вместо одного консьюмера, обрабатывающего все ответы, вы можете иметь несколько консьюмеров, каждый из которых отвечает за обработку одной или нескольких партиций одновременно. Это гарантирует, что система сможет быстро и масштабируемо обрабатывать большие объемы ответов.

Что такое смещения? 

Представьте себе Kafka как большой логистический склад, куда со всех сторон поступают пакеты (сообщения). Склад должен организовать и отправить эти посылки в нужные пункты назначения как можно быстрее. 

Если бы все пакеты складывались в одну кучу, работа была бы хаотичной и медленной. Вместо этого склад делит упаковки на разные стеллажи — каждый из этих стеллажей представляет собой партицию. 

Теперь каждая упаковка получает этикетку с серийным номером — эта этикетка и есть смещение. Благодаря этой системе смещений работники (консьюмеры) точно знают, где и в каком порядке забирать пакеты, а если их прервут, они смогут вернуться в то место, где остановились.

После этой небольшой аналогии воспринимайте смещения как об уникальной нумерации, которую Kafka присваивает каждому сообщению в партиции. Каждый раз, когда новое сообщение записывается в партицию, оно получает номер смещения, начинающийся с 0 и увеличивающийся по мере записи новых сообщений.

Как видно на изображении, каждая партиция (0, 1 и 2) имеет последовательность смещений, и Kafka следит за сохранением порядка внутри каждой партиции. 

1. Партиции и смещения: 

На изображении показаны три партиции в топике Kafka (партиция 0, партиция 1, партиция 2). В каждой партиции сообщения записываются с последовательным смещением. Например, в партиции 0 последнее сообщение находится по смещению 9. 

2. Непрерывная запись сообщений: 

Kafka постоянно записывает новые сообщения в партиции. Стрелки справа показывают, что по мере поступления новых сообщений они записываются на следующее доступное смещение. Когда новое сообщение будет получено, оно будет записано со следующим номером смещения.

3. Уникальные смещения для каждой партиции: 

Стоит отметить, что смещения специфичны для каждой партиции. Например, в Партиции 1 последнее сообщение находится по смещению 8, а в Партиции 2 — по смещению 9. Эти последовательности могут различаться между партициями , но в пределах каждой партиции порядок всегда сохраняется.

Смещения важны, потому что они гарантируют, что консьюмеры точно знают, где остановиться и где возобновить чтение, когда они возвращаются к потреблению сообщений из топика. Если консьюмер прочитал до смещения 5 в партиции 0, при следующем опросе он начнет со смещения 6. Это гарантирует, что ни одно сообщение не будет прочитано более одного раза (если только оно не будет намеренно переработано) и что ни одно сообщение не будет пропущено. 

🚨 ВНИМАНИЕ! 🚨 Смещение не содержит самого сообщения. Оно служит «маркером», указывающим на место хранения сообщения в партиции.

Что это значит на практике? 

Представьте, что у вас есть API опроса, который собирает вопросы и ответы пользователей. Каждый раз, когда создается новый опрос, API публикует сообщение в Kafka, отправляя его в топик survey-events. В этом случае Kafka необходимо управлять большими объемами данных, особенно если этот API постоянно получает и отправляет новые опросы.

1. Публикация сообщений из API

• При создании нового опроса API публикует сообщение в топике survey-events. 
• Это сообщение содержит такую информацию, как название опроса, варианты ответов и дата создания. 

2. Партиции и смещения

• В Kafka топик survey-events разбит на партиции, что означает, что сообщения распределяются между различными партициями. 
• Каждое сообщение получает смещение в своей партиции. 
• Например, сообщение может быть отправлено в партицию 0 со смещением 10, а другое — в партицию 1 со смещением 6. Эти сообщения хранятся в ожидании, когда их прочитают консьюмеры. 

3. Консьюмеры, читающие сообщения 

• Представьте, что у вас есть две различные консьюмерские службы:
  • Служба сбора ответов: должна отслеживать каждый новый опрос и готовить систему к приему ответов. 
  • Служба анализа данных: собирает информацию об опросе для создания отчетов и аналитических материалов в режиме реального времени. 
• Обе службы потребляют сообщения из топика «Опрос — события», но Kafka распределяет между ними партиции. Смещения помогают консьюмерам узнать, где следует возобновить чтение.

4. Как смещения обеспечивают непрерывность 

• Предположим, что служба сбора ответов использует партицию 0 и уже обработала сообщение до смещения 9. Когда новое сообщение приходит по смещению 10, оно точно знает, где продолжить.
• Если служба анализа данных читает партицию 1 и обработала данные до смещения 5, она прочитает следующее сообщение по смещению 6. 
• Если какая-либо из служб временно отключится, то, вернувшись, она не потеряет последовательность сообщений. Kafka хранит смещения и гарантирует, что каждый консьюмер продолжит работу с того места, на котором остановился. 

5. Преимущества смещений 

• Без смещений невозможно гарантировать правильный порядок сообщений или избежать повторений. 
• Kafka с ее логикой партиций и смещений эффективно решает эту проблему, позволяя системе масштабироваться, сохраняя согласованность даже при очень большом объеме сообщений.

Поток 

• Создается новый опрос → API публикует сообщение в Kafka. 
• Kafka распределяет сообщение → Сообщение попадает в партицию и получает смещение. 
• Консьюмеры обрабатывают сообщения → Каждый консьюмер читает начиная с последнего смещения, на котором он остановился. 
• Восстанавливаемые сбои → Если консьюмер выходит из строя, он возобновляет чтение с последнего смещения без потери данных. 

Консьюмерские сервисы точно знают, где остановиться и возобновить работу, даже в случае сбоев. Это делает Kafka мощным инструментом для работы с распределенными системами реального времени.

Как помогают партиции и смещения? 

Партиции и смещения играют фундаментальную роль в Kafka, каждый из которых помогает по-своему: 

• Масштабируемость: Партиции играют решающую роль в обеспечении высокой масштабируемости Kafka. Когда объем сообщений растет, вы можете добавить больше консьюмеров, и каждый консьюмер может отвечать за один или несколько партиций. Это помогает распределить нагрузку, делая обработку сообщений быстрее и эффективнее, не перегружая ни одну точку обработки.
• Параллельная обработка: Разделяя топики на партиции, Kafka обеспечивает параллельную обработку. Это означает, что разные консьюмеры могут обрабатывать сообщения одновременно, ускоряя время отклика и увеличивая пропускную способность системы.

• Обслуживание заказов: Смещение — это уникальный номер, который идентифицирует каждое сообщение в партиции. Оно гарантирует, что сообщения в каждой партиции будут обрабатываться в правильном порядке. Например, если вы обрабатываете поток заказов и первое сообщение — «Заказ 1», а второе — «Заказ 2», смещение сохраняет эту последовательность внутри партиции, гарантируя, что сообщения будут прочитаны в порядке их получения.

• Непрерывность и устойчивость: Кроме того, смещение помогает обеспечить непрерывность обработки. Если консьюмер выходит из строя или нуждается в перезапуске, он может возобновить обработку с последнего обработанного смещения. Это гарантирует, что сообщения не будут потеряны и обработка продолжится с того места, где она закончилась, обеспечивая устойчивость системы.

Еще раз

• Топик = «тема» (или категория) сообщений. 
• Партиция = «отдел» внутри темы, позволяющий эффективно и параллельно обрабатывать сообщения.
• Смещение = «маркер» каждого сообщения внутри партиции, позволяющий точно управлять обработкой.

Теперь, когда мы поняли эти различия, поговорим об очень важном компоненте в Kafka.

Роль Zookeeper в Kafka 

Теперь, когда мы уже достаточно много рассказали, давайте поговорим о ключевом компоненте, который работает за кулисами: Zookeeper. Его можно сравнить с дирижером оркестра. Но вместо того, чтобы координировать музыкантов, он координирует брокеры, партиции и, в старых версиях, даже смещения и консьюмеры. Он всегда рядом, поддерживает синхронизацию, чтобы Kafka работала как хорошо настроенная машина. 

Но что на самом деле делает Zookeeper? Как он обеспечивает эффективную работу Kafka даже в условиях сбоев? Давайте погрузимся в эту тему.

Управление брокерами

Kafka — это распределенная система, а значит, у вас может быть несколько брокеров (или серверов), работающих одновременно. Каждый брокер отвечает за хранение и обработку определенного набора партиций. Но как Kafka узнает, какие брокеры активны и могут обрабатывать эти партиции? 

Это первая важная функция Zookeeper. Он ведет обновляемый список всех активных брокеров в кластере Kafka. Считайте его своего рода «менеджером», проверяющим, какие серверы работают, какие нет, и при необходимости перераспределяющим задачи.

Если брокер выходит из строя, Zookeeper действует. Он перераспределяет партиции, за которые отвечал этот брокер, в пользу другого, который еще работает. Именно это делает Kafka такой устойчивой. Даже когда часть системы выходит из строя, Zookeeper гарантирует, что Kafka продолжит работать практически незаметно для вас.

Координация смещений: тогда и сейчас 

Помните о смещениях, о которых мы говорили ранее? Они указывают консьюмеру, где Kafka должна возобновить чтение при возобновлении обработки. Но как Kafka узнает, на каком именно смещении остановился каждый консьюмер, особенно если что-то пошло не так? 

До версии Kafka 0.9: 

До версии 0.9 за хранение смещений отвечал непосредственно Zookeeper. Это означало, что каждый раз, когда консьюмер читал сообщение, Zookeeper обновлял и сохранял последнее смещение, прочитанное этим консьюмером. Если что-то шло не так, например сбой или перезапуск системы, Zookeeper имел точную запись о том, где остановился каждый консьюмер, что позволяло Kafka возобновить чтение в нужной точке. 

Такой подход хорошо работал в небольших кластерах, но по мере роста систем и добавления новых консьюмеров он стал перегружать Zookeeper. Он не был предназначен для хранения часто изменяемых данных, таких как смещения, что ограничивало масштабируемость Kafka.

Сейчас (версия 0.9 и более поздние): 

С появлением версии 0.9 Kafka начала хранить смещения внутри специального топика под названием __consumer_offsets. Теперь вместо хранения смещений напрямую, Kafka сама управляет и хранит эти данные в виде сообщений в этом топике. Это позволяет обрабатывать большие объемы консьюмеров и данных гораздо эффективнее, не перегружая Zookeeper. 

Хотя Zookeeper больше не хранит смещения напрямую, он по-прежнему играет важную роль в координации общего состояния кластера. Он следит за тем, какие брокеры активны, управляет выборами лидеров партиций, а также координирует консьюмеров и их группы.

Выборы лидера партиций

В Kafka у каждой партиции есть лидер, который является брокером, отвечающим за управление чтением и записью для этой партиции. Лидер получает сообщения от продюсеров и распределяет их среди консьюмеров, которые являются копиями данной партиции на других брокерах.

Но что произойдет, если лидер не справится или станет недоступным? Здесь на помощь приходит Zookeeper, который быстро и автоматически координирует процесс выбора нового лидера. На рисунке, если брокер-1 выходит из строя, Zookeeper определяет этот сбой и выбирает нового лидера из числа консьюмеров — в данном примере брокер-2 возьмет на себя руководство партицией -0 (и другими, если потребуется). Это гарантирует, что консьюмеры смогут продолжать читать сообщения из этой партиции.

Этот автоматический механизм обхода сбоя необходим для обеспечения высокой доступности. Даже в сценариях, когда брокер или партиция становятся недоступными, система остается устойчивой, и данные продолжают поступать. Zookeeper выполняет все управление самостоятельно, без ручного вмешательства, что позволяет Kafka быть масштабируемой и устойчивой к сбоям. 

Таким образом, благодаря Zookeeper, координирующему выборы лидеров, Kafka гарантирует, что обработка сообщений будет продолжаться даже в таких неблагоприятных ситуациях, как отказ брокера.

Мониторинг кластера 

В такой распределенной системе, как Kafka, с множеством брокеров, консьюмеров и партиций, очень важно поддерживать синхронизацию. Легко представить, какой хаос может возникнуть, если никто не будет за это отвечать. 

Zookeeper — это центральная часть оркестровки. Он следит за тем, чтобы каждый брокер знал, какими партициями он управляет, чтобы каждый консьюмер знал, где он остановился, и чтобы вся система всегда была в порядке. Он выступает в роли невидимого менеджера, обеспечивающего бесперебойную работу всех шестеренок Kafka.

Теперь представьте себе сценарий, в котором вы собираете тысячи ответов на опросы в режиме реального времени в системе Kafka с несколькими брокерами и партициями. Что произойдет, если один из брокеров выйдет из строя? Без Zookeeper вы можете потерять важные данные, или система даже перестанет обрабатывать сообщения. Это было бы катастрофой для системы!

Вот тут-то и приходит на помощь Zookeeper. Он обнаруживает сбои, перераспределяет работу между другими брокерами, координирует и делает все это настолько эффективно, что вы редко замечаете, что что-то пошло не так. Это обеспечивает высокую доступность, надежность и готовность Kafka к масштабированию по мере необходимости. 

Zookeeper не привлекает столько внимания, как другие компоненты Kafka, но это настоящий герой за кулисами. Без него Kafka потеряла бы свою устойчивость, синхронизацию и способность к самовосстановлению в случае сбоев. Он гарантирует, что все части Kafka — от брокеров до консьюмеров — всегда находятся в гармонии, работая вместе эффективно и непрерывно.

Теперь давайте подробнее остановимся на двух фундаментальных ролях, которые находятся немного за пределами экосистемы Kafka.

Асинхронность

Когда мы говорим о Kafka, мы всегда должны иметь в виду одно слово — асинхронный. В основе системы лежат продюсеры и консьюмеры, отвечающие за отправку и прием/обработку данных. Однако главный секрет эффективности Kafka заключается именно в асинхронном способе взаимодействия, позволяющем работать плавно и без жестких зависимостей между частями. Давайте разберемся, как это работает.

Продюсеры и консьюмеры: Отправка и получение

В Kafka продюсеры — это те, кто генерирует данные и отправляет их брокеру, публикуя свои сообщения в топиках. Это могут быть любые сервисы: от приложения электронной коммерции, отправляющего информацию о заказах, до системы мониторинга, отправляющей журналы ошибок. Самое важное здесь то, что продюсеры не беспокоятся о том, кто будет потреблять эти сообщения — они просто отправляют данные.

С другой стороны, консьюмеры отвечают за чтение и обработку этих сообщений. Они подписываются на интересующие их топики и, как только будут готовы, потребляют данные. Прелесть в том, что они могут делать это в своем собственном темпе, не синхронизируясь с продюсерами. Это означает, что даже если консьюмер недоступен в момент отправки сообщения, он сможет получить к нему доступ позже, поскольку Kafka хранит сообщения до тех пор, пока они не будут потреблены.

Асинхронная коммуникация

Вот где проявляется сила асинхронной связи. Когда мы говорим, что связь между продюсерами и консьюмерами асинхронна, мы имеем в виду, что для работы процесса им не нужно синхронизироваться. Продюсерам не нужно ждать, пока консьюмеры будут готовы к приему сообщений, а консьюмеры могут получать их, когда им удобно. 

Это не только позволяет избежать узких мест, но и делает сервисы чрезвычайно гибкими. Каждый компонент работает в своем темпе, не завися напрямую от другого. Если консьюмеру требуется больше времени для обработки сообщения или если объем данных очень велик, ничего не теряется и не застревает — Kafka адаптируется, временно сохраняя данные до тех пор, пока консьюмер не сможет их обработать.

Асинхронность является основополагающей в распределенных системах, особенно при больших объемах данных и взаимодействии множества сервисов друг с другом. Без асинхронности в моменты пикового трафика данных вы бы столкнулись с проблемами, зависаниями и перегрузками. На изображении выше мы видим это — API консьюмера недоступен, но Kafka обеспечит сохранение входящих сообщений до тех пор, пока консьюмер не восстановится и не возобновит их обработку. 

Такая независимость между производителями и консьюмерами, обеспечиваемая Kafka, делает систему надежной и эффективной даже в очень динамичных и масштабных средах. Все это, конечно, благодаря слову, которое следует держать в уме: асинхронный.

Распределенное сердце Kafka 

Теперь, когда мы рассмотрели журналы, разделы и консьюмеров, пришло время поговорить о брокерах. Именно они обеспечивают распределенную и масштабируемую работу Kafka. Но что именно представляют собой эти брокеры и почему они так важны? 

Представьте, что брокеры Kafka — это распределительные центры в большой логистической сети. Как и в системе доставки, где распределительные центры получают, хранят и отправляют посылки в разные пункты назначения, брокеры Kafka делают то же самое с сообщениями. Они получают сообщения от продюсеров, временно хранят их и доставляют консьюмерам организованным и эффективным способом.

Брокер в Kafka — это просто сервер, который является частью кластера Kafka. Он отвечает за получение данных от продюсеров, хранение этих сообщений в партициях (внутри топиков), а затем доставку сообщений консьюмерам, которые подписались на их чтение.

Задача брокеров

• Горизонтальная масштабируемость: Способность расти по мере увеличения нагрузки. 
• Устойчивость: Способность справляться со сбоями без прерывания работы системы. 
• Высокая доступность: Обеспечение постоянной работоспособности системы даже в случае сбоев. 

В общем, брокеры гарантируют, что все будет работать, даже когда происходят сбои. Теперь кратко обсудим некоторые вопросы, которые могут возникнуть. Я перечислю эти вопросы в виде пунктов, чтобы лучше организовать ответы.

Консьюмеры подписываются на топики или партиции? 

Консьюмеры в Kafka подписываются на топики. Когда консьюмер подписывается на топик, Kafka автоматически распределяет партиции этого топика между консьюмерами. Это означает, что каждый консьюмер будет отвечать за обработку сообщений из одной или нескольких партиций и будет читать сообщения в порядке, указанном смещениями. 

Если у вас есть топик с тремя партициями и три консьюмера, подписанных на этот топик, Kafka обеспечит, чтобы каждый консьюмер обрабатывал сообщения из разных партиций. Это гарантирует, что сообщения обрабатываются параллельно и распределенно, что делает Kafka чрезвычайно гибкой, позволяя системе масштабироваться по мере роста нагрузки.

Что делать, если в каждом топике только один консьюмер? Является ли Kafka лучшим выбором?

Вы можете задаться вопросом: «А что, если у меня только один консьюмер, интересующийся этим топиком? Будет ли Kafka по-прежнему идеальным решением?» Это правильный вопрос, в конце концов, Kafka отлично работает в сценариях, где несколько консьюмеров обрабатывают данные параллельно. Но давайте проанализируем эту ситуацию вместе. 

Kafka была разработана для работы с большими объемами данных и обработки в масштабе. Поэтому, если вы имеете дело со сценарием, в котором только один сервис или система заинтересованы в сообщениях топика, Kafka может показаться «пушкой, наведенной на муху». Но так ли это на самом деле?

Когда Kafka является хорошим выбором для одного консьюмера?

Даже если сообщения топика обрабатывает только один консьюмер, Kafka все равно может быть хорошим выбором — в зависимости от вашего сценария. Рассмотрим некоторые ситуации, в которых она выделяется: 

• Объем данных: Если вы имеете дело с большими объемами данных (даже если это всего один консьюмер), Kafka все равно может быть идеальным решением благодаря своей способности обрабатывать высокопроизводительные потоки и надежно сохранять сообщения. Производительность и масштабируемость Kafka по-прежнему являются главным преимуществом. 
• Гарантия сохранности: Kafka хранит сообщения в течение настраиваемого периода времени, а это значит, что даже если ваш единственный консьюмер будет временно отключен от сети, он сможет вернуться и «прочитать» пропущенные сообщения без каких-либо проблем.
• Масштабируемое будущее: Сегодня у вас может быть только один консьюмер, но что будет завтра? Kafka позволяет легко добавлять новых консьюмеров в будущем, если другим системам или сервисам также потребуется доступ к данным. Она адаптируется по мере развития ваших потребностей.

А в каких случаях Kafka не так уж идеальна? 

Если в вашем сценарии задействован всего один консьюмер и объем данных относительно невелик, Kafka может оказаться слишком надежным решением. В таком случае, возможно, вам больше подойдет более простая очередь сообщений (например, RabbitMQ или SQS). Эти системы легче, проще в настройке и хорошо работают в сценариях, где объем данных меньше, а простота важнее масштабируемости.

Итак, Kafka или нет? 

Ответ зависит от ваших потребностей. Если вы имеете дело с большими объемами данных, и хотите, чтобы сообщения были надежными, и думаете о будущем масштабировании, Kafka — отличный выбор, даже при наличии всего одного консьюмера. Но если ваш сценарий более легкий и не предполагает большого объема обработки или данных в масштабе, возможно, стоит рассмотреть более простые варианты. 

В конце концов, Kafka — это как ремень безопасности: он может показаться излишеством для решения небольшой задачи, но он всегда готов расти вместе с вашими требованиями.»

Chronicles of pragmatic Programmer

---