Асинхронная передача данных это способ передачи с задержкой времени или без задержки времени

Синхронная и асинхронная передача данных

Синхронный способ передачи данных — способ передачи цифровых данных по последовательному интерфейсу, при котором приемнику и передатчику известно время передачи данных, то есть, передатчик и приемник работают синхронно, в такт. Синхронизация приемника и передатчика достигается либо путем ввода синхронизирующей последовательности (например, в начале передачи данных передается детерминированный сигнал с известным переключением состояний из «нуля» в «единицу», по времени прихода происходит синхронизация приемника и передатчика, путем выставления стробирующих импульсов в центр битового интервала), либо путем применения способа кодирования с самосинхронизацией при передаче каждого бита данных [1] . К самосинхронизирующим кодам относят: RZ, Манчестер-II, MLT-3. Асинхронныйспособ передачи данных — такой способ передачи цифровых данных от передатчика к приемнику по последовательному интерфейсу, при котором данные передаются в любой момент времени. Для того, чтобы приёмник инициировал прием данных, вводятся специальные битовые последовательности, обрамляющие данные. Перед началом передачи данных передается стартовый бит, в конце передачи данных передается стоповый бит[1].

Понятие об узкополосном и широкополосном способе передачи данных

Узкополосная система (baseband) использует цифровой способ передачи сигнала. Хотя цифровой сигнал имеет широкий спектр и теоретически занимает бесконечную полосу частот, на практике ширина спектра передаваемого сигнала определяется частотами его основных гармоник. Именно они дают основной энергетический вклад в формирование сигнала. В узкополосной системе передача ведется в исходной полосе частот, не происходит переноса спектра сигнала в другие частотные области. Именно в этом смысле система называется узкополосной. Сигнал занимает практически всю полосу пропускания линии. Для регенерации сигнала и его усиления в сетях передачи данных используют специальные устройства – повторители (repeater, репитор).

Примером реализации узкополосной передачи являются локальные сети и соответствующие спецификации IEEE (например, 802.3 или 802.5).

Ранее узкополосная передача из-за затухания сигналов использовалась на расстояниях порядка 1-2 км по коаксиальным кабелям, но в современных системах, благодаря различным видам кодирования и мультиплексирования сигналов и видам кабельных систем, ограничения отодвинуты до 40 и более километров.

Термин широкополосная (broadband) передача изначально использовался в системах телефонной связи, где им обозначался аналоговый канал с диапазоном частот (шириной полосы пропускания) более 4 КГц. С целью экономии ресурсов при передаче большого числа телефонных сигналов с полосой частот 0,3-3,4 КГц были разработаны различные схемы уплотнения (мультиплексирования) этих сигналов, обеспечивающие их передачу по одному кабелю.

В высокоскоростных сетевых приложениях широкополосная передача означает, что для передачи данных используется не импульсная, а аналоговая несущая. По аналогии термин «широкополосный Интернет» означает, что вы используете канал с пропускной способностью более 128 Кбит/c (в Европе) или 200 Кбит/c (в США). Широкополосная система обладает высокой пропускной способностью, обеспечивает высокоскоростную передачу данных и мультимедийной информации (голос, видео, данные). Примером являются сети АТМ, B-ISDN, Frame Relay, сети кабельного вещания CATV.

Оценка качества коммуникационной сети

Для оценки качества коммуникационной сети можно использовать следующие характеристики:

§ Скорость передачи данных по каналу связи

§ Пропускную способность канала связи

§ Достоверность передачи информации

§ Надёжность канала связи и модемов

Скорость передачи данных по каналу связи измеряется количеством битов информации, передаваемых за единицу времени – секунду.

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

Так, для асинхронных модемов и телефонного канала связи диапазон скоростей составляет 300-9600 бит/с, а для синхронных – 1200-19200 бит/с.

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

Единица измерения пропускной способности канала связи – знак в секунду.

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

Дата добавления: 2018-06-27 ; просмотров: 2575 ; Мы поможем в написании вашей работы!

Источник

Синхронная и асинхронная передача данных: терминология и отличия

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

