Phenquestions
Обратите внимание, что это не вводное занятие. Прочтите, что такое Apache Kafka и как он работает, прежде чем продолжить этот урок, чтобы получить более глубокое представление.
Темы в Кафке
Тема в Kafka - это то, куда отправляется сообщение. Потребительские приложения, которые заинтересованы в этой теме, помещают сообщение в эту тему и могут делать с этими данными все, что угодно. До определенного времени любое количество пользовательских приложений может получать это сообщение любое количество раз.
Рассмотрим такую тему, как страница блога Ubuntu LinuxHint. Уроки откладываются на вечность, и любое количество читателей-энтузиастов может приходить и читать эти уроки любое количество раз или переходить к следующему уроку по своему желанию. Этим читателям могут быть интересны и другие темы из LinuxHint.
Разделение тем
Kafka предназначен для управления тяжелыми приложениями и постановки в очередь большого количества сообщений, которые хранятся в теме. Для обеспечения высокой отказоустойчивости каждая тема разделена на несколько тематических разделов, и каждый раздел темы управляется на отдельном узле. Если один из узлов выходит из строя, другой узел может выступать в роли лидера темы и может передавать темы заинтересованным потребителям. Вот как одни и те же данные записываются в несколько разделов темы:
Разделы тем
Теперь на изображении выше показано, как одни и те же данные реплицируются в нескольких разделах. Давайте визуализируем, как разные разделы могут выступать в качестве лидера на разных узлах / разделах:
Kafka Broker Partitioning
Когда клиент что-то записывает в тему в позиции, для которой раздел в брокере 0 является лидером, эти данные затем реплицируются между брокерами / узлами, чтобы сообщение оставалось безопасным:
Репликация между разделами брокера
Больше разделов, более высокая пропускная способность
Кафка использует Параллелизм для обеспечения очень высокой пропускной способности для приложений производителей и потребителей. Фактически, таким же образом он также сохраняет свой статус отказоустойчивой системы. Давайте разберемся, насколько высокая пропускная способность достигается с помощью параллелизма.
Когда приложение-производитель записывает какое-либо сообщение в раздел в брокере 0, Kafka открывает несколько потоков параллельно, чтобы сообщение могло быть реплицировано для всех выбранных брокеров одновременно. На стороне потребителя приложение-потребитель получает сообщения из одного раздела через поток. Чем больше количество разделов, тем больше потоков-потребителей можно открыть, чтобы все они могли работать параллельно. Это означает, что чем больше разделов в кластере, тем больше можно использовать параллелизм, создавая систему с очень высокой пропускной способностью.
Больше разделов требует больше обработчиков файлов
Как раз для того, чтобы вы изучили выше, как мы можем повысить производительность системы Kafka, просто увеличив количество разделов. Но мы должны быть осторожны с тем, к какому пределу мы движемся.
Каждый раздел темы в Kafka сопоставлен с каталогом в файловой системе серверного брокера, на котором он запущен. В этом каталоге журнала будет два файла: один для индекса, а другой для фактических данных на сегмент бревна. В настоящее время в Kafka каждый брокер открывает дескриптор файла как для индекса, так и для файла данных каждого сегмента журнала. Это означает, что если у вас есть 10 000 разделов на одном брокере, это приведет к параллельной работе 20000 обработчиков файлов. Хотя, это примерно конфигурация Брокера. Если система, на которой развернут брокер, имеет высокую конфигурацию, это вряд ли будет проблемой.
Риск с большим количеством разделов
Как мы видели на изображениях выше, Kafka использует технику внутрикластерной репликации для репликации сообщения от лидера на разделы реплики, которые находятся в других брокерах. И производитель, и потребительское приложение читают и записывают в раздел, который в настоящее время является лидером этого раздела. Когда брокер выходит из строя, лидер этого брокера становится недоступным. Метаданные о том, кто является лидером, хранятся в Zookeeper. На основе этих метаданных Kafka автоматически назначит руководство раздела другому разделу.
Когда брокер завершается с помощью чистой команды, узел контроллера кластера Kafka будет последовательно перемещать лидеров завершающего брокера i.е. один за раз. если учесть, что перемещение одного лидера занимает 5 миллисекунд, недоступность лидеров не будет беспокоить потребителей, так как недоступность происходит в течение очень короткого периода времени. Но если мы рассмотрим, когда брокер убит нечистым образом, и этот брокер содержит 5000 разделов, из которых 2000 были лидерами разделов, назначение новых лидеров для всех этих разделов займет 10 секунд, что очень много, когда дело доходит до высокого уровня. востребованные приложения.
Заключение
Если мы рассматриваем как высокоуровневого мыслителя, большее количество разделов в кластере Kafka приводит к более высокой пропускной способности системы. Помня об этой эффективности, нужно также учитывать конфигурацию кластера Kafka, который нам нужно поддерживать, память, которую нам нужно назначить этому кластеру, и то, как мы можем управлять доступностью и задержкой, если что-то пойдет не так.
Прочтите больше сообщений на основе Ubuntu здесь, а также многое другое об Apache kafka.
