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

1: Ирина Ананьева, давайте начинать всем ещё раз привет. И сегодня у нас ещё 1 классная супер востребованная тема про брокеры сообщений, а именно мы будем

2: Обсуждать rabbit mq и сравнивать его с kafka тему мы выбрали и подготовили вместе с яной Паршиной, которая уже участвовала в записи других эпизодов подкаста гетена ист, такие как 13 ошибок в бпмн диаграмм.

3: Вообще, в принципе, топ диаграмм, а даже не топ. Мне кажется, мы обсудили тогда все диаграммы, которые важно знать системным и бизнес аналитикам, а также домейн дривен дизайн. Вообще брокеры. Это сейчас такой любопытный вопрос, которым интересуются

4: Системные аналитики, потому что развивается распределённая архитектура, сервисы, микросервисы, да, и в целом оптимизация работы систем. Не все можно реализовать без них. И я скажу то, что даже там мои самые, самые

5: Самые первые проекты, они уже тогда имели не кафку, а именно рэббита для определённых задач. Сегодня 1 из таких обсудим прям моя любимая, скажем так, поэтому мы сегодня и будем погружаться в изучение в rabbitmq к сегодняшнему.

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

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

8: Сегодня мне поможет разбираться в этой теме Яна Паршина, менеджер системных аналитиков в компании икс 5 тех продукт онёр команды персонализации, ментор, автор статей, ведущая тренингов и воркшопов Яна, передаю тебе слово всем.

9: Привет. Привет. Да, спасибо большое. На самом деле чуть чуть совсем добавлю про востребованность этой темы. На мой взгляд, она 1 из топовых на собеседованиях. Я лично обожаю спрашивать у кандидата, в чем отличие между

10: Этими 2 популярными брокерами также прошу зачастую объяснить, а почему на проекте или на продукте выбран, например, именно рэббит, а не kafka, так что надеюсь, что сегодня мы ответим и на эти вопросы тоже прекрасно, что

11: Ты это подсветила, так что это очередной выпуск, который поможет освежить память, добавить знаний и подготовиться к собеседованию. Тогда предлагаю начинать, и давай начнём с того, что расскажем нашим зрителям.

12: А что же такое ребит инкью, когда он используется и сравним его с кафкой? Ну и в целом про кафку тоже, наверное, стоит освежить. Хотя предыдущий эпизод 1 из недавних у нас как раз-таки тоже был про coffe.

13: Стоит на него посмотреть да, сегодня сделаем акцент именно на реббите и будем сравнивать его с кафкой, чуть чуть затронем, но тут скорее действительно отсылаю подробно послушать, что такое кафка в другом эпизоде кафка.

14: И rabbit что это такое? Это системы очередей сообщений, которые мы можем использовать при какой-то потоковой обработке данных, но важно понимать, что rabbit это брокер для распределённых сообщений.

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

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

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

18: Это те, кто получают данные с тем или иным брокером, с реббитом или с кафкой. Давайте разберёмся, кто такие консьюмеры и потребители и кто такие производители, производители данных в данном случае.

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

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

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

22: Данных и нашего брокера посмотрим с другой стороны между брокером и нашим потребителем в rabbitmq производитель отправляет сообщение и отслеживает, дошло ли оно до потребителя, в то время как сам

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

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

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

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

27: Выбирает книжку, выбирает сообщение, которое ему нравится, и запоминает его а rabbit, он как почта мы пришли в почтовое отделение, сказали, что отправить кому отправить рэббит сам.

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

29: Это письмо. Спасибо большое. И больше никак ребит не является ответственным за это письмо. Может спокойно, например, удалить эти данные из себя. Очень классный пример с библиотекой.

30: И с почтой мне уже казалось, что сейчас будет пример про очень медленную почту, либо почта, которая все теряет, и сообщения в куче. Прям вот ждала что-нибудь такое. Но нет, здесь, ян, я хочу

31: Уже подсветить, что это разные модели у нас есть pull and push модель, по которой у нас что происходит с брокером кафка на кафку, подписаны потребители и как только они готовы.

32: Они забирают сообщения в обработку, то есть они, по сути, входят в kafka как во временную базу данных и kafka, она просто место хранения сообщений, в то время как у rabbit у него

