הגדרת נושאים ומחיצות ב-Kafka: מדריך כוונון

מדריך כוונון תצורת נושאים ומחיצות ב-Kafka

תארו לעצמכם: אתם עולים לאוויר בסביבת ייצור, ועיכוב הצרכנים גדל, המחיצות מוטות, וברוקר אחד עמוס. תרחיש טיפוסי עם תצורת נושא Kafka שגויה. נעבור על איך לתכנן סכמת נושא כדי להימנע מבעיות אלה.

מספר המחיצות וגורם השכפול הם שני פרמטרים שלא ניתן לשנות בקלות לאחר יצירת הנושא. הפחתת מספר המחיצות בלתי אפשרית ללא יצירה מחדש מלאה של הנושא. לכן תצורה ראשונית נכונה היא קריטית. אנו מבטיחים שעם תכנון נכון, לא תיתקלו בנקודות חמות או בעיכובים מיותרים.

מדוע תצורת מחיצות נכונה חשובה

כל מחיצה היא יחידת מקביליות. צרכן אחד בקבוצה מעבד מחיצה אחת. אם לנושא יש 6 מחיצות, לכל היותר 6 צרכנים בקבוצה יכולים לקרוא במקביל. צרכנים נוספים יושבים בטלים. בנוסף, כתיבה בתוך מחיצה מסודרת בהחלט. סדר גלובלי על פני נושא אינו מובטח—רק בתוך מחיצה. זה קריטי לאירועים שחייבים להיות מעובדים ברצף (לדוגמה, כל הפעולות של משתמש יחיד).

דוגמה: נושא user-events עם 6 מחיצות. אירועים ממשתמש יחיד (user:101) יכולים להגיע למחיצות שונות (0 ו-1), ולשבור את סדר העיבוד. מפתח הודעה פותר זאת: hash(user_id) % num_partitions תמיד מניב את אותה מחיצה.

כיצד ליצור ולהגדיר נושאים

באמצעות kafka-topics.sh

# Базовый топик для событий пользователей
kafka-topics.sh --bootstrap-server kafka-1:9092 \
  --create \
  --topic user-events \
  --partitions 12 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=10737418240 \
  --config compression.type=lz4 \
  --config min.insync.replicas=2 \
  --config message.max.bytes=1048576

# Компактный топик — для хранения последнего состояния по ключу
kafka-topics.sh --bootstrap-server kafka-1:9092 \
  --create \
  --topic user-profiles \
  --partitions 24 \
  --replication-factor 3 \
  --config cleanup.policy=compact \
  --config min.cleanable.dirty.ratio=0.1 \
  --config segment.ms=3600000 \
  --config delete.retention.ms=86400000

# Высокоприоритетная очередь с коротким retention
kafka-topics.sh --bootstrap-server kafka-1:9092 \
  --create \
  --topic order-processing-priority \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=3600000 \
  --config max.message.bytes=102400

ניהול פרוגרמטי באמצעות Admin API (Java/Kotlin) יצירת נושאים פרוגרמטית אידיאלית עבור יישומים שיוצרים נושאים דינמית:

Properties props = new Properties();
props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-1:9092,kafka-2:9092,kafka-3:9092");
props.put(AdminClientConfig.REQUEST_TIMEOUT_MS_CONFIG, 5000);
props.put(AdminClientConfig.DEFAULT_API_TIMEOUT_MS_CONFIG, 10000);
try (AdminClient admin = AdminClient.create(props)) {
    NewTopic userEvents = new NewTopic("user-events", 12, (short) 3);
    userEvents.configs(Map.of(
        "retention.ms", "604800000",
        "compression.type", "lz4",
        "min.insync.replicas", "2"
    ));
    NewTopic deadLetter = new NewTopic("user-events-dlq", 3, (short) 3);
    deadLetter.configs(Map.of(
        "retention.ms", "2592000000", // 30 дней
        "retention.bytes", "-1"
    ));
    CreateTopicsResult result = admin.createTopics(List.of(userEvents, deadLetter));
    result.all().get(30, TimeUnit.SECONDS);
}

שינוי תצורה של נושא קיים

# Увеличиваем retention
kafka-configs.sh --bootstrap-server kafka-1:9092 \
  --alter \
  --entity-type topics \
  --entity-name user-events \
  --add-config retention.ms=1209600000

# Добавляем партиции (только увеличение!)
kafka-topics.sh --bootstrap-server kafka-1:9092 \
  --alter \
  --topic user-events \
  --partitions 24

# Внимание: добавление партиций нарушает порядок для ключевых сообщений.
# Существующие ключи пойдут в те же партиции (hash % 12),
# новые ключи будут распределяться по 24 партициям.

# Просмотр конфигурации топика
kafka-configs.sh --bootstrap-server kafka-1:9092 \
  --describe \
  --entity-type topics \
  --entity-name user-events

ניהול מנהיגים והפחתת הטיה

חלוקה לא אחידה של מנהיגים בין ברוקרים מובילה לנקודות חמות:

# Проверяем распределение лидеров
kafka-topics.sh --bootstrap-server kafka-1:9092 \
  --describe --topic user-events

# Предпочтительные реплики — перебалансировка лидеров
kafka-leader-election.sh --bootstrap-server kafka-1:9092 \
  --election-type preferred \
  --all-topic-partitions