Сложность современных компьютерных программ связана с длительными процессами, которые происходят «внутри». Бывают такие процессы, обработка которых требует много времени. И если в процессе обработки такого процесса программа будет «стоять», то это чревато снижением продуктивности и вероятным и убыткам и . Для этого и придумано асинхронное программировани е , чтобы улучшить общую эффективность программы путем отмены блокирования основного потока программы.

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

Синхронное представление в быту

У нас есть некая занятая девушка, которая запланировала на вечер познакомить родителей со своим молодым человеком. Чтобы все прошло идеально, ей нужно:

доделать дела на работе;

подготовить вечерний наряд;

сделать прическу, маникюр и накрасит ь ся;

попросить маму накрыть на стол.

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

Девушка берет телефон в руки и начинает звонить. Набрала маму и попросила на вечер накрыть стол. Мама принялась готовить. Девушка з аказала красивое вечернее платье и согласовала адрес его доставки. Съездила сделала себе маникюр и прическу. Наступил вечер, знакомство не состоялось. Почему? Девушка была так занята подготовкой, что не успела доделать дела на работе, потому что целый день провела с телефоном , отдавая команды и ожидая подтверждения, что все готово.

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

Асинхронная передача данных в программировании

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

Асинхронная передача данных — это когда долго выполняемую функцию убирают из основного потока выполнения программы. Она не завершается, а продолжает работать в каком-нибудь другом месте. А сама программа не «зависает» и не «тормозит», а продолжает свое выполнение.

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

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

Терминология асинхронности

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

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

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

Многопоточность. Данный термин обозначает наличие нескольких потоков выполнения программы.

Асинхронность. Данный термин означает, что начало и конец одной функции мо гут происходить в разных частях кода. Чтобы такая функция завершилась , должно пройти немного времени, но сколько точно — сказать невозможно.

Заключение

Синхронная и асинхронная передача данных может осуществляться во многих сферах. Мы показали на примере программирования, как работают синхронные и асинхронные события. У обоих подходов есть свои достоинства и недостатки, поэтому использовать их в своих программах нужно обдуманно.

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Асинхронный способ передачи данных

Связанные понятия

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

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

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

Не следует путать с Компонентным видеоКомпози́тное ви́део — полный цветной аналоговый видеосигнал в исходной полосе видеочастот, передаваемый без звукового сопровождения по одному каналу (кабелю). По ГОСТ 21879—88 понятию англ. Composite Video Signal соответствует полный видеосигнал, содержащий сигнал синхронизации. В аналоговом цветном телевидении стандартной чёткости композитным видеосигналом называют полный цветной телевизионный сигнал (ПЦТС) стандартов PAL, SECAM или NTSC.

Источник

Асинхронное взаимодействие. Брокеры сообщений. Apache Kafka

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

Привет! Меня зовут Дмитрий Шеламов и я работаю в Vivid.Money на должности backend-разработчика в отделе Customer Care. Наша компания – европейский стартап, который создает и развивает сервис интернет-банкинга для стран Европы. Это амбициозная задача, а значит и ее техническая реализация требует продуманной инфраструктуры, способной выдерживать высокие нагрузки и масштабироваться согласно требованиям бизнеса.

В основе проекта лежит микросервисная архитектура, которая включает в себя десятки сервисов на разных языках. В их числе Scala, Java, Kotlin, Python и Go. На последнем я пишу код, поэтому практические примеры, приведенные в этой серии статей, будут задействовать по большей части Go (и немного docker-compose).

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

Асинхронное взаимодействие

Итак, представим что у нас есть два микросервиса (А и Б). Будем считать, что коммуникация между ними осуществляется через API и они ничего не знают о внутренней реализации друг друга, как и предписывает микросервисный подход. Формат передаваемых между ними данных заранее оговорен.

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

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

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

Все, что остается А при такой модели взаимодействия – это просто ждать. Может быть наносекунду, а может быть час. И эта цифра вполне реальна в том случае, если Б в процессе обработки данных выполняет какие-либо тяжеловесные операции, вроде обработки видео.