33: Пуш модель, когда он сам отвечает за то, что нужно доставить сообщение, и он сам, получается, так можно сказать, дёргает микросервис какую-то службу, команду для того, чтобы её

34: Так скажем, запустить, верно ли, объяснила, да, все так. И тут ещё важный нюанс, что rabbit, после того, как сообщение дошло до потребителя, удаляет, как правило, да, там.

35: Можно настроить по разному, но, как правило, удаляет те данные, которые уже дошли до потребителя. То есть он не хранит их в себе долго, к ним нельзя обратиться по несколько раз. А в кафке можно, да?

36: Это так. Но здесь тоже ещё хочу обратить внимание на то, что у нас в kafka есть возможность настроить хранение сообщений до бесконечности хоть как в реальной базе данных, но ps. Лучше так.

37: Не делать и есть возможность опять же, настроить плюс минус так же как в репите в целом. Плюс минус они могут быть взаимозаменяемые под одни и те же задачи, да, то есть мы там Зада,

38: Например, доставки уведомлений. Я думаю, что мы точно сегодня её будем обсуждать. Мы её можем решить как с кафкой, так и с реббитом. Но именно механизмы как продюсер, да, то есть производитель публикует сообщения, кон,

39: Юмер потребитель его забирает, они будут разные. И получается у нас есть вот эта разница в пул пуш модели, как доставляются сообщения, как они перегоняются между производителями и потребителями.

40: Или же вот паблишерами и сабскрайберами предлагаю погружаться дальше и что же у нас внутри рэббита? Да, давай обсудим, а из чего, собственно, у нас состоит rabbitmq? Мы поговорили, что у нас с 2

41: 2 Концов. Условно нашего процесса есть продюсер и консьюмер сервисы, которые у нас отправляют и принимают сообщения, но важно понимать, что в процессе обработки и как раз маршрутизации у нас вступают внутрь.

42: Ключевые компоненты нашего брокера rabbitmq что это за компоненты? 1 это exchange он принимает сообщения от продюсера и направляет их в очередь согласно определённым правилам.

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

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

45: Вторые посылки должны поехать в очередь на доставку, не знаю, в соединённых штатах и третьи, по, не знаю, по России это разные очереди. И как раз наш эксчендж определяет, какую посылку в

46: Очередь поместить а вот как он определяет это биндинг, это правила, по которым сообщения из exchange поступают в определённые очереди какие есть правила, мы сегодня тоже ещё обсудим, но чуть чуть попозже.

47: Если мы будем говорить про жизненный путь сообщения, то он будет выглядеть примерно следующим образом. Сначала продюсер отправляет сообщение в брокер сообщение, попадает в

48: Где брокер проверяет правила нашей биндинг, по которым нужно распределить данное сообщение в ту или иную очередь и дальше, в зависимости от правила, помещает это сообщение в очередь и

49: Подписчик уже получит нужные ему сообщение из нужной очереди, в чем преимущество на самом деле это помогает довольно гибко контролировать правила обмена сообщениями и использовать 1 ребит для взаимодействия.

50: Между большим довольно количеством консьюмеров и продюсеров и настроить вот эту внутреннюю логику прям внутри самого рэбита. Но если мы будем говорить про rabbit чуть шире, чем просто про

51: То, как он работает с сообщениями, поговорим о нём как о брокере, то rabbitmq, он на самом деле довольно прост в настройке, и именно поэтому довольно часто в продуктах, которые в том числе.

52: Если только только начинают что-то делать, отдают предпочтение рэббиту, а не кафке, потому что настроить или там приготовить рэббит несколько проще у него есть доступный исходный код в открытом доступе.

53: Большое комьюнити, поэтому да, с реббитом на начальных этапах может быть попроще гибкость это мы уже сегодня тоже отметили, но есть и недостатки. Важно понимать, что у rabbit на самом деле неболь.

54: Большая пропускная способность, там порядка 40000 сообщений в секунду, что для очень высоконагруженных систем бывает недостаточно понятно, что rabbit тоже можно масштабировать, но это отде.

55: Задача и есть как раз ограничения в этих самых возможностях для масштабирования это может быть непросто. И поэтому, когда речь заходит о больших потоках данных,

