​Message brokers, часть 1: RabbitMQ

Оба брокера реализуют паттерн publish/subscribe. Его основные участники это

🔸 Producer — отправляет сообщения. Сообщение состоит из ключа, значения и хэдеров
🔸 Consumer — принимает сообщения
🔸 Message broker — компонент для обмена сообщениями, разворачивается отдельно

Основная структура данных для распределения сообщений — очередь. Обычно в системе целое море продюсеров, очередей и консьюмеров. Чтобы упростить общение между ними, RabbitMQ использует промежуточный слой — exchangers.

Принцип работы:

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

Консьюмер подсоединяется к интересным очередям и забирает оттуда сообщения.

Чтобы было понятно, как это выглядит, посмотрите на картинку внизу поста👇

Сообщение удаляется из очереди после прочтения. Отсюда идут следующие схемы:

▫️ Если сообщение должны прочитать несколько получателей — у каждого должна быть своя очередь, куда это сообщение попадёт.

Пример: сообщение order.from-A.to-C. vip попадает в две очереди — order.from-A.* и order.*.*.vip

▫️ Если нужно распределить сообщения между получателями, консьюмеры подключаются к одной очереди. RabbitMQ распределяет сообщения между ними равномерно по принципу round-robin.

Пример: сообщение order.from-A.to-B и order.from-A.to-C распределяются между консюмерами С1 и С2

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

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

Главное в RabbitMQ:
✔️ Основной компонент — exchanger и связанные с ним очереди
✔️ Сообщения удаляются после прочтения
✔️ Push-модель
✔️ Гибкий роутинг сообщений

​Message brokers, часть 2: Kafka

Если RabbitMQ — это 100% очередь, то Kafka больше похожа на список, потому что данные после чтения не удаляются. В принципе это основное отличие двух брокеров, остальное — просто следствие.

Один список называется partition. Несколько partition можно объединить в группу, которая называется topic.

Консьюмеры читают данные из партишена или топика. Для каждого консюмера хранится индекс последнего прочитанного сообщения (offset). Когда получатель прочитает сообщение, Kafka сдвинет его offset. И в следующий раз этот получатель прочитает другие сообщения.

Если в partition 10 сообщений, то
🧔🏻 Один консьюмер прочитает сразу всё
👳🏻 Другой прочитает 5 и потом ещё 5
👩🏼‍🦰 Третий будет вычитывать по одному сообщению

И никто никому не мешает☺️

В рамках одного partition все консюмеры читают сообщения в одном порядке. Иногда это очень важная фича. Для топика из нескольких partition такой гарантии нет.

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

🔸 Если сообщение должны прочитать несколько однотипных получателей, достаточно записать их в один partition

🔸 Если получатели разнотипные, то продюсер должен добавить данные в несколько партишенов.
Пример: чтобы сообщение “A to C vip” прочитали C1 и C4, продюсер отправляет запись в топик orders и vip_orders.

🔸 Если нужно распределить сообщения по получателям, то консьюмеры объединяются в consumer group с общим оффсетом

Резюме

▫️ В Kafka сообщения не пропадают при чтении, их можно читать несколько раз и пачками
▫️ Гарантия порядка сообщений в рамках одного partition
▫️ Kafka занимает горааааздо больше места на диске
▫️ Kafka использует pull модель — получатели сами решают, когда забрать сообщения. В RabbitMQ инициатива исходит от очереди, чтобы равномерно распределять сообщения
▫️ Разные схемы общения с продюсерами и консьюмерами. На картинке ниже я представила аналог схемы из предыдущего поста
▫️ Разные сценарии масштабирования и отказоустойчивости
▫️ Субъективное мнение — в рэббите проще распределять сообщения по получателям. Kafka подходит для накопления данных и более сложных сценариев
▫️Объективное — Kafka используется на бОльшем количестве проектов, пусть даже в качестве простой очереди😐

Общие черты двух брокеров:

🐰🐞 Отлично поддерживаются спрингом
🐰🐞 Можно настроить хранение сообщений на диске
🐰🐞 Нужно супер тщательно продумать схему работы и масштабирование

PS Эти посты — самые основы месседж брокеров, прямо вот верхушечка. Для дальнейшего изучения подойдёт эта серия статей, книги "RabbitMQ in Action" и "Kafka in Action".

Transient = do not serialize the field

DevOps (або Development & Operations) - відносно нова позиція в ІТ, пов'язана із вирішенням питань інфраструктури, інтеграції й оптимізації процесу завантаження й оновлення релізів продукту.

📈 Попит на DevOps-ів у світі стрімко зростає. Спеціалістам цього напрямку зі старту пропонують високі зарплати у валюті, проте й працювати доводиться із широким спектром технологій.

Якщо DevOps для тебе - не дивний акронім, а один із пріоритетних напрямків кар'єрного розвитку, наша сьогоднішня добірка корисностей саме для тебе 🤟🏻

📌 Актуальні статті для новачків у DevOps:
- Мануал для джуна. Що треба знати початківцю в DevOps: 30 запитань і поради досвідченого ліда
- Тренди DevOps — що треба знати і вміти інженеру в 2022 році
- Співбесіда з DevOps. 300+ запитань для Junior, Middle, Senior

📌 Безкоштовна сертифікація від SoftServe Academy

Навіть під час війни майже щомісяця запускаються нові стажування за напрямком DevOps від великих IT-компаній. Тож залишайся з нами та не пропусти саме свою кар'єрну можливість 🙃

