Во время интервью я обнаружил, что многие интервьюеры особенно любят задавать вопросы, связанные с Kafka. Нетрудно понять, кто делает Kafka единственным королем очередей сообщений в области больших данных с пропускной способностью одной машины в 100000 и задержкой в миллисекунды. Кому может не понравиться такая естественная распределенная очередь сообщений?
В недавнем интервью интервьюер увидел, что Кафка был написан на пункте в резюме, поэтому он спросил Кафку напрямую, и в основном не задавал других вопросов. Давайте взглянем на восемь последовательных вопросов Кафки интервьюера:
(Следующие ответы составлены после интервью, и только около трети ответов были даны во время самого интервью)
1. Зачем использовать Кафку?
Буферизация и ограничение пиков: когда происходит всплеск восходящих данных, нисходящий поток может быть не в состоянии его обработать, или в нисходящем потоке недостаточно машин для обеспечения избыточности. Kafka может действовать как буфер в середине, временно сохраняя сообщения в Kafka и нижестоящем. Услугу можно обрабатывать медленно, в своем собственном темпе.
Разделение и масштабируемость: в начале проекта конкретные требования не могут быть определены. Очередь сообщений может использоваться в качестве уровня интерфейса для разделения важных бизнес-процессов. Вам нужно только соблюдать соглашения, и вы можете получить возможности расширения для программирования данных.
Избыточность: может использоваться подход «один ко многим» .Производитель публикует сообщение, которое может быть использовано несколькими тематическими службами подписки для использования несколькими несвязанными предприятиями.
Надежность: в очереди сообщений могут накапливаться запросы, поэтому, даже если бизнес-клиент умрет в ближайшее время, это не повлияет на нормальную работу основного бизнеса.
Асинхронная связь: во многих случаях пользователи не хотят или не должны обрабатывать сообщения немедленно. Очередь сообщений предоставляет механизм асинхронной обработки, который позволяет пользователям помещать сообщение в очередь, но не обрабатывает его немедленно. Поместите в очередь столько сообщений, сколько хотите, а затем обработайте их при необходимости.
2. Как использовать сообщения, которые были обработаны Kafka?
Смещение сообщений потребления Kafka определяется в zookeeper. Если вы хотите многократно использовать сообщения Kafka, вы можете записать контрольные точки смещения (n) в redis. Если вы хотите использовать сообщения повторно, прочтите контрольные точки в redis. Сбросьте смещение zookeeper, чтобы вы могли добиться многократного потребления сообщений
3. Данные Kafka хранятся на диске или в памяти, почему скорость выше?
Кафка использует дисковое хранилище.
Скорость высокая, потому что:
- Последовательная запись: поскольку жесткий диск представляет собой механическую структуру, каждое чтение и запись будут адресованы -> записи, где адресация - это «механическое действие», на это требуется много времени. Таким образом, жесткие диски «ненавидят» случайный ввод-вывод и предпочитают последовательный ввод-вывод. Для увеличения скорости чтения и записи жестких дисков Kafka использует последовательный ввод-вывод.
- Файлы с отображением в памяти: 64-разрядная операционная система обычно может представлять файлы данных объемом 20 г. Ее принцип работы заключается в прямом использовании страницы операционной системы для реализации прямого отображения файлов в физическую память. После завершения сопоставления ваши операции с физической памятью будут синхронизированы с жестким диском.
- Эффективный дизайн хранилища файлов Kafka: Kafka разделяет большой файл раздела в теме на несколько небольших файловых сегментов. С помощью нескольких небольших файловых сегментов легко периодически очищать или удалять файлы, которые были использованы, и уменьшать использование диска. Индексная информация позволяет быстро найти
сообщение и определить размер ответа. Путем отображения всех метаданных индекса в память (файл с отображением памяти)
можно избежать дисковых операций ввода-вывода файла сегмента. За счет разреженного хранения файлов индекса можно значительно уменьшить пространство, занимаемое метаданными файла индекса.
Заметка:
- Один из методов Kafka для определения эффективности запросов - сегментировать файлы данных. Например, есть 100 сообщений, а их смещение составляет от 0 до 99. Предположим, что файл данных разделен на 5 сегментов, первый сегмент - 0-19, второй сегмент - 20-39 и т. Д., Каждый сегмент помещен в отдельный файл данных, а файл данных назван в честь небольшого смещения в сегменте. Таким образом, при поиске
сообщения с указанным смещением можно использовать двоичный поиск, чтобы определить, в каком сегменте находится сообщение.- Построение индекса для сегментации файла данных файла данных позволяет найти Сообщение, соответствующее смещению в меньшем файле данных, но для этого по-прежнему требуется последовательное сканирование, чтобы найти Сообщение, соответствующее смещению.
Чтобы еще больше повысить эффективность поиска, Kafka создает файл индекса для каждого файла сегментированных данных. Имя файла такое же, как имя файла данных, но расширение файла - .index.
4. Как не потерять данные Kafka?
В трех пунктах одна - сторона производителя, сторона потребителя и сторона брокера.
- Без потери данных производителя
Механизм подтверждения Kafka: когда Kafka отправляет данные, каждый раз, когда отправляется сообщение, будет механизм обратной связи с подтверждением, чтобы гарантировать, что сообщение может быть получено в обычном режиме, и статус равен 0, 1, -1.
Если это синхронный режим:
ack имеет значение 0, что очень рискованно. Как правило, не рекомендуется устанавливать значение 0. Даже если он установлен в 1, данные будут потеряны при падении лидера. Поэтому, если вы хотите строго гарантировать, что конечные данные не будут потеряны, вы можете установить его на -1.
Если это асинхронный режим:
также будет учитываться статус подтверждения. Кроме того, есть буфер в асинхронном режиме. Управляющие данные отправляются через буфер. Для управления есть два значения: порог времени и количество сообщений. Если буфер заполнен и данные не были отправлены, есть возможность настроить, очищать ли буфер немедленно. Его можно установить на -1, чтобы заблокировать навсегда, что означает, что данные больше не производятся. В асинхронном режиме, даже если установлено значение -1. Также возможно, что данные операции потеряны из-за ненаучных операций программиста, таких как kill -9, но это особое исключение.
Примечание:
ack = 0: производитель не ждет подтверждения завершения синхронизации брокера и продолжает отправлять следующее (пакетное) сообщение.
ack = 1 (по умолчанию): производитель ожидает, пока лидер успешно получит данные и получит подтверждение перед отправкой следующего сообщения.
ack = -1: производитель отправит следующий фрагмент данных только после получения подтверждения от подписчика.
- Без потери данных о потребителях
Фиксация смещения используется, чтобы гарантировать, что данные не будут потеряны. Kafka записывает значение смещения для каждого потребления. Когда он продолжит потребление в следующий раз, он продолжит потребление с последним смещением.
Информация о смещении сохраняется в zookeeper до версии 0.8 kafka и сохраняется в теме после версии 0.8. Даже если потребитель зависает во время работы, значение смещения будет найдено при перезапуске, и будет найдено предыдущее сообщение о потреблении. Местоположение, затем потребление, потому что, когда записывается информация о смещении, не каждое сообщение записывается после завершения потребления, поэтому эта ситуация может вызвать повторное потребление, но сообщение не будет потеряно.
Единственное исключение - когда мы устанавливаем
KafkaSpoutConfig.bulider.setGroupid на один и тот же groupid, когда мы устанавливаем KafkaSpoutConfig.bulider.setGroupid на две группы потребителей, которые изначально выполняли разные функции в программе . В этой ситуации две группы будут использовать одни и те же данные. Группа A будет принимать сообщения в разделе 1 и 2, а группа B будет получать сообщения в разделе 3. Таким образом, сообщения, потребляемые каждой группой, будут потеряны и будут неполными. Чтобы гарантировать, что каждая группа имеет исключительную долю данных сообщения, идентификатор группы не должен повторяться.
- Данные брокеров в кластере Kafka не потеряны
Обычно мы устанавливаем количество репликаций (реплик) для каждого раздела в брокере.Когда производитель записывает его, сначала записывайте его лидеру в соответствии со стратегией распространения (раздел за разделом, ключ за ключом, без опроса). , Последователь (реплика) синхронизирует данные с лидером, поэтому с помощью резервной копии он также может гарантировать, что данные сообщения не будут потеряны.
5. Почему для сбора данных выбирают кафку?
Уровень сбора данных может в основном использовать Flume, Kafka и другие технологии.
Flume: Flume - это метод конвейерного потока, который предоставляет множество реализаций по умолчанию, позволяя пользователям развертывать с помощью параметров и расширять API.
Kafka: Kafka - это надежная распределенная очередь сообщений. Кафка - очень универсальная система. У вас может быть много производителей и множество потребителей, разделяющих разные темы.
Напротив, Flume - это специальный инструмент, предназначенный для отправки данных в HDFS и HBase. Он имеет специальные оптимизации для HDFS и интегрирует функции безопасности Hadoop.
Поэтому Cloudera рекомендует использовать Kafka, если данные используются несколькими системами; если данные предназначены для использования Hadoop, используйте Flume.
6. Приведет ли перезапуск Kafka к потере данных?
- Kafka записывает данные на диск, и, как правило, данные не теряются.
- Но в процессе перезапуска Kafka, если есть потребители, которые потребляют сообщения, если Kafka не успевает отправить смещение, это может привести к неточным данным (потере или повторному использованию).
7. Как решить, если Kafka не работает?
- Сначала подумайте, затронут ли бизнес
Kafka не работает. Первый вопрос, который мы должны рассмотреть, заключается в том, влияет ли на предоставляемую услугу отключившуюся машину. Если услуга предоставляется, если реализован механизм отказоустойчивости кластера, то нет необходимости беспокоиться об этом. .
- Устранение неполадок и восстановление узлов
Чтобы восстановить узлы кластера, основным шагом является проверка причины простоя узла с помощью анализа журнала, чтобы решить проблему и снова восстановить узел.
8. Почему Kafka не поддерживает разделение чтения и записи?
В Kafka операции производителей, пишущих сообщения, и потребителей, читающих сообщения, взаимодействуют с ведущей копией, тем самым реализуя модель производства и потребления, состоящую из записи и чтения мастер-записи .
Kafka не поддерживает чтение master-write-slave , потому что чтение master-write-slave имеет два очевидных недостатка:
Проблема согласованности данных: будет временное окно задержки для данных от главного узла к подчиненному узлу. Это временное окно вызовет несогласованность данных между главным и подчиненным узлами. В определенный момент значение данных A как в главном узле, так и в подчиненном узле равно X, а затем значение A в главном узле изменяется на Y, затем, прежде чем изменение будет сообщено подчиненному узлу, приложение считывает данные A в подчиненном узле. Значение не является последним Y, что создает проблему несогласованности данных.
Проблема с задержкой: для таких компонентов, как Redis, процесс записи данных с главного узла для синхронизации на подчиненный узел должен проходить через этапы сеть → память основного узла → сеть → память ведомого узла. Весь процесс займет определенное количество времени. В Kafka синхронизация ведущий-ведомый занимает больше времени, чем Redis. Она должна проходить через этапы сеть → память основного узла → диск основного узла → сеть → память ведомого узла → диск ведомого узла. Для приложений, чувствительных к задержке, функция записи ведущего и чтения ведомого не очень подходит.
И у мастера-читателя kafka есть много преимуществ:
- Может упростить логику реализации кода и снизить вероятность ошибок;
- Детализация нагрузки уточняется и равномерно распределяется, по сравнению с основной записью и подчиненным чтением, не только производительность загрузки лучше, но также управляемость пользователем;
- Эффект задержки отсутствует;
- Когда копия стабильна, несоответствия данных не будет.