56: Почтение отдают кафки, и мы сегодня ещё и поговорим, какие как раз задачи лучше решает кафка, а какие ребит со всеми пунктами по плюсам и минусам. Согласна. Единственное, что здесь, наверное, это наличие

57: То, что опенсорсный исходный код у rabbit абсолютно такая же история, открытая документация, открытое решение и у apache kafka, так что это преимущество.

58: Можно сказать, что есть у обоих брокеров и выделять бы его уже как отдельное. Я не стала, по крайней мере, в сравнении. Ещё 1 момент. Давай попробуем пояснить нашим коллегам, вот чем отличается.

59: Очередь в реббите от топика в kafka. То есть как-то вот знаешь, на самом деле такой вопрос с подвохом, как мне кажется, есть ещё вопрос в чем раз.

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

61: То есть, по факту такой, ну, мини база данных, да, можно сказать, что место хранения сообщений временное, а брокер это система, которая позволяет управлять

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

63: Вопрос на шаг назад я ответила давай тебе задам вопрос на шаг вперёд в чем отличие между топиками в kafka и очередями в рэббите? Очередь, которая используется в рэббите, это структура, да.

64: По типу фифо 1 пришёл, 1 ушёл сообщение, оно помещается в очередь и обрабатывается 1 из подписчиков после обработки. Сообщение, как правило, удаляется, если мы говорим

65: Про кафку и про топики, то топик это канал или там поток, в который публикуются события. И это важно, что там именно события и каждый подписчик он получает.

66: По сути, копию сообщения и использует дальше это сообщение для какой-то логики. Например, если мы говорим про rabbitmq, представим, что у нас есть интернет-магазин и

67: Туда в очередь заказов приходит сообщение, что создан заказ, и 1 из сервисов, например, обработчик заказов, забирает это сообщение, удаляет его из очереди в реббите.

68: И начинает собирать заказ. Например, отправляет его как раз в центр сборки заказов. И там начинается свой процесс. Другие потребители не участвуют дальше в этом.

69: Процессе, они никак с именно этим сообщением не работают. А вот если мы представим, что у нас есть интернет-магазин и есть какие-то события, например, получили платёж за

70: Тоже заказ, как могли бы отреагировать другие сервисы? Они подписаны на это событие, что платёж по заказу получен. Каждый начинает производить, не знаю, свои действия, например, микро.

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

72: И отправить в систему управления складом. Например, приходит информация, основанная на этом же событии, что нужно изменить количество товаров в соответствии с заказом. Например, какие-то товары у нас теперь будут раскупленными, их больше.

73: Не осталось. Система лояльности будет начислять баллы, потому что платёж прошёл. Нужно начислить, не знаю, 10 каких-нибудь баллов лояльности, которыми пользователь потом может воспользоваться. То есть каждый обработал.

74: Это событие по своему запустил свои процессы, и таких подписчиков на топик может быть много в реббите не так. У нас 1 потребитель конкретного сообщения запускает свой процесс и здесь

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

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

77: Kafka их может быть много, стоит ещё, наверное, подсветить, что из реббита мы, получается, читаем сообщения разово, а точнее, не читаем рэббит доставляет сообщения до потребителя разово, то есть, получается такая, знаешь, история про

78: Человек пришёл в очередь в магазин, он прошёл через кассу, и все. Он прошёл через кассу. Его процесс работы с магазином завершён. Если нужно, так скажем, этого человека.

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

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

81: В случае с kafka какая у нас история? Ну, пришёл человек в магазин, и одновременно нужно, чтобы его, получается, и кассир обслужил, да, то есть вот такая вот история, кассир даже получается, не сам rabbit.

82: Кассир это какой-то микросервис, который может обрабатывать вот этого человека. В kafka тоже самое, то есть его такой же кассир может обслуживать, но параллельно в случае с kafka, вместе с тем, что

83: Нашего покупателя обслуживает кассир, к нему может прийти оперная труппа, станцевать перед ним балет, параллельно к нему может подойти какой-нибудь комик и рассказать какой-нибудь смешной анекдот, ещё параллель.

84: Вместе с этим то, что вот пользователь подошёл на кассу, что может произойти. Подошёл сборщик продуктов в пакет. Во у нас есть такая тема и начал параллельно собирать его продукты в пакет, то есть на событие клиент

