Потому что kafka часто используется в работе, но некоторые внутренние механизмы kafka не очень знакомы, поэтому я недавно читал информацию, связанную с kafka.Мы знаем, что kafka - это очень классический движок сообщений, который известен своей высокой производительностью и высоким доступность. Итак, вопрос в том, как добиться высокой производительности и высокой доступности? В какой форме сохраняются его сообщения? Теперь, когда диск записан, почему он все еще такой быстрый? Как это гарантирует, что сообщения не будут потеряны...? С этой серией вопросов давайте снимем завесу кафки.
Во-первых, давайте подумаем об этом: Зачем вам мессенджер? Почему вы не можете просто использовать RPC напрямую? Возьмем в качестве примера систему заказов: когда мы размещаем заказ, мы должны сначала уменьшить запасы товара, затем пользователь платит и вычитает деньги, а торговый счет добавляет деньги..., и, наконец, мы можем отправить push-уведомление или SMS на скажите пользователю разместить заказ Успех, скажите продавцу разместить заказ.
Если весь процесс заказа заблокирован синхронно, процесс займет больше времени, время ожидания пользователя будет больше, а опыт будет не очень хорошим.В то же время, чем длиннее ссылка, на которую опирается процесс заказа, тем больше риск. Чтобы ускорить реакцию и снизить риски, мы можем разобрать некоторые сервисы, которые не обязательно застревают в основной ссылке, и отделить их от основного сервиса. Наиболее важным ядром размещения заказа является обеспечение согласованности запасов, платежей пользователей и платежей продавцов, а уведомление о сообщениях может быть полностью асинхронным. Таким образом, весь процесс заказа не будет заблокирован из-за уведомления продавца или пользователя о том, что он заблокирован, и при этом не будет выведено предупреждение о том, что заказ не выполнен из-за их ошибки.
Следующим шагом является проектирование механизма сообщений.С точки зрения макросов, механизм сообщений поддерживаетОтправить,место хранения,перениматьВот и все.
Затем появляется простая модель очереди сообщений, как показано на рисунке выше: Engine хранит сообщение отправителя, так что, когда получатель приходит к Engine за данными, Engine отвечает получателю из хранилища, и все в порядке. Поскольку задействовано постоянное хранилище, медленный дисковый ввод-вывод является проблемой, которую следует учитывать. Также может быть более одного получателя. Взяв в качестве примера приведенный выше заказ, после того, как заказ выполнен, событие завершения отправляется через сообщение. В это время разработка, ответственная за push-уведомление на стороне пользователя, должна использовать это сообщение. , и разработка, отвечающая за push-уведомление на стороне продавца, также должна потреблять сообщение. Для этого сообщения самый простой способ, который я могу придумать, — это скопировать два набора сообщений, но не кажется ли это немного расточительным? Также следует учитывать высокую доступность, поэтому, если у нашего механизма есть копия, после того, как у него есть копия, в случае сбоя узла механизма мы можем выбрать новую копию для работы. Недостаточно иметь только копии, и отправителей может быть несколько.В настоящее время кажется неразумным, если все отправители отправляют данные на один ведущий (главный) узел, а нагрузка на один узел слишком велика. Может быть, вы скажете: разве нет копии? Пусть получатель прочитает сообщение прямо из реплики. Отсюда возникает еще одна проблема: что делать, если сообщение лидера репликации реплики задерживается? Не можете прочитать сообщение и снова прочитать Лидера? Если это так, то конструкция двигателя представляется более сложной, что кажется неразумным. Затем вам нужно придумать метод, который может рассеять давление одного узла, не проходя через копию.Ответ — технология сегментирования.Поскольку давление на один узел-лидер слишком велико, он делится на несколько узлов-лидеров.Мы нужен только хороший алгоритм балансировки нагрузки, достаточно равномерно распределять сообщения по каждому узлу шарда с помощью балансировки нагрузки, поэтому мы можем разработать набор моделей производитель-потребитель примерно такой длины.
Но это всего лишь простые идеи, и как их реализовать все еще очень сложно.С этой серией вопросов и идей давайте посмотрим, как реализуется kafka.
Подумай и осознай
Прежде всего, давайте начнем с нескольких терминов кафки, в основном представляющих сообщения, темы, разделы и группы потребителей.
Как оформить сообщение
Сообщение является источником службы. Все предназначено для отправки сообщения с одного конца на другой. Это включает в себя структуру сообщения. Тело сообщения не должно быть слишком большим. Если тело сообщения слишком велико, хранилище стоимость увеличится, а накладные расходы на передачу по сети увеличатся, поэтому тело сообщения должно содержать только необходимую информацию, желательно без избыточности. Сообщение предпочтительно также поддерживает сжатие.Благодаря сжатию само тело сообщения может быть уменьшено до меньшего размера, так что можно еще больше уменьшить нагрузку на хранилище и сеть. Сообщения должны быть постоянными.Использованные сообщения не могут храниться вечно, или очень старые сообщения вряд ли будут использованы снова.Необходим механизм для очистки старых сообщений и освобождения места на диске.Как найти старые сообщения.Сообщение является ключевым, поэтому лучше всего иметь временную метку при создании сообщения, вычислять старое сообщение по временной метке и удалять его при необходимости. Сообщения также должны быть пронумерованы.С одной стороны, номер представляет собой местонахождение сообщения, а с другой стороны, потребители могут найти соответствующее сообщение по номеру. Как хранить большое количество сообщений тоже проблема.Все они хранятся в одном файле.Эффективность запросов низкая и не способствует очистке старых данных.Поэтому используется сегментация,чтобы разрезать большие лог-файлы на несколько относительно небольшие лог-файлы.Для улучшения ремонтопригодности при вставке сообщения нужно только добавить его в конец сегмента, но при поиске сообщения, если весь сегмент загружается в память один за другим, кажется, требуется много накладных расходов на память, поэтому набор механизмов индексирования для ускорения доступа к соответствующему сообщению посредством индексирования.
Суммировать: сообщение kafka содержитсоздать время,порядковый номер сообщения,Поддержка сжатия сообщений, журнал, в котором хранятся сообщения,сегментированное хранилище, и естьпоказательиз.
Зачем нужна Тема
С точки зрения макроса, механизм сообщений — это один отправляющий и один получающий.Есть проблема: производитель A хочет отправить сообщение потребителю B, и в то же время отправляет сообщение потребителю C. Так как же потребитель B и потребитель C могут потреблять только те данные, которые им нужны? Самый простой способ придумать — это добавить тег к сообщению, и потребители могут получать свои собственные сообщения в соответствии с тегом, вместо того, чтобы напрямую пропускать свои собственные сообщения, но это не кажется очень элегантным, и на это тратятся ресурсы ЦП. фильтрация сообщений. Поэтому самый действенный способ - не давать С в Б, и не давать Б в В. Это Тема. Чтобы различать различные услуги по темам, каждому потребителю нужно подписаться только на тему, которая его волнует.Производитель отправляет сообщение, которое нужно потребителю, через согласованную тему.Простое понимание состоит в том, что сообщение классифицируется в соответствии с темой.
Суммировать: ТемалогикаПонятие Topic можно хорошо разделить на бизнес, и каждому потребителю достаточно обратить внимание только на свой Topic.
Как перегородки гарантируют порядок
Из вышеизложенного мы знаем, что цель разделения состоит в том, чтобы рассредоточить давление одного узла, а затем объединить Тему и Сообщение, тогда примерное наслоение сообщений Топик (topic) -> Partition (раздел) -> Message (сообщение ). Вы можете спросить, поскольку раздел предназначен для уменьшения нагрузки на один узел, почему бы не использовать несколько тем вместо нескольких разделов, в случае нескольких машинных узлов мы можем развернуть несколько тем на нескольких узлах, кажется. Это также может быть Это кажется осуществимым, если подумать, но неправильным, если хорошенько подумать. В конце концов, мы все еще должны обслуживать бизнес.В этом случае бизнес темы должен быть разобран на несколько тем, но определение бизнеса разбито.
Ну так как есть несколько разделов,распределение сообщений является проблемой.Если данные по теме слишком сконцентрированы на определенном разделе,то это вызовет неравномерное распределение.Для решения этой проблемы очень полезен хороший алгоритм распределения.Необходимо .
кафка поддержкаметод опроса, то есть в случае нескольких разделов, сообщения могут быть равномерно распределены по каждому разделу через опрос.Здесь следует отметить, что данные в каждом разделе упорядочены, но общие данные не могут быть гарантированы.Если ваш бизнес сильно зависит по порядку сообщений, то вы должны внимательно рассмотреть эту схему.Например, производитель отправляет три сообщения A, B и C по очереди, и они распределены по трем разделам, поэтому может быть возможный порядок потребления.Это B , А, С.
Так как же обеспечить порядок сообщений? С общей точки зрения, пока количество разделов больше 1, порядок сообщений никогда не может быть гарантирован, если вы не установите количество разделов равным 1, но тогда пропускная способность становится проблемой. Из фактического бизнес-сценария, как правило, нам могут понадобиться сообщения определенного пользователя или сообщения определенного продукта по порядку. Однако мы можем захотеть сохранить сообщения пользователя А. Например, сообщения описывают пользователя. поведение, и порядок поведения не может быть хаотичным. В настоящее время мы можем рассмотреть возможность использованияkey hashТаким образом, один и тот же идентификатор пользователя всегда может быть назначен разделу с помощью хеширования.Мы знаем, что раздел упорядочен, поэтому в этом случае сообщения одного и того же пользователя должны быть упорядочены, а разные пользователи могут быть назначены на разные разделов, это также использует функцию нескольких разделов.
Суммировать: упорядоченность всего сообщения Kafka не может быть гарантирована, но упорядоченность сообщений одного раздела может быть гарантирована.
Как разработать разумную потребительскую модель
Поскольку модель сообщений разработана, потребители необходимы.Самый простой способ добиться потребителей — это запустить процесс или поток, чтобы получать сообщения непосредственно от брокера.Это разумно, но если скорость производства больше, чем текущая скорость потребления, что делать? делать? Первое, что приходит в голову, это запустить еще один потребитель и использовать несколько потребителей для увеличения скорости потребления.Здесь, похоже, есть еще одна проблема.Что если два потребителя потребляют одно и то же сообщение? Блокировка — это решение, но эффективность будет снижена.Можно сказать, что сущность потребления — это чтение, а чтение может быть общим.Пока бизнес идемпотентный, не имеет значения, потребляется ли сообщение повторно. В этом случае, если 10 потребителей соревнуются за одно и то же сообщение, 9 потребителей будут тратить ресурсы напрасно. Следовательно, хотя для улучшения своих возможностей потребления требуется несколько потребителей, также необходимо обеспечить, чтобы каждый потребитель потреблял необработанные сообщения.группа потребителей, в группе потребителей может быть несколько потребителей. Мы знаем, что тема разделена, поэтому, если каждый потребитель в группе потребителей подписывается на другой раздел, все в порядке. В идеале каждому потребителю выделяется одинаковое количество разделов данных.Если количество разделов, полученных потребителем, неравномерно (более или менее) и данные искажены, некоторые потребители будут очень заняты или расслаблены, это неразумно, что требует сбалансированной стратегии распределения.
Существует три основных стратегии распределения потребительских разделов Kafka:
- Range: Эта стратегия для топиков.Количество разделов топика и количество потребителей будет делиться на единицу.Если есть остаток, значит лишние разделы не разделены поровну.В это время потребители в топике фронт получит больше очков.1 перегородка на самом деле вполне разумна на первый взгляд, ведь число не сбалансировано. Однако если потребитель подписывается на несколько тем, и каждая тема имеет в среднем еще несколько разделов, то потребители впереди будут использовать гораздо больше разделов.
Так как он разделен по размерности темы, в итоге:
- c1 потребляет Topic0-p0, Topic0-p1, Topic1-p0, Topic1-p1
- c2 потребляет Topic0-p2, Topic1-p2
В итоге можно обнаружить, что потребитель c1 имеет на два раздела больше, чем потребитель c2, и вполне возможно разделить раздел c1 на c2, чтобы его можно было сбалансировать.
- RoundRobin: Принцип этой стратегии заключается в сортировке разделов всех потребителей в группе потребителей и всех темах, на которые подписаны потребители, в лексикографическом порядке, а затем присваивании разделов каждому потребителю по одному с помощью алгоритма опроса. Допустим теперь есть две темы, в каждой по 3 раздела, и 3 потребителя. Тогда общая ситуация с потреблением выглядит следующим образом:
- c0 потребляет Topic0-p0, Topic1-p0
- c1 потребляет Topic0-p1, Topic1-p1
- c2 потребляет Topic0-p2, Topic1-p2
Это кажется идеальным, но если теперь есть 3 темы и количество разделов для каждой темы несовместимо, например, у темы 0 есть только одна секция, у темы 1 есть две секции, у темы 2 есть три раздела, а потребитель c0 подписывается на тему 0, потребитель c1 подписывается на топик0 и топик1, а потребитель с2 подписывается на топик0, топик1, топик2, то общая ситуация потребления следующая:
- Расход C0 Topic0-P0
- потребление c1 Topic1-p0
- c2 потребляет Topic1-p1, Topic2-p0, Topic2-p1, Topic2-p2
Таким образом, RoundRobin не идеален.Не принимая во внимание разницу в пропускной способности каждой секции топика, можно увидеть, что бремя потребления c2 очевидно велико, и секция Topic1-p1 может быть отнесена к потребителю c1.
- Sticky: Range и RoundRobin имеют свои недостатки, в некоторых случаях можно было сделать более сбалансированным, но не обошлось.
Одной из целей внедрения Sticky является:Распределение перегородок должно быть максимально равномерным. В случае вышеописанного RoundRobin 3 темы, соответствующие 1, 2 и 3 разделам соответственно, потому что c1 может полностью потреблять Topic1-p1, но не делает этого. В ответ на эту ситуацию в режиме Sticky Topic1-p1 можно назначить c1.
Вторая цель внедрения Sticky:Разделы размещаются как можно ближе к последнему выделению. Основным решением здесь является проблема перераспределения партиций после перебалансировки. Предположим, что есть три потребителя c0, c1 и c2. Все они подписаны на топик 0, топик 1, топик 2 и топик 3, и каждый топик имеет два раздела. Ситуация наверное такая:
Этот метод распределения в настоящее время ничем не отличается от RoundRobin, но если потребитель c1 выходит в это время, в группе потребителей остаются только c0 и c2. Затем вам нужно перераспределить раздел c1 на c0 и c2.Давайте посмотрим, как ребалансируется RoundRobin:
Можно обнаружить, что исходная тема 1-p1 из c0 назначается c2, а исходная тема 1-p0 из c2 назначается c0. Эта ситуация может вызвать проблему повторного потребления.Когда потребитель не успел подать заявку, обнаруживается, что раздел был выделен новому потребителю, и новый потребитель будет генерировать повторное потребление. Но с теоретической точки зрения, после выхода c1 нет необходимости перемещать разделы c0 и c2, просто разделите исходный раздел c1 на c0 и c2, это липкий подход:
Следует отметить, что в стратегии Sticky, еслиРаспределение перегородок должно быть максимально равномернымиРазделы размещаются как можно ближе к последнему выделениюВ случае конфликта приоритет будет отдан первому.
Суммировать: kafka по умолчанию поддерживает указанные выше три стратегии выделения разделов, а также поддерживает настраиваемое выделение разделов. Пользовательский метод необходимо реализовать самостоятельно. Из эффекта RoundRobin лучше, чем Range, а Sticky лучше, чем RoundRobin. Рекомендуется вы используете версию, поддерживаемую лучшей стратегией.
Прошлые основные моменты:
- Узнайте больше о замках в одной статье
- Одна статья, чтобы понять откат и сохранение
- Эволюция модели Redis IO
Wechat ищет [делает вид, что разбирается в программировании], получает электронные книги и делится опытом интервью с крупными фабриками.