🕯 Паттерн Observer (Наблюдатель)

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

Использование:

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

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

1️⃣ Обеспечивает слабую связанность между объектами.
2️⃣ Упрощает динамическое добавление новых наблюдателей без изменения кода субъекта.
3️⃣ Позволяет множеству объектов реагировать на события.

Недостатки:

1️⃣ Может приводить к большим накладным расходам при большом количестве наблюдателей.
2️⃣ Потенциальная сложность отладки из-за непредсказуемого порядка оповещения.
3️⃣ Может возникнуть ситуация, когда наблюдатели получают неконсистентное состояние.

📊 Логирование, трассировка и метрики

Логирование, трассировка и метрики — это три столпа наблюдаемости системы

🔹 Логирование
Логирование фиксирует дискретные события в системе. Например, мы можем записывать входящие запросы или обращения к базам данных как события. Это самый объемный тип данных. Для построения платформы анализа логов часто используют стек ELK (Elastic-Logstash-Kibana). Мы часто определяем стандартизированный формат логов для разных команд, чтобы использовать ключевые слова при поиске среди большого объема логов.

🔹 Трассировка
Трассировка обычно привязана к запросам. Например, пользовательский запрос проходит через API-шлюз, балансировщик нагрузки, сервис A, сервис B и базу данных — это можно визуализировать в системах трассировки. Это полезно для выявления узких мест в системе. OpenTelemetry используется для демонстрации типичной архитектуры, которая объединяет три столпа в одной платформе.

🔹 Метрики
Метрики — это обычно агрегируемая информация из системы. Например, QPS сервиса, отзывчивость API, задержка сервиса и т.д. Сырые данные записываются в базы данных временных рядов, такие как InfluxDB. Prometheus извлекает данные и преобразует их на основе предопределенных правил оповещений. Затем данные отправляются в Grafana для отображения или в менеджер оповещений, который затем рассылает уведомления по email, SMS или в Slack.

💬 Какие инструменты вы используете для мониторинга системы?

⌛ Введение в CompletableFuture

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

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

▪️ Запускать задачи асинхронно;
▪️ Комбинировать несколько задач;
▪️ Обрабатывать ошибки без try-catch;
▪️ Строить цепочки зависимостей.

Пример создания асинхронной задачи:

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    // Эмуляция долгой задачи
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        throw new IllegalStateException(e);
    }
    return "Задача завершена!";
});

System.out.println(future.join()); // Ожидание завершения и получение результата

Здесь задача выполняется в фоновом потоке, а основной поток продолжает свою работу.

🎮 Комбинирование нескольких задач

Часто нужно дождаться завершения нескольких задач и собрать их результаты. С помощью thenCombine() можно комбинировать результаты нескольких асинхронных вычислений:

CompletableFuture<Integer> future1 = CompletableFuture.supplyAsync(() -> 50);
CompletableFuture<Integer> future2 = CompletableFuture.supplyAsync(() -> 20);

CompletableFuture<Integer> result = future1.thenCombine(future2, Integer::sum);

System.out.println(result.join()); // 70

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

❌ Обработка ошибок

Одним из главных преимуществ CompletableFuture является возможность обрабатывать ошибки без try-catch через метод exceptionally():

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> {
    if (true) throw new RuntimeException("Ошибка!");
    return 42;
}).exceptionally(ex -> {
    System.out.println("Произошла ошибка: " + ex.getMessage());
    return 0; // Возвращаем дефолтное значение в случае ошибки
});

System.out.println(future.join()); // 0

Этот подход улучшает читаемость и упрощает обработку исключений в асинхронном коде.

📎 Композиция цепочек

Вы можете строить целые цепочки задач с помощью методов thenApply(), thenAccept() и т.д. Пример использования:

CompletableFuture.supplyAsync(() -> "Hello")
    .thenApply(result -> result + " World")
    .thenAccept(finalResult -> System.out.println(finalResult)); // Hello World

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

🛠 Применение на практике

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

CompletableFuture<String> api1 = CompletableFuture.supplyAsync(() -> {
    // Эмуляция запроса к первому API
    return "Response from API 1";
});

CompletableFuture<String> api2 = CompletableFuture.supplyAsync(() -> {
    // Эмуляция запроса ко второму API
    return "Response from API 2";
});

CompletableFuture<Void> allOf = CompletableFuture.allOf(api1, api2);

allOf.thenRun(() -> {
    try {
        System.out.println(api1.get() + " & " + api2.get());
    } catch (Exception e) {
        e.printStackTrace();
    }
});

🔍 Что такое MVC?

MVC (Model-View-Controller) — это популярный архитектурный паттерн, который разделяет приложение на три компонента:

Model — отвечает за бизнес-логику и управление данными. Это сердце приложения, где происходит взаимодействие с базой данных, выполнение бизнес-правил и другие операции.

View — представляет собой интерфейс пользователя. Он отвечает за отображение данных и взаимодействие с пользователем, но не содержит бизнес-логики.

Controller — посредник между Model и View. Он получает запросы от пользователя, передает их Model и возвращает результаты во View.

💡 MVC позволяет четко разделить обязанности между компонентами, облегчая поддержку и масштабирование кода.

👀 Принципы SOLID

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

Рассмотрим каждый принцип:

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

2️⃣ Принцип открытости/закрытости (O)
Классы должны быть открыты для расширения, но закрыты для изменения. Это значит, что поведение класса можно расширять, не изменяя его существующий код. В Java это часто реализуется через использование интерфейсов или абстрактных классов.

3️⃣ Принцип подстановки Барбары Лисков (L)
Объекты суперкласса должны заменяться объектами подкласса без нарушения корректности программы. В Java это особенно важно при работе с наследованием, чтобы подклассы правильно расширяли базовые классы, не изменяя их поведение.

4️⃣ Принцип разделения интерфейса (I)
Клиенты не должны зависеть от интерфейсов, которые они не используют. В Java это достигается путем разделения крупных интерфейсов на более узкоспециализированные, чтобы классы реализовывали только те методы, которые им действительно нужны.

5️⃣ Принцип инверсии зависимостей (D)
Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций. В Java это часто реализуется через внедрение зависимостей (Dependency Injection), которое позволяет передавать зависимости извне, что способствует слабой связности и гибкости системы.

🕯 Паттерн Adapter (Адаптер)

Adapter — это структурный паттерн, который позволяет объектам с несовместимыми интерфейсами работать вместе. Он действует как обёртка между двумя классами, приводя их интерфейсы к общему виду.

Использование:

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

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

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

Недостатки:

1️⃣ Увеличивает сложность системы за счёт введения дополнительных классов.
2️⃣ Может привести к увеличению времени выполнения программы при частом использовании.

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

⚡️ Уровни изоляции транзакций в базах данных

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

🔑 Что такое изоляция транзакций?

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

🔒 Типы уровней изоляции:

🔹 Read Uncommitted:
Самый низкий уровень изоляции. Транзакции могут читать изменения, сделанные другими транзакциями, даже если они не были зафиксированы (грязные чтения). Быстро, но рискованно.

🔹 Read Committed:
Видны только зафиксированные данные. Это исключает грязные чтения, но могут возникать неповторяемые чтения (данные меняются между двумя запросами).

🔹 Repeatable Read:
Гарантирует, что данные, прочитанные транзакцией, не могут быть изменены другой транзакцией до завершения первой. Однако возможны фантомные чтения (новые строки появляются при повторных запросах).

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

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

💬 Какой уровень изоляции вы чаще используете в своих приложениях?