85: Подошёл на кассу, то есть подошла очередь клиента, у нас получается у rabbit, разовая реакция, тупо кассир тупо обслужил и тупо отпустил 1 микросервис может его забрать и обработать.

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

87: И там его смогут обслужить, все-таки пробить его покупки. То, что он хотел. Короче, суть в том, что у нас несколько микросервисов независимо друг от друга могут среагировать. По сути, да, это именно такой вот подход, скажем,

88: Так, в обработке сообщений. И вот все равно мы сводим все к тому, что топик и очередь плюс минус, как бы они, по сути, про очередь просто очередь в реббите уже в деся.

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

90: Подписчиков сабскрайберов или же потребителей. И кстати, кстати, про хранение здесь ну опять же, мы уже погружаемся дальше в сами технологии и то, что мы уже обсуждали время хранения, сообще

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

92: Журналы событий и на эти события реагируют уже остальные микросервисы. Надеюсь, 20 раз 1 и тоже не повторила. Я предлагаю чуть чуть поговорить все-таки ещё и про

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

94: Rabbit, он гарантирует получение сообщения потребителями, то есть потребитель, он играет такую пассивную роль, он сидит и ждёт, пока рэббит отправит ему сообщение в очередь пример банковская.

95: Приложение, которое может ждать СМС сообщения о том, что транзакция обработана кафка чуть иначе, там потребитель он, ну, не потребитель, он подписи.

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

97: Работает с этой информацией про приоритет сообщений в реббите. Мы можем обеспечить отправку сообщений в порядке. 1 пришёл, 1 ушёл и обработать при этом сообщения с более высоким

98: То есть там есть возможность настраивать вот эту приоритизацию и сказать, что какие-то сообщения там важнее, чем другие. Например, если там у нас есть какое-нибудь приложение магазин, он может

99: Ставить транзакции выше, чем, не знаю, там какие-то системные сообщения, потом обработаем системное, самое главное, там вот как раз банковские транзакции обеспечить, чтобы заказ начали собирать в-ка.

100: Там нет приоритизации очереди, там вот как пришло, так и уйдёт событие при распределении. Соответственно, все сообщения, они рассматриваются как абсолютно равные удаление сообщений. Бо.

101: Rabbit, он маршрутизирует сообщения в очередь назначения. То есть вот у нас есть потребитель и после прочтения потребитель должен отправить брокеру ответ о том, что он получил это сообщение и

102: Rabbit, он потом удалит из очереди эту информацию в kafka, там, иначе там добавляется сообщение в файл журнал, он может храниться довольно долго, как Говор.

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

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

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

106: В кафке довольно высокая пропускная способность, и кафка способна обрабатывать миллионы сообщений в секунду, реббит он чуть чуть менее способный, и там можно обрабатывать 1000 сообщений.

107: Секунду все зависит от того как вы настроите реббит, но да, порядок цифр все-таки разный. Маршрутизация следующий важный критерий в kafka маршрутизация супер простая, она основана на.

108: Топиках и партициях сообщение пришло 1, 1 оно и уйдёт в реббите гибкая система с различными стратегиями обмена как раз сообщений их приоритетов, их маршрутизации.

109: Очереди и так далее. Это все можно настраивать способ обработки, он тоже отличается в kafka. Мы читаем сообщения из журналов, можем их читать несколько раз, обрабатывать тоже многократно в

110: Ребите, мы 1 раз прочитали, отдали ответ, что мы прочитали, и на этом ребит удалит сообщение. Не будет засорять больше очередь этой информацией, поэтому чаще всего кафку на самом деле используют

111: Для высоконагруженных систем, например, для аналитики данных. То есть у нас есть какие-то пользователи в том же интернет магазине, они, не знаю, там посмотрели карточки товаров пощёлкали, понадоб.

112: Их в корзину совершили сколько-то заказов. Вся аналитика событий может прогрузиться в кафку, потом разные системы, которые у нас работают с аналитикой. Каждый там по отдельности сходил, собрал нужные для

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

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

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

116: Ооо хранение сообщений kafka у нас как такая бесконечная база данных может выступать но не надо, это все-таки про временное хранение сообщений, rabbit в то же время не так гибко масштабируется, здесь можно докидывать эксченджи.