Возможно, вам проблема не показалась существенной – одна железка ждет пока другая ответит, велика ли потеря?
Чтобы сделать эту проблему более личной, представим, что сервис А – это приложение, запущенное на вашем телефоне, и пока оно ожидает ответ от Б, вы видите на экране анимацию загрузки. Вы не можете продолжить пользоваться приложением до тех пор, пока сервис Б не ответит, и вынуждены ждать. Неизвестное количество времени. При том, что ваше время гораздо ценнее, чем время работы куска кода.

Подобные шероховатости решаются следующим образом – вы разделяете участников взаимодействия на два “лагеря”: одни не могут работать быстрее, как бы вы их ни оптимизировали (обработка видео), а другие не могут ждать дольше определенного времени (интерфейс приложения на вашем телефоне).
Затем вы заменяете cинхронное взаимодействие между ними (когда одна часть вынуждена ждать другую, чтобы удостовериться, что данные были доставлены и обработаны сервисом-получателем) на асинхронное, то есть модель работы по принципу отправил и забыл – в этом случае сервис А продолжит свою работу, не дожидаясь ответа от Б.

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

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

• Данные, которые теряются при аварийном завершении сервиса-получателя теперь могут быть снова получены из промежуточного хранилища, в то время как сервис-отправитель продолжает выполнять свою работу. Таким образом мы получаем механизм гарантии доставки;
• Эта прослойка также защищает получателей от скачков нагрузки, ведь получателю выдаются данные по мере их обработки, а не по мере их поступления;
• Запросы на выполнение тяжеловесных операций (таких как рендеринг видео) теперь могут быть переданы через эту прослойку, обеспечивая меньшую связность между быстрыми и медленными частями приложения.

Под вышеобозначенные требования вполне подходит и обычная СУБД. Данные в ней можно хранить в течении продолжительного времени, не беспокоясь о потере информации. Также исключена и перегрузка получателей, ведь они вольны сами выбрать темп и объемы чтения предназначенных для них записей. Подтверждение же обработки можно реализовать, помечая прочитанные записи в соответствующих таблицах.

Однако выбор СУБД в качестве инструмента для обмена данными может привести к проблемам с производительностью с ростом нагрузки. Причина в том, что большинство баз данных не предназначены для такого сценария использования. Также во многих СУБД отсутствует возможность разделения подключенных клиентов на получателей и отправителей (Pub/Sub) – в этом случае, логика доставки данных должна быть реализована на клиентской стороне.
Вероятно, нам нужно нечто более узкоспециализированное, чем база данных.

Брокеры сообщений

Брокер сообщений (очередь сообщений) – это отдельный сервис, который отвечает за хранение и доставку данных от сервисов-отправителей к сервисам-получателям с помощью модели Pub/Sub.
Эта модель предполагает, что асинхронное взаимодействие осуществляется согласно следующей логике двух ролей:

• Publishers публикуют новую информацию в виде сгруппированных по некоторому атрибуту сообщений;
• Subscribers подписываются на потоки сообщений с определенными атрибутами и обрабатывают их.

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

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

В общем случае, тело представляет из себя набор байт определенного формата.
Получатель обязательно должен знать этот формат, чтобы после получения сообщения иметь возможность десериализовать его тело для дальнейшей обработки.
Использовать можно любой удобный формат, однако, важно помнить об обратной совместимости, которую поддерживают, например, бинарный Protobuf и фреймворк Apache Avro.

По такому принципу работает большинство брокеров сообщений, построенных на AMQP (Advanced Message Queuing Protocol) – протоколе, который описывает стандарт отказоустойчивого обмена сообщениями посредством очередей.
Данный подход обеспечивает нам несколько важных преимуществ:

• Слабая связанность. Она достигается за счет асинхронной передачи сообщений: то есть, отправитель скидывает данные и продолжает работать, не дожидаясь ответа от получателя, а получатель вычитывает и обрабатывает сообщения, когда удобно ему, а не когда они были отправлены. В данном случае очередь можно сравнить с почтовым ящиком, в который почтальон кладет ваши письма, а вы их забираете, когда удобно вам.
• Масштабируемость. Если сообщения появляются в очереди быстрее, чем консьюмер успевает их обрабатывать (речь идет не о пиковых нагрузках, а о стабильном разрыве между скоростью записи и обработки), мы можем запустить несколько экземпляров приложения-консьюмера и подписать их на одну очередь.
  Этот подход называется горизонтальным масштабированием, а экземпляры одного сервиса принято называть репликами. Реплики сервиса-консьюмера будут читать сообщения из одной очереди и обрабатывать их независимо друг от друга.
