पाठ 25 / 25

Revision: Cheat Sheet और Self-Check

पूरे कोर्स की Kafka की अवधारणाओं, settings और संचालन आदतों की दोहराई करें।

Cheat sheet

मॉडल: topic → partitions (क्रमबद्ध logs) → offsets; records में key/value/timestamp/headers; क्रम सिर्फ़ एक partition के भीतर। Producers: key → murmur2 % partitions; acks=all, idempotence, linger.ms, compression; registry के साथ schemas। Consumers: group = प्रति partition एक consumer; प्रोसेसिंग के बाद commit (at-least-once) और handlers idempotent बनाएँ; lag = log-end − committed; rebalances; poison records के लिए DLT। Topics: throughput से partitions का आकार (सिर्फ़ बढ़ सकते हैं; key मैपिंग बदलती है); retention बनाम compaction (tombstones); नामकरण और स्वामित्व। Durability: rf=3, min.insync.replicas=2, acks=all, कोई unclean चुनाव नहीं; Kafka के भीतर transactions से exactly-once। Ecosystem: Connect, Streams/Flink/ksqlDB। संचालन: lag, URP, disk, latency; TLS + SASL + ACLs; rolling upgrades; क्षमता = दर × retention × rf।

इंटरव्यू में पूछे जाने वाले सवाल

इन्हें समझाने को तैयार रहें: Kafka में क्रम कैसे काम करता है और वह प्रति partition क्यों है, consumer group कैसे scale होता है, at-least-once का क्या मतलब है और प्रोसेसिंग को idempotent कैसे बनाते हैं, acks, replication factor और min.insync.replicas कैसे मिलते हैं, partitions जोड़ने पर क्या होता है, और बढ़ते consumer lag को कैसे debug करेंगे।

त्वरित जाँच: Consumer lag बढ़ता जा रहा है। संभावित पहली जाँच कौन-सी है?

  • क्या topics के नाम लंबे हैं
  • क्या font पढ़ने योग्य है
  • क्या consumers धीमे या अटके हैं, या partitions/consumers कम हैं
  • Topic हटाना
Answer

क्या consumers धीमे या अटके हैं, या partitions/consumers कम हैं — Lag तब बढ़ता है जब प्रोसेसिंग उत्पादन से धीमी हो, इसलिए consumer की गति, errors, rebalances और समानांतरता जाँचें।

त्वरित जाँच: कौन-सा setup स्वीकृत writes खोए बिना एक broker विफलता सह लेता है?

  • rf=3, min.insync.replicas=2, acks=all
  • rf=1, acks=1
  • rf=2, min.insync.replicas=2, acks=all
  • rf=3 के साथ acks=0
Answer

rf=3, min.insync.replicas=2, acks=all — तीन replicas में से दो in-sync ज़रूरी होने पर एक विफलता के बाद writes चलते हैं और डेटा दो brokers पर रहता है।

त्वरित जाँच: आप चाहते हैं कि record दो बार पहुँचे तो भी प्रोसेसिंग सुरक्षित रहे। आप क्या करते हैं?

  • ज़्यादा partitions जोड़ें
  • प्रोसेसिंग से पहले commit करें
  • Broker पर retries बंद करें
  • Handler को idempotent बनाएँ, जैसे अनोखी key से upsert
Answer

Handler को idempotent बनाएँ, जैसे अनोखी key से upsert — Idempotent handling दोहरा delivery हानिरहित बनाती है।