117: Также используют прекрасную возможность. Всегда можно докинуть ресурсов. Здесь, ян, возможно, ты сможешь добавить по поводу масштабирования рэббита. На что стоит обратить внимание. Ты правильно заметила, что часто

118: Используют именно так называемое горизонтальное масштабирование, когда просто подкидывают ресурсов. Но если мы говорим про масштабирование, за счёт оптимизации процессов внутри, то помогает чаще всего 2 вещи. 1, это действительно работа.

119: С эксченджами, например, мы создаём какой-то самый 1 эксчейндж, там препроцессинг наших сообщений. А дальше уже этот exchange препроцессинга определяет, что нам нужно какие-то сообщения.

120: Отправить в exchange, который будет работать с уведомлениями, какие-то сообщения отправить там в эксчейндж, который будет работать, не знаю, там, с сообщениями доставки и так далее. Ну, опять же, если мы пытаемся развивать

121: Наш пример с интернет магазином. И 2 момент это работа как раз с очередями. То есть мы именно очереди тоже можем, с 1 стороны, подробить, а с другой стороны объединить в какие-то общие

122: То есть, например, вспоминая наш эксчендж по уведомлениям, там может быть отдельная очередь на смски, отдельная очередь на, не знаю, емейл сообщения и 3 очередь на пуши, и у каждого будет свой воркер, и за

123: Этого мы оптимизируем нагрузку, которая у нас есть на rabbit. Предлагаю двигаться дальше. Ян, давай разберём примеры, когда у нас вообще в целом встречается rabbitmq.

124: На проектах. А давай 1 мой пример про смски с кодом подтверждения банковских транзакций. То есть те самые, которые нам важно получить, и банк не начнёт ничего делать, пока он

125: И получит то, что код введён из СМС, правильно? И нам тут, напомню, важно, что есть определённая транзакционность. То есть мы как какой-то банковский сервис не можем начать проверять.

126: Транзакцию до того, как, не знаю, была выслана смска. Например, мы не можем, не знаю, дать сначала денег, а потом подтвердить, что это там тот самый человек запросил у нас, не знаю, перевод.

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

128: Есть, собственно, чёткая последовательность действий, которые должны вызываться до и после. Если попытаться представить это на примере, давайте возьмём все тот же интернет-магазин, который у нас мог быть написан на монолите.

129: Как mvp версия, почему нет, но мы решили его распилить, поэтому вынесли всю часть, которая связана с отправкой уведомлений, и часть, которая связана со складом в отдельный микро.

130: Сервисы. И у нас получилось, что у нас есть монолитная система, где сам пользователь ходит, что-то добавляет в корзину, удаляет из корзины. Не знаю, добавляет в избранное, совершает заказ. Это в

131: Монолите осталось и часть микросервисов, которые могут существовать отдельно, не мешая друг другу, подключаются только тогда, когда им пришло определённое сообщение от rabbit, и таким образом, мы

132: Можем постепенно распиливать сложную систему интернет магазина с большим количеством процессов внутри на небольшие итерации. Спасибо за пример, ян. И у меня к тебе вопрос. Кажется, я

133: Его тебе или кому-то задавала в каком-то из эпизодов скажи, пожалуйста, а могут ли быть kafka и rabbit вместе на 1 проекте вполне, и у меня на проекте на самом деле так и есть?

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

135: И как раз рассылку, например, пушей нашим пользователям мы делаем через rabbit, почему нам это важно, потому что давайте представим, что у вас есть интернет-магазин. Вы очень хотите прокоммуницировать со своими клиентами.

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

137: Котором мы будем проверять, что пользователю мы не отправляли сообщений слишком много, и класть пуши там и сообщения в очередь только тогда, когда мы выполнили вот эту проверку. Обес.

138: Транзакцию. И после этого уже будет только рассылка. Кафку используем тогда, когда нам нужно собрать аналитику. А сколько пушей открыли? А перешли ли потом куда-то из этого пуша там посылки

139: Которую мы вставили. А прошли ли, может быть, опрос из этого пуш сообщения, как им наш заказ? Все ли понравилось. То есть, да, мы используем и rabbit, и кафку на 1 продукте, но для разных целей, беря лучшее от

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

141: Технологии рэббита не подошли для того, чтобы собирать огромные просто потоки событий, которые приходят с разных микросервисов и затем их собирать и агрегировать в 1 сервисе мониторинга, строить аналитики. Отче.