• Эластичность. Наличие между приложениями такой прослойки, как очередь, помогает справляться с пиковыми нагрузками: в этом случае очередь будет выступать буфером, в котором сообщения будут копиться и по мере возможности считываться консьюмером, вместо того, чтобы ронять приложение-получатель, отправляя данные ему напрямую.
• Гарантии доставки. Большинство брокеров предоставляют гарантии “at least once” и “at most once”.

At most once исключает повторную обработку сообщений, однако допускает их потерю. В этом случае брокер будет доставлять сообщения получателям по принципу “отправил и забыл”. Если получатель не смог по какой-то причине обработать сообщение с первой попытки, брокер не будет осуществлять переотправку.

At least once, напротив, гарантирует получение сообщения получателем, однако при этом есть вероятность повторной обработки одних и тех же сообщений.

Зачастую эта гарантия достигается с помощью механизма Ack/Nack (acknowledgement/negative acknowledgement), который предписывает совершать переотправку сообщения, если получатель по какой-то причине не смог его обработать.
Таким образом, для каждого отправленного брокером (но еще не обработанного) сообщения существует три итоговых состояния — получатель вернул Ack (успешная обработка), вернул Nack (неуспешная обработка) или разорвал соединение. Последние два сценария приводят в переотправке сообщения и повторной обработке.

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

Стоит отметить, что существует еще одна гарантия доставки, которая называется “exactly once”. Ее трудно достичь в распределенных системах, но при этом она же является наиболее желаемой.

В этом плане, Apache Kafka, о которой мы будем говорить далее, выгодно выделяется на фоне многих доступных на рынке решений. Начиная с версии 0.11, Kafka предоставляет гарантию доставки exactly once в пределах кластера и транзакций, в то время как AMQP-брокеры таких гарантий предоставить не могут. Транзакции в Кафке – тема для отдельной публикации, сегодня же мы начнем со знакомства с Apache Kafka.

Apache Kafka

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

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

За выбор брокера-контроллера, в свою очередь, отвечает отдельный сервис – ZooKeeper, который также осуществляет service discovery брокеров, хранит конфигурации и принимает участие в распределении новых читателей по брокерам и в большинстве случаев хранит информацию о последнем прочитанном сообщении для каждого из читателей. Это важный момент, изучение которого требует опуститься на уровень ниже и рассмотреть, как отдельный брокер устроен внутри.

Commit log

Структура данных, лежащая в основе Kafka, называется commit log или журнал фиксации изменений.

Новые элементы, добавляемые в commit log, помещаются строго в конец, и их порядок после этого не меняется, благодаря чему в каждом отдельном журнале элементы всегда расположены в порядке их добавления.

Свойство упорядоченности журнала фиксаций позволяет использовать его, например, для репликации по принципу eventual consistency между репликами БД: в них хранят журнал изменений, производимых над данными в мастер-ноде, последовательное применение которых на слейв-нодах позволяет привести данные в них к согласованному с мастером виду.
В Кафке эти журналы называются партициями, а данные, хранимые в них, называются сообщениями.

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

Партиции и топики

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

Так вот в Кафке функцию очереди выполняет не партиция, а topic. Он нужен для объединения нескольких партиций в общий поток. Сами же партиции, как мы сказали ранее, хранят сообщения в упорядоченном виде согласно структуре данных commit log. Таким образом, сообщение, относящееся к одному топику, может хранится в двух разных партициях, из которых читатели могут вытаскивать их по запросу.

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

Pull и Push

Обратите внимание, что я не случайно использовал слово “вытаскивает” по отношению к читателю.
В описанных ранее брокерах доставка сообщений осуществляется путем их проталкивания (push) получателям через условную трубу в виде очереди.
В Кафке процесса доставки как такового нет: каждый читатель сам ответственен за вытягивание (pull) сообщений из партиций, которые он читает.

