ℹ️ A Guide to CompletableFuture

Статья подробно объясняет, как использовать CompletableFuture в Java для создания асинхронного и параллельного кода. В ней рассматриваются ключевые аспекты, такие как создание, объединение задач, обработка исключений и жизненный цикл CompletableFuture. Если собираетесь освоить передовые техники работы с асинхронными операциями в Java и значительно улучшить производительность своего кода, эта статья будет полезна.

Читать статью.

🖥 10 Java-библиотек, которые изменят ваш код

Эта статья представляет 10 Java-библиотек, которые могут кардинально изменить ваш подход к программированию. Вы узнаете, как такие инструменты, как Lombok, Jackson и Apache Commons, могут существенно упростить ваш код, улучшить его производительность и сделать разработку более эффективной. Если вы хотите узнать, как сделать свой код чище и функциональнее, эта статья станет отличным гидом в мир передовых Java-библиотек​.

Читать статью

🔍 Что такое ElasticSearch

ElasticSearch — это распределенная поисковая система с открытым исходным кодом, которая позволяет быстро и эффективно обрабатывать и анализировать большие объемы данных. Она идеально подходит для приложений, требующих гибкости в поиске и высокой скорости обработки запросов. Благодаря интеграции с Kibana и Logstash, ElasticSearch становится мощным инструментом для мониторинга и анализа данных в реальном времени.

📌 Use cases:

▪️ Мгновенный поиск по большим объемам данных
▪️ Гибкая схема индексации и поиска
▪️ Легкость в масштабировании и интеграции

📶 Паттерны коммуникации в распределенных системах

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

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

☑️ Запрос-ответ с HTTP

Этот синхронный паттерн коммуникации предполагает, что один сервис отправляет запрос другому сервису и ожидает ответа или ошибки, блокируя свою работу до получения результата. REST, наиболее популярный архитектурный стиль для этой модели коммуникации, использует методы протокола HTTP — GET, POST, PUT и DELETE.
 
Однако использование этого паттерна может привести к проблемам, если сервисы образуют цепочку взаимодействий: в таком случае сбой одного из сервисов может привести к отказу всей операции, а также к расточительному использованию ресурсов и каскадным сбоям.

☑️ Общие данные

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

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

☑️ Асинхронный запрос-ответ

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

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

☑️ Коммуникация на основе событий

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

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

👨‍💻 Подробнее читайте в статье.
📨 Материал взят из нашей еженедельной email-рассылки, посвященной бэкенду. Подпишитесь, чтобы быть в числе первых, кто получит дайджест.

🚫 Ключевые проблемы многопоточности

🔵 Состояние гонки (Race Conditions):

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

🔵 Взаимные блокировки (Deadlocks):

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

🔵 Ошибки конкуренции (Concurrency Bugs):

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

🔵 Прерывание потока (Thread Interruption):

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

🔵 Ошибки согласованности памяти (Memory Consistency Errors):

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

🔵 Соперничество за ресурсы (Resource Contention):

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

🔵 Голодание (Starvation):

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

💸 А у вас есть платные подписки?

💬 Расскажите в комментариях, что это за сервисы👇

🔼 Топ-5 способов улучшить производительность API:

1️⃣ Пагинация результатов:
Этот метод используется для оптимизации больших наборов данных путем их постраничной передачи клиенту, что повышает отзывчивость сервиса и улучшает пользовательский опыт.

2️⃣ Асинхронное логирование:
Этот подход предполагает отправку логов в буфер без блокировки и немедленное возвращение управления, вместо того чтобы записывать данные на диск при каждом вызове. Логи периодически сбрасываются на диск, что значительно снижает нагрузку на систему ввода-вывода.

3️⃣ Кэширование данных:
Часто запрашиваемые данные могут храниться в кэше для ускорения их извлечения. Клиенты сначала проверяют кэш перед обращением к базе данных, а такие решения для хранения данных, как Redis, обеспечивают более быстрый доступ благодаря хранению в оперативной памяти.

4️⃣ Сжатие payload:
Чтобы сократить время передачи данных, запросы и ответы можно сжимать, что ускоряет процессы загрузки и выгрузки.

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

💬 А как вы улучшаете перфоманс API?