Первый раз выкладываю картинку, она из фильма "Одно дыхание" и ее стоит посмотреть! (Обучение и отдых один за другим)

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

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

Все должны быть знакомы с Kafka и ElasticSearch (далее ES), я также представил Kafka и ES в нескольких статьях ранее.
Кафка прохождение
Начало работы с ElasticSearch
ElasticSearch — Java-API
ElasticSearch — механизм поиска
Анализ основного процесса выбора ЭП

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

Обзор

И Kakfa, и ES — это компоненты, которые очень часто появляются в распределенных системах, и они превосходны в своих направлениях. Итак, прежде всего, давайте быстро представим их характеристики.

• Kafka

  Кафка — этовысокая пропускная способностьизраспределенныйопубликовать подписатьсясистема сообщений, который может обрабатывать все данные о потоке действий на веб-сайте потребительского масштаба.

  • Предоставление сообщения O (1) постоянной структурой данных диска, структура для сообщения, даже если количество Tb в стабильности хранения может поддерживаться долго.
  • Высокая пропускная способность; даже очень скромное оборудование Kafka может поддерживать миллионы сообщений в секунду.
  • Поддерживает разделение сообщений через кластеры серверов Kafka и потребителей.
  • Поддержка параллельной загрузки данных Hadoop, поддержка Spark, Flink для потоковых вычислений в реальном времени.

• ES

  • Распределенное хранилище файлов в реальном времени, каждое поле индексируется и доступно для поиска
  • Распределенная аналитическая поисковая система реального времени
  • Обрабатывать петабайты структурированных или неструктурированных данных

  Подходит для сцен:Подробный запрос, фильтр, сортировка
  Не подходит для сценариев:
  1. Большой объем данных (общее количество проиндексированных документов>=500w), высокая кардинальность (сегменты>=1000) агрегация
  2. Большой объем данных (общее количество проиндексированных документов>=500w), высокая кардинальность (уникальное значение>=10000) дедупликация (дедупликация тоже неточна)
  3. Нечеткий запрос с высокой кардинальностью (общее количество проиндексированных документов >=500w)
  4. Ассоциация Query: ES не поддерживает запрос ассоциации
  5. Многомерная составная агрегация (размер>=5): при большом количестве элементов будут серьезные проблемы с производительностью.
  6. Массовый экспорт (>=10w): не подходит для массового запроса
  7. Анализ данных: не подходит для офлайн-вычислений.
  Оцените количество сегментов: если предположить, что поля A и B имеют 10 различных значений соответственно, и сгруппировать два поля A и B одновременно, в конечном итоге будет сгенерировано 10x10 = 100 сегментов (декартово произведение различных значений). ​каждого поля — конечное количество сегментов)

Как выбрать мастер в распределенной среде

В качестве службы распределенного хранения данных Kafka и ES отличаются высокой доступностью и масштабируемостью, поэтому нет сомнений в наличии нескольких узлов. Таким образом, чтобы такое количество узлов могло работать вместе, должен существовать совместный узел, отвечающий за управление всем кластером.Этот узел кластера называется в Kafka.controller(Контроллер), мы упоминали в ESmaster.

Выбор брокера Kafka

Друзья, знакомые с кафкой, знают, что в архитектуру кафки внедрен компонент Zookeeper (зк здесь вводить не буду), который используется для управления метаданными кластера, а информация о контроллере также является одним из метаданных, поэтому контроллер kafka выбирает мастера Это реализовано, полагаясь на zk, Основной принцип заключается в следующем: Все брокеры в кластере регистрируют временные узлы с помощью zk /controller, первый из них становится брокером контроллера, а остальные регистрируют наблюдатели. Если контроллер отключается или происходит сбой, другие брокеры в кластере могут мгновенно это обнаружить и повторно инициировать регистрацию.

главный выборщик ЕС

В файле конфигурации ES есть свойство "node.master", если значение равноtrueЭто указывает на то, что узел имеет право стать главным узлом. Таким образом, основной принцип выборов ES является: имеющим право на статье главный узел инициирует каждый запрос Ping, а затем найдите наименьший идентификатор узла в узле, к которому опрос, голосование, когда узел получает более половины, узел становится главным узлом, И все узлы в кластерной информации о трансляции.