Производители, формируя сообщения, прикрепляют к нему ключ и номер партиции. Номер партиции может быть выбран рандомно (round-robin), если у сообщения отсутствует ключ.

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

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

Какие преимущества имеет данный подход?

Недостатки

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

В Кафке по умолчанию вычитывание сообщений из партиции останавливается, когда получатель доходит до битого сообщения, и до тех пор, пока оно не будет пропущено и закинуто в “карантинную” очередь (также именуемой “dead letter queue”) для последующей обработки, чтение партиции продолжить не получится.

Также в Кафке сложнее (в сравнении с AMQP-брокерами) реализовать приоритет сообщений. Это напрямую вытекает из того факта, что сообщения в партициях хранятся и читаются строго в порядке их добавления. Один из способов обойти данное ограничение в Кафке – создать нескольких топиков под сообщения с разным приоритетом (отличаться топики будут только названием), например, events_low, events_medium, events_high, а затем реализовать логику приоритетного чтения перечисленных топиков на стороне приложения-консьюмера.

Еще один недостаток данного подхода связан тем, что необходимо вести учет последнего прочитанного сообщения в партиции каждым из читателей. В силу простоты структуры партиций, эта информация представлена в виде целочисленного значения, именуемого offset (смещение). Оффсет позволяет определить, какое сообщение в данный момент читает каждый из читателей. Ближайшая аналогия оффсета — это индекс элемента в массиве, а процесс чтения похож на проход по массиву в цикле с использованием итератора в качестве индекса элемента.

Однако этот недостаток нивелируется за счет того, что Kafka, начиная с версии 0.9, хранит оффсеты по каждому пользователю в специальном топике __consumer_offsets (до версии 0.9 оффсеты хранились в ZooKeeper).
К тому же, вести учет оффсетов можно непосредственно на стороне получателей.

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

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

Consumer Group

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

Так как читатели привязываются непосредственно к партиции (при этом читатель обычно ничего не знает о количестве партиций в топике), ZooKeeper при подключении нового читателя производит перераспределение участников в Consumer Group таким образом, чтобы каждая партиция имела одного и только одного читателя.
Читатель обозначает свою Consumer Group при подключении к Kafka.

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

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

Чтобы решить эту проблему, мы можем пойти от обратного: если все события, относящиеся к одной сущности (например, все действия относящиеся к одному user_id), будут всегда добавляться в одну и ту же партицию, они будут упорядочены в рамках топика просто потому, что находятся в одной партиции, порядок внутри которой гарантирован Кафкой.
Для этого нам и нужен ключ у сообщений: например, если мы будем использовать для выбора партиции, в которую будет добавлено сообщение, алгоритм, вычисляющий хэш от ключа, то сообщения с одинаковым ключом будут гарантированно попадать в одну партицию, а значит и вытаскивать получатель сообщения с одинаковым ключом в порядке их добавления в топик.
В кейсе с потоком событий о действиях пользователей ключом партицирования может выступать user_id.

Retention Policy

Теперь пришло время поговорить о Retention Policy.
Это настройка, которая отвечает за удаление сообщений с диска при превышении пороговых значений даты добавления (Time Based Retention Policy) или занимаемого на диске пространства (Size Based Retention Policy).

• Если вы настроите TBRP на 7 суток, то все сообщения старше 7 суток будут помечаться для последующего удаления. Иными словами, эта настройка гарантирует, что в каждый момент времени будут доступны для чтения сообщения младше порогового “возраста”. Можно задавать в часах, минутах и милисекундах.
• SBRP работает аналогичным образом: при превышении порога занимаемого дискового пространства, сообщения будут помечаться для удаления с конца (более старые). Нужно иметь в виду: так как удаление сообщений происходит не мгновенно, занимаемый объем диска всегда будет чуть больше указанного в настройке. Задается в байтах.

Retention Policy можно настроить как для всего кластера, так и для отдельных топиков: например, сообщения в топике для отслеживания действий пользователей можно хранить несколько дней, в то время как пуши – в течении нескольких часов. Удаляя данные согласно их актуальности, мы экономим место не диске, что может быть важно при выборе SSD в качестве основного дискового хранилища.

Compaction Policy

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

Источник