آموزش ۴۰۰ سوال مصاحبه کافکا (Kafka) به همراه پاسخ‌ها ۲۰۲۶ - آخرین آپدیت

با بیش از ۵۰۰ سوال تمرینی جامع، بر مفاهیم داخلی کافکا، تولیدکنندگان، مصرف‌کنندگان و Streams مسلط شوید.

دوره آمادگی مصاحبه و آزمون Apache Kafka برای توسعه‌دهندگان و معمارانی طراحی شده است که می‌خواهند از دانش سطحی فراتر رفته و اکوسیستم استریمینگ توزیع‌شده را به‌طور واقعی استاد شوند. من این دوره را ساختم زیرا متوجه کمبود منابع تمرینی باکیفیت و سناریومحور شدم که «چرا»ی هر پیکربندی را توضیح دهند. چه برای مصاحبه Big Data آماده می‌شوید و چه برای یک گواهینامه فنی، من بررسی‌های عمیقی روی موتور ذخیره‌سازی Log-structured، انتقال از ZooKeeper به KRaft و جزئیات Exactly-Once Semantics (EOS) ارائه می‌دهم. شما فقط پاسخ‌ها را حفظ نمی‌کنید؛ بلکه یاد می‌گیرید چگونه Producerها را برای عدم حذف داده تنظیم کنید، بازتعادل‌سازی گروه‌های مصرف‌کننده را مدیریت نمایید و خطوط لوله داده مقیاس‌پذیر را با Kafka Connect و KSQL طراحی کنید. هر سوال با یک توضیح جامع همراه است تا با اعتمادبه‌نفس کامل و آماده برای محیط عملیاتی (Production) وارد بازار کار شوید.

دامنه آزمون و مباحث نمونه

• معماری هسته: پارتیشن‌ها، ISRها، حالت KRaft و انتخابات لیدر.

• جزئیات کلاینت: Producerهای Idempotent، پارتیشن‌بندی Sticky و مدیریت Offset.

• اکوسیستم و یکپارچه‌سازی: Kafka Connect، رجیستری شمای داده (Avro/Protobuf) و SMTها.

• پردازش جریان: مقایسه KTables و KStreams، ذخیره‌سازهای وضعیت (State Stores) و Windowing.

• عملیات و امنیت: SASL/SSL، ACLها، مانیتورینگ JMX و عیب‌یابی Lag.

نمونه سوالات تمرینی

• سوال ۱: یک Producer با تنظیمات acks=all و min.insync.replicas=2 روی توپیکی با Replication Factor=3 پیکربندی شده است. اگر ناگهان دو بروکر آفلاین شوند، چه اتفاقی برای درخواست ارسال داده می‌افتد؟

  • الف) درخواست موفق می‌شود زیرا یک بروکر هنوز فعال است.

  • ب) درخواست با خطای NotEnoughReplicasException شکست می‌خورد.

  • ج) درخواست در Producer بافر می‌شود تا بروکر دوم بازگردد.

  • د) درخواست موفق می‌شود اما پیام به عنوان «Unclean» علامت‌گذاری می‌شود.

  • ه) درخواست فقط با خطای LeaderNotAvailableException شکست می‌خورد.

  • و) پارتیشن به طور خودکار وارد حالت «Read-Only» می‌شود.

  • پاسخ صحیح: ب

  • توضیح کلی: تنظیم min.insync.replicas حداقل تعداد رپلیکاهایی را تعیین می‌کند که باید در هنگام استفاده از acks=all، نوشتن داده را تایید کنند تا عملیات موفق شود.

  • تحلیل دقیق گزینه‌ها:

    • الف: نادرست؛ یک بروکر نیاز به ۲ رپلیکای همگام را برآورده نمی‌کند.

    • ب: صحیح؛ چون فقط ۱ بروکر فعال است، کافکا نمی‌تواند حداقل نیاز ۲ تایی را تامین کند و این استثنا رخ می‌دهد.

    • ج: نادرست؛ Producer بر اساس تنظیمات retries تلاش مجدد می‌کند، اما اگر وضعیت کلاستر تغییر نکند، در نهایت خطا می‌دهد.

    • د: نادرست؛ در این زمینه مفهومی به نام وضعیت پیام «Unclean» وجود ندارد.

    • ه: نادرست؛ حتی اگر لیدر در دسترس باشد، تعداد رپلیکاها عامل اصلی شکست در اینجا است.

    • و: نادرست؛ کافکا حالت بومی «Read-Only» برای پارتیشن ندارد و صرفاً درخواست‌های نوشتن را رد می‌کند.