🐲 Пам'ятка: часова складність структур даних

В минулих дописах рубрики #алгоритми ми дізналися, що вирішення кожної задачі потребує окремої структури даних для оптимізації ресурсів — а ще раніше з'ясували, що таке складність (О-нотація) алгоритмів.

Сподіваємось, ще не все встигло вилетіти з пам'яті 🌝

👉 Зібрали в одну картинку складності чотирьох найпростіших операцій з даними для найпоширеніших структур.

HashMap и принципы SOLID

На большинстве собесов спрашивают одно и то же. Как работает HashMap, принципы ООП и SOLID, разница абстрактного класса и интерфейса, жизненный цикл бина.

Когда я была junior/middle, 80% вопросов повторялись на каждом собеседовании. И вопросы возникали уже у меня:
🤔 Как интервьюеры поймут, что я топчик, если спрашивают такую банальщину?
🤔 Почему в вакансии целая страница требований и технологий, но мы ничего из этого не обсуждаем?
🤔 Может на проекте всё очень плохо, а код написан на java 6?

И только когда я начала собеседовать людей, то поняла, зачем это всё.

Всё дело в специфике найма джуниоров и мидлов.

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

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

1️⃣ Это база🤌

Желание обсудить саги и агрегаты это здорово, но большую часть времени разработчик проводит с кодом. Stream API, коммиты, структуры данных — в этом не должно быть пробелов.

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

Сегодня собесы больше ориентируются на практику. Бывает, что кандидат лихо объясняет synchronization order, но не видит ошибок в простом многопоточном коде. Не смущайтесь лёгких заданий, они не так просты, как кажутся:)

Время собеседования очень ограничено. Выделенные 30-60 минут лучше потратить на базу. Если с ней всё хорошо — остальное приложится

2️⃣ Легко сравнить кандидатов между собой

Если 10 человек расскажут устройство HashMap, получится 10 разных ответов.

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

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

❓ Если спрашивают банальщину — значит проект скучный?

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

❓ Как выделиться среди других кандидатов, если задают только общие вопросы?

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

Если интервьюер чем-то заинтересуется в вашем опыте, он обязательно спросит:)

❗️ Я отвечал на всё правильно, но оффер не прислали!

Причина может быть вообще не в вас. Может пришёл кандидат с более релевантным опытом, или бюджет перераспределили на другие цели.

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

Основы Kafka. Отличное видео для подготовки к собесам

#kafka #собес

https://youtu.be/-AZOi3kP9Js

https://www.udemy.com/courses/search/?q=aws+certified+cloud+practitioner&src=sac&kw=AWS+Cloud

Aws cloud certification courses

Хочете почати використовувати 🤖 Штучний Інтелект для покращення своєї роботи?

В цьому файлі зібрали для вас ТОП23 сервіси для різних типів професій

AZURE CLOUD CERTIFICATION (AZ-900)

----------------1------------------------------ (MUST HAVE)
https://www.youtube.com/watch?v=C6RFbx1STUk&ab_channel=TheTechBlackBoard

----------------2------------------------------ (NICE TO HAVE)

https://www.youtube.com/watch?v=CrU8eoBCMNI&list=PL4xJu1uDj2zrk7wQ2lPqquNPy5BfmaY0H&index=2
https://www.youtube.com/watch?v=ZfBvo-nugcQ&list=PL4xJu1uDj2zrk7wQ2lPqquNPy5BfmaY0H&index=3
https://www.youtube.com/watch?v=fWavaq9fsoc&list=PL4xJu1uDj2zrk7wQ2lPqquNPy5BfmaY0H&index=4
https://www.youtube.com/watch?v=0r_qaiLQDI4&list=PL4xJu1uDj2zrk7wQ2lPqquNPy5BfmaY0H&index=5
https://www.youtube.com/watch?v=oj9u0rk6k5w&list=PL4xJu1uDj2zrk7wQ2lPqquNPy5BfmaY0H&index=6
https://www.youtube.com/watch?v=naXuzbljouU&list=PL4xJu1uDj2zrk7wQ2lPqquNPy5BfmaY0H&index=7
https://www.youtube.com/watch?v=x1TtvJfEHTc&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC
https://www.youtube.com/watch?v=jRFkmHkj9LU&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=2
https://www.youtube.com/watch?v=g3tDLDVxV0k&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=3
https://www.youtube.com/watch?v=so2TSynj3QY&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=4
https://www.youtube.com/watch?v=b6k8N2_0HJM&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=5
https://www.youtube.com/watch?v=6xYYUq2zJEU&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=6
https://www.youtube.com/watch?v=BZMTN7k2SDM&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=7
https://www.youtube.com/watch?v=Prg7Hor7zro&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=8
https://www.youtube.com/watch?v=M1w6RzxCNCY&list=PLyABYqulvUwa9cNF9Yyv_SwdG4n17N1MC&index=9
https://www.youtube.com/watch?v=edEfRpQSjXs&list=PL0AYtrUw-NRQkrV0vscqAJvfvBnVwOP9_&index=63

----------------3------------------------------ (REVIEW)
Additional resource:
https://www.examtopics.com/exams/microsoft/az-900/view/
Test cases
https://pupuweb.com/microsoft-azure-fundamentals-az900-actual-exam-question-answer-dumps-3/2/

Corrected version of Thomas' simple table style which I like:

post - create, call procedure
put - replace existing
patch - partial update of existing