142: Да, и другие тоже сервисы. Вот как раз-таки 1 сервис мониторинга, 2 сервис аналитики. Всем нужно это событие. Короче, они вот столкнулись с такой проблемой, когда нужен именно поток событий, а не порядок и транзакционность. И именно они

143: Можно так сказать, изобрели кафка, то есть для того, чтобы с логами, с событиями, с аналитикой работать. Прекрасный пример. И также я просила в эпизоде подкаста 23 на этот вопрос ответить.

144: Наших зрителей есть тоже отклик о том, что на проекте используется и кролик rabbit mq наш и kafka вместе и для общения между микросервисами выбран как раз-таки rabbit mq.

145: А кафка используется для общения между системами, чтобы это не значило и в общем то по большей части как в подкасте номер 23 рекомендую его послушать, если вы ещё не погружались в kafka я.

146: Я предлагаю двигаться дальше, ян, можешь, пожалуйста, подсказать, как у нас может быть устроена постановка задачи на разработчиков, если мы работаем с реббитом, что важно учитывать в

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

148: Тизировать. Отчасти те знания, которые мы уже проговорили и начнём с того, что опять же в реббите есть ключевые компоненты эксчейндж кью и massage, и к каждому из этих компонентов нам как

149: Системным аналитикам надо прописать свои требования. Давай начнём с эксченджа, напомню, что эксчендж это та самая точка обмена. Все сообщения у нас должны попасть именно в exchange и прежде чем

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

151: Публиковаться наши сообщения и имя должно быть уникальным. 2, это дюрабл, так называемая временная ли очередь или нет. То есть если нам необходимо создать постоянную точку,

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

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

154: Постоянная очередь. Дальше. Какая у нас точка обмена? Интернал или нет? Такой атрибут? Он может принимать, собственно, 2 значения, да или нет? Внутренние продюсеры у нас данные публикуют или нет? Сле.

155: Следующая настройка это если у нас автоудаление сообщений, эта настройка нам говорит о том, нужно ли удалять точку обмена после того, как завершился процесс использования нашего сообщения для примера.

156: Если мы говорим, что у нас есть отдельный эксчейндж, который работает только на разовые смски, например, и мы понимаем, что это что-то, что можно временно гасить, потом создавать заново, возможно, это непло.

157: Плохой вариант с точки зрения, опять же, нагрузки, оптимизации, нагрузки на rabbit и есть ещё аргументы, но это не обязательные аргументы. Чаще всего их можно не указывать в требованиях, если там

158: Нет иной договорённости с не знаю, с архитектором или с разработчиками, поэтому самое важное для эксченджа указать имя, постоянная ли это очередь, внутренняя ли это точка обмена и есть ли у нас автоудаление.

159: Или нет, движемся дальше очередь, напомню, у нас в реббите работает по принципу фифо first in first out, и при конфигурации очереди мы можем задать как обязательные, так и.

160: Необязательные параметры, и каждая очередь должна иметь уникальное имя и свойства, которые будут определять её поведение. Сперва нам нужно её назвать и, собственно, определить.

161: Эти свойства, чтобы потребитель мог считывать данные из неё. Поэтому в требованиях мы обязательно указываем 1 это имя, оно тоже должно быть уникальным. 255 символов кодировка ютф 8.

162: И имя не может начинаться со слов que, потому что это зарезервированная часть для rabbit. В общем, не надо создавать такие имена, но он вам и не даст, поэтому определяем в требованиях 1, как у нас назы.

163: Называется очередь. И 2. Какими свойствами очередь должна обладать, чтобы мы, как rabbit, поняли, в какую очередь положить то или иное сообщение. И последнее, собственно, само сообщение тут

164: Есть тоже своя структура, у нас есть заголовок, у нас есть пэйлот, где мы можем дополнительно указать какие-то данные. У нас есть header заголовок сообщения, который участвует в построении логики обрабо.

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

166: Характеристика, которая нам позволит обращаться и направлять сообщения в очередь. И этот роутинг кей, он должен быть уникальным. 2, это headers, он содержит информацию для

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

168: Ещё есть пропертис. Это характеристики сообщений, которые мы считаем важными. Как правило, это какой-нибудь тип или кодировка. И последнее это как мы будем доставлять наши сообщения, режим доставки.

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

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

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

