❓ Какие бывают гарантии доставки сообщений в Kafka?

В Kafka существует три уровня гарантий доставки сообщений:

1️⃣ At most once (максимум один раз)

Сообщение может быть потеряно, но никогда не будет обработано дважды. Producer отправляет сообщение и не ждет подтверждения (acks=0). Самый быстрый, но ненадежный вариант.

2️⃣ At least once (минимум один раз)

Сообщение гарантированно доставлено, но может быть обработано несколько раз. Producer ждет подтверждения от лидера (acks=1) или всех реплик (acks=all). При повторной отправке возможны дубликаты. Используется чаще всего.

3️⃣ Exactly once (ровно один раз)

Сообщение доставляется и обрабатывается строго один раз. Достигается через idempotent producer (enable.idempotence=true) и транзакции. Самый надежный, но с небольшим оверхедом по производительности.

Выбор зависит от задачи: для логов подойдет at most once, для финансовых операций — exactly once, для большинства случаев — at least once с идемпотентной обработкой.

🐸 Библиотека собеса по Java

#core

🔍 Просто о сложном: Record Class

Record-классы появились в Java 14 (вначале как preview, позже стабилизированы) и стали настоящим спасением от шаблонного кода.

Это лаконичный способ описать неизменяемые data-классы — без десятков строк с конструкторами, equals(), hashCode() и toString().

🔹 Зачем они нужны

Раньше, чтобы описать простой объект вроде User, нужно было писать шаблонный код:

class User {
private final String name;
private final int age;

public User(String name, int age) {
this.name = name;
this.age = age;
}

// геттеры, equals, hashCode, toString...
}

С record это выглядит так:

record User(String name, int age) {}

И всё — у вас уже есть:

— конструктор, геттеры, equals(), hashCode(), toString();
— неизменяемость полей;
— компактность и читаемость.

🔹 Ключевые моменты

▪️ record — это специальный вид класса, унаследованный от java.lang.Record.
▪️ Все поля — final, сеттеров нет.
▪️ Можно добавить собственные методы и статические фабрики.
▪️ Можно переопределить канонический конструктор для валидации.
▪️ Можно объявлять вложенные рекорды и использовать их в switch или pattern matching.

🔹 Под капотом

Record — это не просто “синтаксический сахар”. JVM видит его как финальный класс с приватными финальными полями и стандартными методами, но запрещает наследование (final) и предполагает неизменность.

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

🔹 Подводные камни

— Record ≠ DTO везде

Если вы сериализуете/десериализуете через фреймворки (Jackson, JPA), убедитесь, что они поддерживают record (современные версии — да).

— Проблемы с неймингом

Для рекордов автоматически создаются методы-геттеры без префикса get. Например, для record User(String name) будет метод name(), а не getName().

Это ломает привычные JavaBean-паттерны и может вызвать проблемы с библиотеками, которые ожидают именно getName().

— Не подходит, если нужен мутабельный объект.

Для билдера или ORM-энтити используйте обычный класс.

— Не добавляйте бизнес-логику внутрь record.

Это data-контейнер, а не доменная сущность.

✔️ Когда можно использовать

— DTO между слоями;
— Результаты запросов к БД (projection);
— Ответы REST API;
— Ключи в Map и Set;
— В тестах и утилитах для временных структур.

❌ Не подходит:

— На практике редко используется из-за проблем с неймингом.
— Для ORM-сущностей, билдера, и изменяемых структур.

🐸 Библиотека джависта

#CoreJava

⌛ Сохраняйте шпаргалку по Thread

🐸 Библиотека джависта

#Enterprise