Выше приведено краткое введение в выбор Kafka Broker и ES.Среди них Kafka очень проста, потому что использует ZK, а ES сама реализует алгоритм Bully.Подробнее см.Анализ основного процесса выборов в ЕС.

модель данных

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

Основная копия выборов

Оба похожи.

Выборы лидера Кафки

Kafka использует стратегию приоритетного копирования для выбора основной копии раздела:

При создании темы будет автоматически создана коллекция AR (All Replication). Эта коллекция AR не изменится, пока не будет добавлен новый раздел, включая нештатные ситуации, такие как отключение разделов реплики. Кроме того, будет ISR ( in-sync-replication) набор синхронных реплик, этот набор является набором реплик, который в настоящее время синхронизируется с данными первичной реплики, этот набор будет меняться в зависимости от среды. Таким образом, каждый раз, когда избирается лидер первичной реплики, реплики будут изыматься из набора AR по очереди, и будет оцениваться, находится ли он в наборе ISR.Если да, то выборы будут успешными, а текущий лидер информация будет синхронизирована с зк.

ES

В ES начиная с версии 5.x введена концепция Allocation ID, которая используется для концепции выбора основного шарда.Каждый шард имеет свой уникальный Allocation ID.В то же время в метаданных кластера есть список, который записывает, какие осколки имеют последние данные. При создании индекса указание того, какой шард является основным, имеет большую гибкость, учитывая баланс кластера и другие ограничения (такие как фильтры с учетом распределения и т. д.), и даже может управляться вручную, но есть один Принцип заключается в обеспечении актуальности данных основного сегмента.

В ES также есть набор синхронных реплик, аналогичный ISR в kafka, идентификаторы синхронного выделения в ES. Поэтому первичный осколок выборов тоже должен быть в isr.

Мужчины из синхронизации данных

Поскольку режим Master-Slave, каждый из всех кластерных узлов, который неизбежно принесет консистенцию данных, а выпуски юзабилити, узлы равномерно распределяются из, Кафка и ES также в этой области имеют свой способ реализации.

Kafka

Kafka читает и записывает данные на осколке лидера, сегментирование реплик в основном предназначено для избыточного резервного копирования данных, поэтому для kafka нет проблем с согласованностью данных. Но это не означает, что данные сообщения, написанные производителем, могут быть немедленно прочитаны потребителем.Существует проблема с HW, которая будет подробно объяснена позже.

ES

Аналогично Kafka, данные ES хранятся на Shard, и Shard также будет хранить несколько копий, но есть разница, ES будет хранить всенаписать запросВсе они распределены по основному сегменту основного сегмента, но запросы на чтение будут сбалансированы по нагрузке на все сегменты реплики (включая основной сегмент) сегмента. Следовательно, есть способ гарантировать, что данные могут быть синхронизированы со всеми сегментами реплики после записи в основной сегмент. обзор здесьEs Копия модели данныхМожно понять, что вкратце это гарантируется ведением списка коммитов через основной шард. Лично мне кажется, что это очень похоже на HW Кафки. В список коммитов заносятся записи, которые все шарды совершили в конце. сегмент отключается, другие сегменты реплик также могут хранить все данные для повторного предоставления услуг.

Как хранятся данные

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

Kafka

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

Это изображение от г-на Чжу (Чжу Сяоси, автора книги «Углубленное понимание Кафки: основные принципы проектирования и практики»)
Вот краткое описание нескольких важных файлов:

• Файлы журнала .log для хранения определенных данных сообщений. Кроме того, размер каждого файла журнала ограничен, и новый файл журнала будет создан после достижения указанного размера, а имя файла также называется версией 100000000000000000000000000000000000000000000000000000000000000000000.log.
• .index смещение индексных файлов, файлов журналов и корреспонденции, имя файла и имя файла журнала совпадают, но расширение файла .index.Файл индекса не создает индекс для каждого сообщения в файле данных, а использует метод разреженного хранения (разреженный индекс) для создания индекса для каждого определенного байта данных. Это позволяет индексному файлу не занимать слишком много места, так что индексный файл можно хранить в памяти.
• .timeindex Файл индекса временной метки, однозначное соответствие с файлом журнала, имя файла совпадает с именем файла журнала, но расширение файла .timeindex. Обратите внимание, что этот файл доступен после версии 0.8.

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