# Или для конкретного топика через JSON
cat > election.json << 'EOF'
{
  "partitions": [
    {"topic": "user-events", "partition": 0},
    {"topic": "user-events", "partition": 1}
  ]
}
EOF
kafka-leader-election.sh --bootstrap-server kafka-1:9092 \
  --election-type preferred \
  --path-to-json-file election.json

אם עיכוב הצרכנים משתנה משמעותית בין מחיצות, בדקו את המפתחות: פונקציית גיבוב גרועה גורמת להטיה. פתרון: הגדילו את מספר המחיצות והשתמשו ב-# Базовый топик для событий пользователей kafka-topics.sh --bootstrap-server kafka-1:9092 \ --create \ --topic user-events \ --partitions 12 \ --replication-factor 3 \ --config retention.ms=604800000 \ --config retention.bytes=10737418240 \ --config compression.type=lz4 \ --config min.insync.replicas=2 \ --config message.max.bytes=1048576 # Компактный топик — для хранения последнего состояния по ключу kafka-topics.sh --bootstrap-server kafka-1:9092 \ --create \ --topic user-profiles \ --partitions 24 \ --replication-factor 3 \ --config cleanup.policy=compact \ --config min.cleanable.dirty.ratio=0.1 \ --config segment.ms=3600000 \ --config delete.retention.ms=86400000 # Высокоприоритетная очередь с коротким retention kafka-topics.sh --bootstrap-server kafka-1:9092 \ --create \ --topic order-processing-priority \ --partitions 6 \ --replication-factor 3 \ --config retention.ms=3600000 \ --config max.message.bytes=102400 (זמין מ-Kafka 2.4+). חלופה: עברו ל-Properties props = new Properties(); props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-1:9092,kafka-2:9092,kafka-3:9092"); props.put(AdminClientConfig.REQUEST_TIMEOUT_MS_CONFIG, 5000); props.put(AdminClientConfig.DEFAULT_API_TIMEOUT_MS_CONFIG, 10000); try (AdminClient admin = AdminClient.create(props)) { NewTopic userEvents = new NewTopic("user-events", 12, (short) 3); userEvents.configs(Map.of( "retention.ms", "604800000", "compression.type", "lz4", "min.insync.replicas", "2" )); NewTopic deadLetter = new NewTopic("user-events-dlq", 3, (short) 3); deadLetter.configs(Map.of( "retention.ms", "2592000000", // 30 дней "retention.bytes", "-1" )); CreateTopicsResult result = admin.createTopics(List.of(userEvents, deadLetter)); result.all().get(30, TimeUnit.SECONDS); } עבור רישום. נטר את המחיצות באמצעות # Увеличиваем retention kafka-configs.sh --bootstrap-server kafka-1:9092 \ --alter \ --entity-type topics \ --entity-name user-events \ --add-config retention.ms=1209600000 # Добавляем партиции (только увеличение!) kafka-topics.sh --bootstrap-server kafka-1:9092 \ --alter \ --topic user-events \ --partitions 24 # Внимание: добавление партиций нарушает порядок для ключевых сообщений. # Существующие ключи пойдут в те же партиции (hash % 12), # новые ключи будут распределяться по 24 партициям. # Просмотр конфигурации топика kafka-configs.sh --bootstrap-server kafka-1:9092 \ --describe \ --entity-type topics \ --entity-name user-events :

# Consumer lag — отставание группы
kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 \
  --describe --group my-consumer-group
# Суммарный lag > 10000 для критичных топиков — повод для алерта

תצורות טיפוסיות לפי סוג נתונים

השוואה: Kafka לעומת RabbitMQ עבור זרמי נתונים

Apache Kafka טוב יותר מ-RabbitMQ פי 3–5 בתפוקה בעומס גבוה (מאות MB/s). RabbitMQ מנצח בניתוב גמיש (exchanges) ותמיכה בתורים עם עדיפויות שונות. עבור event sourcing ו-CDC, Kafka הוא התקן דה-פקטו; עבור מיקרוסרביסים עם ניתוב מורכב, RabbitMQ עשוי להיות נוח יותר.

התהליך שלנו וציר הזמן

עם ניסיון של למעלה מ-10 שנים ו-40+ פריסות Kafka מוצלחות, הלקוחות שלנו חוסכים בממוצע $30,000 בשנה על ידי אופטימיזציה של נושאי Kafka. הגישה שלנו היא:

• ניתוח דרישות: הערכת תפוקה, מספר צרכנים, צורכי סדר, שמירה. תכנון סכמת נושא. משך: יום אחד.
• יצירת נושא: הגדרת מחיצות, שכפול, דחיסה. הגדרת ACLs אם נדרש אימות. משך: 1–2 ימים.
• ניטור: הגדרת התראות על עיכוב צרכנים, תיעוד סכמה לצוות. משך: יום אחד.

אנו מציעים תצורה סוהר: מתכנון ועד תיעוד. אנו יכולים להעריך את הפרויקט שלכם ביום אחד — צרו קשר.

מה כלול?

• תיעוד ארכיטקטוני: סכמת נושא, מפתחות, שמירה.
• תצורת ברוקר ונושא.
• הגדרת ניטור והתראות.
• הדרכת צוות (2–4 שעות).
• חודש אחד של תמיכה לאחר העלייה לאוויר.

ציר זמן

תצורת מחיצות נכונה מפחיתה את זמן האחזור ב-30% בהשוואה לתצורות לא אופטימליות (בהתבסס על הנתונים שלנו). קבלו ייעוץ לפרויקט שלכם — פנו אלינו.

למדו עוד על Apache Kafka ב-ויקיפדיה.