• سوال ۲: در Kafka Streams، تفاوت اصلی بین KStream و KTable چیست؟

  • الف) KStreams در RocksDB ذخیره می‌شوند؛ KTables در RAM ذخیره می‌شوند.

  • ب) KStreams نماینده یک changelog هستند؛ KTables نماینده یک جریان رکورد.

  • ج) KStreams بدون وضعیت (Stateless) هستند؛ KTables همیشه دارای وضعیت (Stateful) هستند.

  • د) KStreams نماینده یک «جریان رکورد» هستند که هر نقطه داده یک درج (Insert) است؛ KTables نماینده یک «changelog» هستند که داده‌ها به صورت upsert عمل می‌کنند.

  • ه) KTables فقط با داده‌های JSON کار می‌کنند؛ KStreams از Avro پشتیبانی می‌کنند.

  • و) KStreams از Join پشتیبانی نمی‌کنند؛ KTables از تمامی انواع Join پشتیبانی می‌کنند.

  • پاسخ صحیح: د

  • توضیح کلی: این مفهوم «دوگانگی جریان-جدول» (Stream-Table Duality) است. KStreams با هر رکورد به عنوان یک رویداد مستقل برخورد می‌کند، در حالی که KTables با رکوردها به عنوان به‌روزرسانی برای یک مقدار کلیددار برخورد می‌کنند.

  • تحلیل دقیق گزینه‌ها:

    • الف: نادرست؛ هر دو می‌توانند از RocksDB برای مدیریت وضعیت استفاده کنند.

    • ب: نادرست؛ دقیقاً برعکس است.

    • ج: نادرست؛ KStreams می‌توانند در عملیات Stateful مانند Windowed Joins شرکت کنند.

    • د: صحیح؛ این گزینه به درستی تفاوت معنایی بین این دو انتزاع را توصیف می‌کند.

    • ه: نادرست؛ هر دو نسبت به فرمت داده مستقل هستند.

    • و: نادرست؛ KStreams از انواع مختلف Join (مانند Stream-Stream و Stream-Table) پشتیبانی می‌کنند.

• سوال ۳: کدام جزء مسئول مدیریت نگاشت پیکربندی‌های تسک Kafka Connect به Workerهای خاص در یک کلاستر توزیع‌شده است؟

  • الف) Schema Registry.

  • ب) Zookeeper Quorum.

  • ج) Connect Worker که به عنوان Leader/Coordinator عمل می‌کند.

  • د) Kafka Broker که به عنوان Controller عمل می‌کند.

  • ه) REST API Gateway.

  • و) نمونه‌های تکی Source Connector.

  • پاسخ صحیح: ج

  • توضیح کلی: در یک کلاستر توزیع‌شده Kafka Connect، ورکرها یک لیدر انتخاب می‌کنند که مسئول تخصیص کانکتورها و تسک‌ها بین ناوگان ورکرهای موجود است.

  • تحلیل دقیق گزینه‌ها:

    • الف: نادرست؛ Schema Registry فقط شمای داده‌ها را مدیریت می‌کند.

    • ب: نادرست؛ Connectهای مدرن برای هماهنگی از توپیک‌های داخلی کافکا استفاده می‌کنند، نه Zookeeper.

    • ج: صحیح؛ ورکر لیدر/هماهنگ‌کننده گروه، توزیع تسک‌ها را مدیریت می‌کند.

    • د: نادرست؛ Broker Controller لیدرهای پارتیشن را مدیریت می‌کند، نه تسک‌های Connect را.

    • ه: نادرست؛ REST API صرفاً رابطی برای ارسال درخواست‌هاست.

    • و: نادرست؛ خود کانکتور یک پیکربندی است، نه یک موجودیت مدیریتی.

• به بهترین آزمون‌های تمرینی برای آمادگی در مصاحبه و آزمون Apache Kafka خوش آمدید.

  • می‌توانید آزمون‌ها را هر چند بار که بخواهید تکرار کنید

  • این یک بانک سوالات جامع و اورجینال است

  • در صورت داشتن هرگونه سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید

  • هر سوال دارای یک توضیح مفصل است

  • سازگار با موبایل از طریق اپلیکیشن Udemy

  • ضمانت بازگشت وجه ۳۰ روزه در صورت عدم رضایت

امیدوارم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد. همین امروز ثبت‌نام کنید و آخرین قدم را برای دریافت مدرک خود بردارید!