Кратко обобщить

Используя LogSegment + упорядоченное смещение + разреженный индекс + бинарный поиск + последовательный поиск можно быстро найти указанное сообщение;
Последовательное добавление + кеш страницы + нулевое копирование Повышение производительности записи.

ES

ES реализован на основе Lucene, а Lucene хранит данные в сегментах, поэтому какие данные содержат сегменты и как он поддерживает поиск и агрегацию ES? По сути, это данные только с двумя структурами (плотными индексами):

• Инвертированный индекс: посмотрите на документ с точки зрения слова (термина), определите, в каком документе (docId) появляется каждая подтаблица терминов, а также количество вхождений (частота слов) и положение (относительно заголовка документа) в каждый документ. смена); term->docId
• Положительный индекс: смотрите на слова с точки зрения документа, указывая, какие слова есть в каждом документе, а также номер и позицию каждого слова; docId->term

Кроме того, при записи сегментов на диск они не изменятся.Преимущества неизменности:

1. Нет необходимости добавлять блокировки, повышать производительность записи
2. Улучшена производительность чтения.После того как файл кэшируется ОС, большинство запросов на чтение будут напрямую извлекать данные из памяти без дискового ввода-вывода.
3. Улучшить другой кеш (кэш запроса, кэш-кеш запроса, кеш FileData)

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

Так как сегменты неизменяемы, то для удаления в ES есть файл .del для отметки какой сегмент и какая запись удаляется, для модификации каждая запись в ES имеет информацию о версии, которая устарела при обновлении документа Версия помечена для удаление и создание новой версии; Когда количество сегментов слишком велико, фоновая задача ES объединит эти сегменты, и тогда записи, помеченные для удаления, будут фактически удалены в соответствии с файлом .del.

процесс записи

Для Kafka процесс записи — это то, как кластер записывает данные, отправленные производителем, в локальный файл журнала; для ES процесс записи относительно сложен.Здесь пишет не включать синхронизацию копий данных.

Kafka

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

ES

ES Каждый узел для записи данных включают буфер, Transly, обновление, Flush, Fsync, Commit Picture Concepts:

• буфер: область памяти, управляемая jvm, ограниченный размер
• translog: файл журнала, в котором хранится каждый документ
• обновление: по умолчанию выполняется каждые 1 с, записывает данные из буфера в новый сегмент (кэш файлов), и в это время данные можно искать
• flush: записать все данные из буфера в новые сегменты, сбросить сегменты из кеша системных файлов на диск, создать файл точки фиксации и одновременно сбросить диск.
• fysnc: сбросить журналы транслогов из файлового кеша на диск
• Точка фиксации: файл журнала создается, когда файл сегмента сбрасывается на диск, который в основном записывает информацию о файле сегмента.

Ниже приведен конкретный процесс написания:

1. При поступлении запроса на запись сначала запишите его в буфер, а затем синхронно запишите в файл транслога (в это время он будет записан в файловый кеш)
2. По умолчанию данные в буфере каждую 1 с или когда размер буфера заполнен, будут обновляться до нового файла сегмента в файловом кеше, и буфер будет одновременно очищаться, и данные могут быть получены только В настоящее время.поиск почти в реальном временипричина
3. Каждые 30 минут, или размер транслога достигает определенного размера, будет запускаться операция сброса, которая сбрасывает на диск все файлы сегментов в файловом кеше, а также сбрасывает транслог на диск и генерирует точку фиксации. файл, файл, записанный в Какие сегменты были сброшены на этот раз, файл транслога будет очищен в конце;
4. Из приведенного выше процесса мы знаем, что транслог также сначала записывается в файловый кеш.На самом деле, в фоновом режиме ES транслог будет сбрасываться на диск каждые 5 с (можно настроить).Эта операция называется fsync;И в течение 5 с, если машина выключена, произойдет реальная потеря данных.
5. Когда на диске появляется все больше и больше файлов сегментов, произойдет операция слияния, в процессе слияния будут удалены данные согласно файлу .del, а также сгенерирован новый файл точки коммита;

Выше описан процесс записи данных ES на шард, и существует риск потери данных на шаге 4.

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

Суммировать

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

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

Трудолюбивые разработчики кода — это не только разработчики кода, но и переносчики знаний!