⁉️ Ваши микросервисы тормозят? База данных перегружена? Решение есть — кэширование!

На открытом уроке «Кэширование в микросервисной архитектуре» мы разберём, как ускорить системы, сократить время отклика и снизить нагрузку. Вы узнаете про паттерны кэширования, типы кэшей и популярные инструменты вроде Redis и Memcached.

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

🔥 Спикер Сергей Прощаев — ведущий инженер-Java-разработчик в одной из крупнейших нефтяных компаний России.

🔴 Регистрируйтесь на вебинар 11 декабря в 20:00 мск! Урок пройдёт перед стартом курса «Microservice Architecture». Только участники получат скидку на обучение: https://vk.cc/cFmQmx

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Как устроен под капотом LinkedHashMap?

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

🔹 Структура LinkedHashMap

Основой LinkedHashMap является та же хэш-таблица, что и в HashMap, но с дополнительной структурой двусвязного списка для сохранения порядка элементов:

▪️ Каждая запись (entry) в LinkedHashMap содержит ссылки на предыдущий и следующий элементы. Это позволяет поддерживать порядок добавления или порядок последнего доступа.
▪️ Сначала выполняется хэширование ключей для быстрой вставки и поиска, как в HashMap, а уже потом запись связывается в список.

🔹 Производительность

▪️ Вставка: Добавление новых элементов выполняется за O(1), поскольку элементы добавляются в конец двусвязного списка, а хэш-таблица используется для поиска свободной позиции.
▪️ Удаление: Удаление элемента требует корректировки ссылок в двусвязном списке, что увеличивает накладные расходы, но также выполняется за O(1).
▪️ Поиск: Операция поиска по ключу происходит с использованием хэш-таблицы и выполняется за O(1), как и в HashMap.
▪️ Множественные коллизии: в худшем случае все операции будут выполняться с O(n), если допустить множественные коллизии.

🔹 Использование памяти

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

🔹 Преимущества и недостатки

▪️ Преимущества:

- Сохранение порядка вставки: LinkedHashMap гарантирует, что элементы будут извлекаться в том порядке, в котором они были добавлены.
- Порядок доступа: Можно настроить LinkedHashMap на удаление самых старых элементов, что полезно для кэшей, где используется политика LRU (Least Recently Used).
- Предсказуемость итераций: В отличие от HashMap, где порядок элементов может изменяться, LinkedHashMap всегда сохраняет стабильный порядок.

▪️ Недостатки:

- Более высокое потребление памяти: Дополнительные ссылки на предыдущие и следующие элементы увеличивают память на каждую запись.
- Скорость: LinkedHashMap немного медленнее HashMap из-за поддержания порядка элементов.

@javalib #java

Как работает 𝐠𝐑𝐏𝐂

gRPC (Google Remote Procedure Call) — это современный фреймворк с открытым исходным кодом, разработанный компанией Google для эффективной и масштабируемой коммуникации между микросервисами. Он основан на RPC (удалённый вызов процедур) и используется для построения распределённых систем и микросервисных архитектур.

Выше показана диаграмма, иллюстрирующая общий поток данных для 𝐠𝐑𝐏𝐂.

Шаг 1: Клиент отправляет REST-запрос, обычно в формате JSON.

Шаги 2 - 4: Сервис заказа (клиент gRPC) получает REST-запрос, преобразует его и делает RPC-вызов к сервису оплаты. gPRC кодирует клиентский stub в бинарный формат и отправляет на транспортный уровень.

Шаг 5: gRPC передаёт пакеты по сети через HTTP/2. Благодаря бинарному кодированию и сетевым оптимизациям gRPC работает в 5 раз быстрее, чем JSON.

Шаги 6 - 8: Сервис оплаты (сервер gRPC) получает пакеты, декодирует их и вызывает серверное приложение.

Шаги 9 - 11: Результат возвращается с серверного приложения, кодируется и передаётся на транспортный уровень.

Шаги 12 - 14: Сервис заказа получает пакеты, декодирует их и отправляет результат клиентскому приложению.

@javalib #java

Что выведет данный фрагмент кода?

Согласованность в распределённой сети — вызов, который мы готовы принять!

На открытом уроке «Распределённые транзакции» разберём, как добиться согласованности данных в микросервисной и распределённой архитектуре. Изучим шаблон Saga, методы обработки ошибок и практики отката данных.

Представьте систему, которая работает без сбоев, несмотря на распределённость данных. Архитектура, которая поддерживает масштабируемость и надёжность, даже при высоких нагрузках.

🔥 Спикер Олег Мифле — бэкенд-разработчик в одной из крупнейших отечественных соцсетей с 15-летним опытом в IT.

🔴 Присоединяйтесь к вебинару 16 декабря в 20:00 мск! Урок пройдёт перед стартом курса «Highload Architect». Участники вебинара получат скидку на обучение: https://vk.cc/cFHQbY

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576