📊 CI/CD Pipeline

CI/CD пайплайн — это система, которая позволяет автоматизировать ключевые этапы разработки: от сборки и тестирования до развертывания программного обеспечения. Такой подход объединяет все стадии жизненного цикла проекта — написание кода, его проверку, тестирование и публикацию — в единый поток, где каждый шаг выполняется автоматически и последовательно.

На диаграмме выше представлены инструменты, которые часто используются для создания эффективного CI/CD пайплайна.

💬 Вы применяете какие-то из них в своих проектах?

🕯 Паттерн Синглтон (Singleton)

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

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

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

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

1️⃣ Гарантирует наличие только одного экземпляра, что удобно для управления ресурсами и предотвращения конфликтов.
2️⃣ Обеспечивает ленивую инициализацию, что позволяет создавать объект только при необходимости (если реализовано правильно).
3️⃣ Удобен для централизованного управления состоянием или ресурсами в системе.

Недостатки:

1️⃣ Нарушает принцип единственной ответственности (SRP), так как класс управляет своим созданием и жизненным циклом.
2️⃣ Усложняет тестирование, поскольку сложно замещать или мокать объект.
3️⃣ Может создавать скрытые зависимости, что приводит к сложности поддержки и масштабирования кода.
4️⃣ В многопоточной среде требуется дополнительная синхронизация для обеспечения безопасности, что может снижать производительность.

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

🚀 Apache Pulsar 4.0: новые горизонты для работы с потоками данных

Apache Pulsar, одна из самых популярных платформ для работы с потоками данных, представила версию 4.0, и это событие заслуживает внимания. 🌟

Что нового:

1️⃣ Улучшенная реализация подписки Key_Shared: обеспечивает более эффективную и надежную обработку сообщений с использованием подписки типа Key_Shared.
2️⃣ Безопасная Docker-среда на базе Alpine Linux и Java 21: новые Docker-образы основаны на Alpine Linux, что уменьшает размер образа и повышает безопасность. Включение Java 21 с Generational ZGC улучшает производительность.
3️⃣ Поддержка OpenTelemetry: внедрение OpenTelemetry-метрик в клиенте Pulsar позволяет более эффективно отслеживать и анализировать производительность приложений.
4️⃣ Обновления в управлении нагрузкой: внедрение новых алгоритмов балансировки нагрузки, таких как AvgShedder, улучшает распределение ресурсов и повышает стабильность системы.
5️⃣ Поддержка Geo-Replication с началом с самой ранней позиции: обеспечивает более гибкое управление репликацией данных между кластерами.

🔗 Узнать больше

💬 Кто уже использует Apache Pulsar?

ℹ️ Что такое нормализация базы данных, и какие существуют нормальные формы?

Нормализация — это процесс приведения структуры базы данных к оптимальному виду для устранения избыточности данных и обеспечения их целостности. Процесс состоит из последовательных этапов, соответствующих нормальным формам (НФ).

Основные нормальные формы (НФ):

1️⃣ Первая нормальная форма (1НФ):
Данные делятся на атомарные (неделимые) значения.
Пример: В одной ячейке таблицы не может быть списка телефонов, вместо этого создается отдельная строка для каждого телефона.

2️⃣ Вторая нормальная форма (2НФ):
Требует выполнения 1НФ и исключения зависимости от части составного первичного ключа. Это устраняет проблему дублирования данных.
Пример: Если таблица использует составной ключ (например, "Курс" и "Студент"), информация, относящаяся только к "Курсу", выносится в отдельную таблицу.

3️⃣ Третья нормальная форма (3НФ):
Выполняется 2НФ и устраняются транзитивные зависимости — неключевые атрибуты должны зависеть только от ключа.
Пример: Если в таблице есть "ID сотрудника", "Отдел" и "Название отдела", то "Название отдела" переносится в отдельную таблицу "Отделы".

Редко используемые нормальные формы:

- Нормальная форма Бойса-Кодда (BCNF): Уточнённая версия 3НФ, где каждое определяющее множество является суперключом. Используется для устранения более сложных аномалий.
- Четвёртая нормальная форма (4НФ): Устраняет многозначные зависимости, которые появляются при использовании нескольких связей между одними и теми же атрибутами.
- Пятая нормальная форма (5НФ): Делает базу данных устойчивой к разделению данных, устраняя зависимости соединений.

Эти формы применяются в сложных сценариях, например, при проектировании корпоративных систем с огромным количеством взаимосвязей. Для большинства приложений 3НФ оказывается достаточной.

📊 Как работает ConcurrentHashMap под капотом?

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

💡 Основные механизмы:

🔹 Сегментация данных (до 8 java): Данные разделялись на сегменты, и блокировка происходила на уровне сегмента, а не всей карты. Это обеспечивало параллельный доступ к разным частям карты.

🔹 Кассовые таблицы (Java 8+): Вместо сегментов используется структура на основе Node[] – массив узлов. Это сделало структуру более гибкой. Вместо сегментации применяется механизм Fine-Grained Locking и Compare-And-Swap:
- Compare-And-Swap используется для операций записи, что позволяет избегать блокировок для большинства операций. Операции с разными бакетами могут выполняться параллельно, поскольку локальная блокировка применяется только к отдельному узлу или бакету.
- Fine-Grained Locking минимизирует область блокировок. Например, если требуется масштабирование (resize) или обработка коллизий, потоки могут продолжать работу с другими бакетами, даже если один из них временно заблокирован.
- synchronized применяется только для случаев, когда CAS не справляется (например, при реорганизации данных или сложных операциях). Это помогает поддерживать баланс между безопасностью и производительностью.

🔹 Масштабируемый массив (Resizable Array): Масштабирование в ConcurrentHashMap происходит градуально, чтобы избежать блокировки всей структуры. Новый массив создаётся с увеличенным размером, и данные переносятся постепенно, по частям. Во время переноса используется специальный узел ForwardingNode, который перенаправляет операции к новому массиву, обеспечивая корректную работу всех потоков.

📚 Основные методы:

▪️ get(Object key):
Легковесная операция, не требует блокировок. Ключ хэшируется, затем вычисляется индекс сегмента. Если в сегменте есть соответствующий узел, он возвращается.

▪️ put(K key, V value):
- Сначала используется CAS для вставки нового элемента.
- Если CAS не срабатывает (например, при наличии коллизии), включается локальная блокировка на соответствующей корзине.

▪️ computeIfAbsent/compute:
Более сложные операции, которые комбинируют вычисления с модификацией. Используются короткие локи для минимизации блокировки других потоков.

⚠️ Особенности:

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

Документация