Перейти до основного вмісту

Стратегії ребалансування в Kafka

Стратегії ребалансування в Kafka

Ребалансування (Rebalancing) — це процес перерозподілу партицій між споживачами (сonsumer) у групі (Consumer Group). Kafka має кілька стратегій ребалансування:

  1. RangeAssignor. Ця стратегія розподіляє партиції на основі діапазонів, які створюються відповідно до сортування топіків і партицій. Наприклад, якщо є два консюмери і 6 партицій (P0–P5), перший консюмер отримає P0–P2, а другий — P3–P5.
    Особливості:
    • Простий алгоритм.
    • Може призводити до нерівномірного розподілу, якщо кількість партицій не ділиться порівну між консюмерами.
  2. RoundRobinAssignor. Ця стратегія рівномірно розподіляє партиції між консюмерами за круговим принципом. Наприклад, якщо є два консюмери і 6 партицій, перший отримає P0, P2, P4, а другий — P1, P3, P5.
    Особливості:
    • Гарантує більш рівномірний розподіл партицій.
    • Використовується в багатотопікових сценаріях.
  3. StickyAssignor. Ця стратегія намагається мінімізувати кількість змін у розподілі партицій між консюмерами при ребалансуванні. Партиції залишаються закріпленими за консюмерами, якщо це можливо.
    Особливості:
    • Мінімізує вплив ребалансування на продуктивність.
    • Використовується в сценаріях, де стабільність розподілу є критично важливою.
  4. Cooperative Sticky Assignor. Поліпшена версія StickyAssignor, виконується поступове (кооперативне) перерозподілення партицій між консюмерами.
    Особливості:
    • Зменшує час простою під час ребалансування.
    • Рекомендується для високонавантажених систем.
Вибір стратегії

Стратегія вибирається за допомогою параметра partition.assignment.strategy у конфігурації споживача.

Значення може бути одним із наведених:

  • org.apache.kafka.clients.consumer.RangeAssignor
  • org.apache.kafka.clients.consumer.RoundRobinAssignor
  • org.apache.kafka.clients.consumer.StickyAssignor
  • org.apache.kafka.clients.consumer.CooperativeStickyAssignor

Sticky Partitioner

Sticky Partitioner в Apache Kafka – це механізм, який забезпечує більш ефективний розподіл повідомлень між партиціями. Sticky Partitioner дозволяє уникнути частої зміни партицій, зменшуючи кількість перенаправлень, що підвищує продуктивність.

Основна ідея Sticky Partitioner

Замість того, щоб визначати партицію для кожного повідомлення окремо (наприклад, на основі ключа), Sticky Partitioner закріплює продюсера за однією партицією на деякий час. Повідомлення записуються в одну партицію, поки не буде досягнуто певного розміру пакета або часу очікування (batch size або linger.ms). Після цього продюсер переходить до іншої партиції.

Алгоритм:

  1. Sticky Partitioner вибирає партицію для першого повідомлення в новому пакеті (batch).
  2. Усі наступні повідомлення надходять до тієї ж партиції, доки не буде заповнено пакет або не спливе час очікування.
  3. Коли пакет відправлено, партиція змінюється, і процес повторюється.
Налаштування Sticky Partitioner:

Sticky Partitioner налаштовується через властивості продюсера, зокрема:

  • batch.size – максимальний розмір пакета (в байтах). За замовчуванням: 16384 (16 KB).
  • linger.ms – максимальний час очікування перед відправкою пакета. За замовчуванням: 0 (відправка негайно).
  • max.request.size – максимальний розмір одного повідомлення чи пакета.

Sticky Partitioner та стратегії ребалансування працюють на різних рівнях Kafka, але вони взаємопов'язані через механізм розподілу навантаження між партиціями та споживачами.

Sticky Partitioner оптимізує роботу продюсера, відправляючи повідомлення батчами в одну партицію.

Стратегії ребалансування оптимізують роботу споживачів, розподіляючи партиції рівномірно.

Коментарі

Популярні публікації

Створення нового Elixir-проєкту

Для створення новго Elixir-проєкту можна використати команду mix new first_project --sup Зрозуміло, що Elixir має бути встановлений раніше. Пояснення команди: mix — це вбудований інструмент для управління проєктами в Elixir (аналог maven у Java чи npm у JavaScript ). new — підкоманда mix, яка створює новий проєкт. first_project — назва твого нового проєкту. Папка з цією назвою буде створена у поточному каталозі. --sup — опціональний прапорець, який додає шаблон структури з Supervision Tree. Це означає, що створений проєкт одразу буде мати структуру, яка підтримує супервізор (супервізор керує життєвим циклом процесів у системі, перезапускаючи їх при падінні). Щоб створити файл з тестом, можна запустити команду із директорії проєкту mix test Приблизний вигляд структури проєкту:

Шпаргалка по базових командах PostgreSQL

1. Підключення до PostgreSQL через командний рядок: psql -h <host> -p <port> -U <username> -d <database> 2. Підключення до бази без параметрів (якщо користувач і база мають однакове ім’я): psql 3. Показати список усіх баз даних: \l 4. Підключитися до іншої бази даних: \c <database_name> 5. Показати список таблиць у поточній базі: \dt 6. Показати всі об'єкти (таблиці, індекси, секвенції): \d 7. Показати таблиці з усіх схем: \dt *.* 8. Переглянути структуру конкретної таблиці: \d <table_name> 9. Виконати SQL-запит (приклад): SELECT * FROM users; 10. Вийти з psql: \q 11. Створити нову базу даних: CREATE DATABASE mydb; 12. Створити нову таблицю: CREATE TABLE users ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, email TEXT UNIQUE ); 13. Додати новий запис: INSERT INTO users (name, email) VALUES ('Іван', 'ivan@example.com'); 14. Оновити дані в таблиці: UPDATE users SET name = 'Петро' WH...

Агрегати в DDD

Domain-Driven Design (DDD, предметно-орієнтоване проєктування) — це підхід до розробки програмного забезпечення, який зосереджується на моделюванні бізнес-логіки на основі реального домену (предметної області). Його запропонував Ерік Еванс у своїй книзі "Domain-Driven Design: Tackling Complexity in the Heart of Software". Основні принципи DDD Фокус на домені – головна увага приділяється предметній області, а не технічним деталям. Єдина мова (Ubiquitous Language) – розробники, бізнес-аналітики та інші учасники проєкту використовують спільну термінологію, щоб уникнути непорозумінь. Бізнес-логіка відокремлена від технічної реалізації – код моделюється так, щоб він чітко відображав реальний бізнес-процес. Основні концепції DDD Entity (Сутність) – об’єкт з унікальним ідентифікатором, що зберігається в системі (наприклад, Користувач, Замовлення). Value Object (Об’єкт-значення) – об’єкт, який не має унікального ідентифікатора та є незмінним (наприклад, Адреса або Гроші)...

Docker-compose для створення Postgresql бази даних

Docker Compose — це інструмент, який дозволяє визначати та запускати багатоконтейнерні Docker-застосунки. Замість того, щоб вручну запускати кожен контейнер із довгими командами docker run, docker-compose.yml надає простий спосіб описати всю архітектуру додатка у вигляді YAML-файлу. Це дозволяє легко створювати, запускати, зупиняти та масштабувати сервіси за допомогою однієї команди, що значно спрощує розробку, тестування та розгортання застосунків. Основні можливості Docker Compose включають: запуск кількох контейнерів одночасно, визначення мережі та спільних томів між контейнерами, налаштування змінних середовища та автоматичне підключення сервісів один до одного через імена сервісів. Він особливо корисний для локального середовища розробки, CI/CD-процесів і навіть невеликих продакшен-рішень, де потрібно швидко відтворити середовище для тестування або демонстрації. Мінімальний docker-compose.yml для локального використання PostgreSQL без збереження даних після видалення контейне...

Шпаргалка по запуску та збірці Spring Boot-проєктів

Maven + Spring Boot 1. Збірка проєкту (із завантаженням залежностей, компіляцією, запуском тестів та створенням артефакту) mvn clean install 2. Збірка артефакту без встановлення у локальний репозиторій mvn package 3. Збірка без тестів mvn clean package -DskipTests 4. Запуск Spring Boot-проєкту mvn spring-boot:run 5. Запуск із активним профілем Spring Boot mvn spring-boot:run -Dspring-boot.run.profiles=dev 6. Запуск із параметрами mvn spring-boot:run -Dspring-boot.run.arguments="--server.port=8081 --spring.profiles.active=prod" 7. Запуск з jar-файлу java -jar target/your-app-name.jar 8. Запуск тестів mvn test 9. Запуск, якщо pom.xml у підкаталозі mvn -f шлях/до/pom.xml spring-boot:run 10. Запуск із Maven-профілем (не плутати з Spring Boot профілем) mvn clean install -P dev Gradle + Spring Boot 1. Збірка проєкту (з компіляцією, тестами та створенням jar) ...