172: За такое подробное пояснение. И хотелось бы ещё 1 небольшой вопрос задать по поводу, наверное, самих сообщений. Они в каких форматах могут быть? То есть, да, есть определённая структура, но сам формат сообщений, джейс.

173: Или, может, ещё встречала что-то за пределами этого. Честно тебе скажу, что встречала только ключ значения, вот только джейсоны с другими не сталкивалась на самом деле rabbitmq.

174: Он в целом не завязывается на формат сообщений, по сути, просто передаёт байты, и поэтому мы можем передавать сообщения в любом формате, но да, самое распространённое, с которым я тоже вот только и работала, это json, но, насколько мне известно,

175: Также прекрасно подходит ямал икс эмэли. Это прям вот то, что может быть спокойно использовано для передачи сообщений непосредственно в rabbitmq. Подскажи, пожалуйста, а как

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

177: Kafka он у нас отвечает за то, какие у нас должны быть топики логические, да, то есть за количество партиций, то есть вот в это у нас была часть погружения, за что отвечает системный аналитик в rabbit.

178: Ну да, вот повторяю свой вопрос с точки зрения архитектуры, при постановке задач, при проектировании решения, а за что все-таки ответственность лежит на архитекторах и разработчиках? Начну, наверное, чуть чуть с конца.

179: Архитекторах лежит задача выбрать, что нам лучше подходит ребит кафка или, может быть, какой-то другой брокер, да, аналитик может предложить, но финальное решение, как правило, все-таки за архитектором, когда

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

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

182: От кого они получают информацию, какие у нас есть очереди, по какой логике надо класть те или иные сообщения в те или иные очереди и, собственно, что у нас должны содержать сообщения вот за эти

183: 4. Получается, на самом деле ключевые вещи описывает и отвечает системный аналитик. Ну, по сути, да, тоже вот его внутрянку, это точки вот эти эксченджи, как у нас, я так понимаю, приоритизируется очередь.

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

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

186: Ещё почитать официальную документацию. Как минимум, если хочется погрузиться чуть подробнее, узнать и про, rabbit, и про кафку, она, правда, неплохая, ну и там конечный обновлённый источник знаний, поэтому.

187: Официальной документации прям супер. Советую пользоваться. Ну и что кроме есть неплохая книжка от Роя про реббитом кью, которую тоже советую тем, кто хочет погрузиться и разобраться во всем.

188: И самостоятельно, и эмуляторы реббитом кью, которые можно ещё и на практике потыкать, понастроить, посмотреть, как это работает, в общем, руками попробовать повзаимодействовать с реббитом.

189: Если не было такого опыта да, практика наше все, если можно что-то пощупать на эмуляторе, а с реббитом mq это работает, то лучше это сделать коллеги, ссылочки на материалы мы оставим в описании.

190: К эпизоду нашего подкаста на его странице, и что я ещё рекомендую это разбираться с практикой, читать, изучать внутреннюю структуру и, конечно же, про

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

192: Это такое. Про официальную документацию тоже добавлю, она классная, хорошая, но есть 1 нюанс. Она на английском. Пожалуйста, не стесняйтесь использовать google, транслейт и нейросети для того, чтобы это все аккуратно переводить. И, кстати,

193: Про нейросети, если мы говорим про чат gpt, там есть так называемые gpt эс, в общем, микро, чаты, gpt, и если вы среди них сделаете поиск, введёте rabbitmq, там есть специальный маленький джи.

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

195: На этом мы завершаем наш сегодняшний эпизод, ян, спасибо тебе за классный подготовленный материал. Очень круто, что нам удалось осветить и 2 брокер основной, с которым работают.

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

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

198: На всех площадках яндекс, музыка, YouTube, RuTube, вк. Telegram и другие платформы, на которых вы сегодня слушали наш эпизод пишите обратную связь в комментариях к подкасту предлагайте.

199: Новые идеи для выпусков и не пропускайте запланированные эпизоды с вами сегодня были Яна Паршина, менеджер системных аналитиков компании икс 5 тех и я ведущий подкаста и основатель сообщества.

200: Тёмных аналитиков гетена лист Екатерина Ананьева увидимся в следующем выпуске.