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

پوشش جامع حوزه‌های آزمون

این مخزن تست‌های تمرینی دقیقاً برای شبیه‌سازی توزیع فنی و پیچیدگی‌های موجود در مصاحبه‌های سطح سازمانی Apache Kafka، مهندسی داده و سیستم‌های توزیع‌شده طراحی شده است.

• مبانی کافکا (۱۳٪): معماری هسته کافکا، اجزای اکوسیستم، توپولوژی‌های بروکر پیام، موارد استفاده از استریمینگ داده‌های بلادرنگ و مزایای جداسازی (Decoupling).

• APIهای Producer و Consumer کافکا (۲۰٪): ارسال‌های همزمان در مقابل ناهمزمان، انواع فشرده‌سازی، معناشناسی تحویل (at-least-once, at-most-once, exactly-once)، گروه‌های مصرف‌کننده، پروتکل‌های Rebalancing و مدیریت پیشرفته خطاها.

• پارتیشن‌بندی و تکثیر در کافکا (۱۸٪): استراتژی‌های پارتیشن‌بندی سفارشی، بخش‌بندی لاگ، مکانیسم‌های فاکتور تکثیر (Replication Factor)، لیست‌های ISR و سناریوهای انتخاب لیدر در شرایط خرابی.

• مدیریت کلاستر کافکا (۱۲٪): عملیات بروکر، خطوط پایه پیکربندی کلاستر، حالت Kraft در مقابل هماهنگی ZooKeeper، ارتقاهای تدریجی (Rolling Upgrades)، مقیاس‌پذیری پویا و Mirroring چند کلاستری.

• تنظیم عملکرد و بهینه‌سازی کافکا (۱۰٪): ایجاد تعادل بین نرخ انتقال (Throughput) و تأخیر، تنظیم Buffer Pool، بهینه‌سازی اندازه Batch، پیکربندی Socket Buffer و رفع گلوگاه‌های I/O دیسک/شبکه.

• امنیت و احراز هویت کافکا (۸٪): رمزنگاری لایه انتقال (TLS/SSL)، مکانیسم‌های SASL (مانند SCRAM, GSSAPI, OAUTHBEARER)، قوانین مجوز ACL و ارتباطات امن بین بروکرها.

• یکپارچه‌سازی و مباحث پیشرفته کافکا (۱۲٪): فریم‌ورک Kafka Connect (معماری Source و Sink)، توپولوژی‌های Kafka Streams API، پردازش Stateful در مقابل Stateless، پیاده‌سازی Schema Registry و استقرار در مقیاس بزرگ در چندین منطقه.

• عیب‌یابی و نگهداری کافکا (۷٪): دیباگ کردن صف‌های Dead-letter، تحلیل لاگ‌های بروکر و Garbage Collection، رفع مشکل گروه‌های Consumer متوقف شده و جریان‌های کاری نگهداری سلامت کلاستر.

درباره این دوره

قبولی در مصاحبه برای نقش‌های مهندس کافکا، مهندس ارشد داده یا معمار سیستم‌های توزیع‌شده نیازمند درک مکانیکی و عمیق از نحوه جریان داده در کلاستر است. مصاحبه‌کنندگان فقط نمی‌پرسند تاپیک چیست؛ بلکه شما را در موارد خاص دنیای واقعی می‌سنجند: مانند Rebalance گروه‌های مصرف‌کننده در ترافیک بالا، سناریوهای از دست رفتن داده هنگام خرابی بروکر و تنظیم دقیق پارامترهای Batch برای بهینه‌سازی سربار شبکه. من این بانک سوالات جامع را توسعه دادم تا دانش شما را در معرض همین فشارهای واقعی قرار دهم.

این دوره با دارا بودن ۵۵۰ سوال تمرینی بسیار دقیق و اورجینال، از تعاریف سطحی دوری می‌کند. در عوض، من بر توازن‌های معماری، تله‌های پیکربندی و سناریوهای دیباگی تمرکز کرده‌ام که مهندسان ارشد در سیستم‌های عملیاتی با آن‌ها مواجه می‌شوند. هر سوال شامل یک تحلیل خط‌به‌خط جامع است که توضیح می‌دهد نه تنها چرا گزینه صحیح درست است، بلکه از نظر ساختاری چرا پیکربندی‌های جایگزین و انتخاب‌های معماری دیگر شکست می‌خورند. چه برای یک نقش مهندسی نرم‌افزار با درآمد بالا آماده می‌شوید، چه به دنبال مقیاس‌بندی یک خط لوله پردازش استریم هستید و چه می‌خواهید مهارت‌های طراحی سیستم خود را پیش از یک مصاحبه پانل اعتبارسنجی کنید، این مخزن آمادگی دقیق و سخت‌گیرانه‌ای را فراهم می‌کند که برای عبور از مراحل فنی در اولین تلاش نیاز دارید.

پیش‌نمایش نمونه سوالات تمرینی

برای ارزیابی عمق فنی و سبک آموزشی توضیحات موجود در این بانک سوالات، لطفاً این سه نمونه سوال را بررسی کنید.

سوال ۱: تحلیل Rebalance گروه‌های Consumer و پیکربندی‌های Session Timeout

یک گروه مصرف‌کننده با نرخ انتقال بالا، دچار Rebalanceهای مکرر و زنجیره‌ای می‌شود، در حالی که اپلیکیشن‌های مصرف‌کننده از نظر ساختاری سالم هستند و در حال اجرا می‌باشند. با بررسی متریک‌ها، متوجه می‌شوید که پردازش یک Batch از رکوردها گاهی اوقات به دلیل عملیات سنگین دیتابیس در پایین‌دست، بیشتر از حد انتظار زمان می‌برد. کدام تنظیمات پیکربندی مستقیماً این مشکل را بدون پنهان کردن کرش‌های واقعی اپلیکیشن حل می‌کند؟

• الف) افزایش شدید مقدار session.timeout.ms در حالی که max.poll.interval.ms کاملاً بدون تغییر بماند.

• ب) کاهش تنظیم max.poll.records و افزایش آستانه پیکربندی max.poll.interval.ms.

• ج) افزایش پارامتر heartbeat.interval.ms به بیش از مقدار آستانه session.timeout.ms تعریف شده.

• د) تغییر پارامتر استراتژی تخصیص مصرف‌کننده از Cooperative Sticky به مدل سنتی Range Assignor.

• ه) کاهش تعداد فیزیکی پارتیشن‌های تخصیص یافته به تاپیک برای مجبور کردن مصرف‌کنندگان کمتر به استخر.

• و) تنظیم enable.auto.commit روی false و اجرای Commitهای همزمان دستی بلافاصله در حلقه پردازش.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: در مصرف‌کنندگان مدرن کافکا، Heartbeatها (که مصرف‌کننده را در گروه زنده نگه می‌دارند) در یک رشته پس‌زمینه جداگانه مدیریت می‌شوند که توسط session.timeout.ms کنترل می‌شود. اما اگر رشته پردازش اصلی زمان زیادی برای پردازش یک Batch رکورد بازگشتی از یک فراخوانی .poll() صرف کند، فراخوانی poll بعدی را از دست می‌دهد. کافکا از max.poll.interval.ms به عنوان تشخیص‌دهنده زنده بودن حلقه پردازش استفاده می‌کند. اگر این فاصله exceeded شود، Coordinator مصرف‌کننده را بیرون می‌اندازد و باعث Rebalance می‌شود. کاهش max.poll.records باعث ایجاد Batchهای کوچک‌تر می‌شود که سریع‌تر پردازش می‌شوند، در حالی که افزایش max.poll.interval.ms زمان بیشتری به رشته برای تکمیل عملیات سنگین می‌دهد.

• دلیل نادرست بودن گزینه‌های دیگر:

• گزینه الف نادرست است: افزایش session.timeout.ms تنها زمانی کمک می‌کند که رشته Heartbeat پس‌زمینه شکست بخورد، نه زمانی که خود حلقه پردازش متوقف شده باشد.

• گزینه ج نادرست است: مقدار heartbeat.interval.ms همیشه باید کمتر از session.timeout.ms باشد (معمولاً یک‌سوم آن)؛ تنظیم آن بالاتر از این مقدار یک پیکربندی نامعتبر است.

• گزینه د نادرست است: Cooperative Sticky Assignor در واقع اختلالات Rebalance را در مقایسه با Range Assignor به حداقل می‌رساند؛ بازگشت به Range شوک عملکردی را بدتر می‌کند.

• گزینه ه نادرست است: تغییر تعداد پارتیشن‌ها، عدم تطابق بین زمان پردازش و فواصل poll را در مصرف‌کنندگان فعال حل نمی‌کند.

• گزینه و نادرست است: تغییر سبک‌های Commit، تضمین‌های تحویل را تغییر می‌دهد اما تأثیری بر Timeoutهای Coordinator گروه که فواصل poll را مدیریت می‌کنند، ندارد.

سوال ۲: ارزیابی دوام داده‌ها و پیکربندی‌های Producer Acks

یک مهندس داده یک تاپیک کافکا در سطح سازمانی با Replication Factor برابر با ۳ ایجاد می‌کند و پیکربندی min.insync.replicas را در سطح تاپیک روی ۲ قرار می‌دهد. Producer با تنظیم acks=all پیکربندی شده است. اگر دو مورد از سه بروکر میزبان رپلیکاهای فعال برای یک پارتیشن خاص ناگهان دچار خرابی سخت‌افزاری شده و آفلاین شوند، Producer در تلاش‌های نوشتن بعدی چه رفتاری خواهد داشت؟

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

• ب) Coordinator کلاستر بلافاصله یک Follower در یک نود سالم را انتخاب کرده و بدون قطع اتصال، آن را به لیدر ارتقا می‌دهد.

• ج) Producer خطای NotEnoughReplicasException یا NotEnoughReplicasAfterAppendException دریافت می‌کند و عملیات نوشتن با شکست مواجه می‌شود.

• د) عملیات نوشتن با موفقیت اجرا می‌شود، اما بروکر مجبور می‌شود فاکتور تکثیر جهانی تاپیک را فوراً به ۱ کاهش دهد.

• ه) بروکر وارد حالت Read-only شده و محموله‌های ورودی Producer را کاملاً در بلوک‌های کش حافظه OS بافر می‌کند.

• و) Producer به طور خودکار به یک صف جایگزین ناهمزمان سوئیچ می‌کند و تا زمان فعال شدن بروکر، آن را کاملاً دور می‌زند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل صحت: وقتی Producer از acks=all (یا acks=-1) استفاده می‌کند، کافکا نیاز دارد که بروکر لیدر، تاییدیه (Acknowledgment) را از تعداد کل رپلیکاهای In-sync مشخص شده در تنظیم min.insync.replicas دریافت کند تا نوشتن موفقیت‌آمیز را تایید کند. از آنجایی که Replication Factor برابر با ۳ است و دو بروکر از بین رفته‌اند، تنها ۱ رپلیکا (لیدر) زنده مانده است. چون ۱ کمتر از حداقل مورد نیاز (۲) است، بروکر لیدر درخواست نوشتن را رد کرده و خطای NotEnoughReplicasException را به کلاینت Producer بازمی‌گرداند تا تضمین‌های دوام داده‌ها (Data Durability) حفظ شود.

• دلیل نادرست بودن گزینه‌های دیگر:

• گزینه الف نادرست است: بروکر نمی‌تواند تحت سیاست acks=all نوشتن را بپذیرد اگر شرط حداقل تعداد رپلیکاهای In-sync نقض شده باشد.

• گزینه ب نادرست است: هیچ رپلیکای بازمانده دیگری برای ارتقا وجود ندارد؛ هر دو Follower آفلاین هستند و فقط لیدر ایزوله باقی مانده است.

• گزینه د نادرست است: کافکا هرگز به طور خودکار لایه متاداده‌ها را تغییر نمی‌دهد یا پیکربندی Replication Factor را به دلیل خرابی‌های زیرساختی کاهش نمی‌دهد.

• گزینه ه نادرست است: بروکر رکوردهای تایید نشده را در صورت شکست آستانه‌های دوام، در یک بافر حافظه موقت سیستم کش نمی‌کند.

• گزینه و نادرست است: Producerهای سمت کلاینت دارای صف‌های داخلی مستقل خودکار برای ذخیره رکوردها خارج از مرزهای کلاستر در زمان رد شدن صریح درخواست‌های نوشتن نیستند.

سوال ۳: مدیریت State Store و تنظیم حافظه در معماری Kafka Streams

یک اپلیکیشن Stateful در Kafka Streams که از عملیات Join در KTable استفاده می‌کند، در جریان‌های بلادرنگ با حجم بالا، دچار Thrashing شدید I/O دیسک و افت عملکرد می‌شود. تحلیل‌ها نشان می‌دهد که نمونه‌های جاسازی شده RocksDB مکرراً بلوک‌های کوچک داده را در فایل‌های فیزیکی دیسک Flush می‌کنند. کدام رویکرد بهینه‌سازی، نرخ انتقال اپلیکیشن را به طور بهینه مقیاس می‌بندد؟

• الف) افزایش پارامتر statestore.cache.max.bytes در ویژگی‌های جریان پیکربندی اپلیکیشن.

• ب) تغییر ساختار توپولوژی کافکا برای جایگزینی کامل KTable (وضعیت‌دار) با یک تنظیمات KStream mapping (بدون وضعیت).

• ج) اجبار به تغییر جهانی کلاستر برای غیرفعال کردن تاپیک Changelog که توسط موتور وضعیت داخلی استریم پشتیبانی می‌شود.

• د) کاهش اندازه Heap در JVM اپلیکیشن برای اجازه دادن به مدیریت حافظه مجازی OS جهت Page-out کردن بلوک‌های فعال فیزیکی.

• ه) قرار دادن منطق پردازش در یک Partitioner سفارشی برای تخصیص کلیدهای تصادفی به هر محموله رکورد ورودی.

• و) کاهش آستانه اندازه Log Segment در تاپیک‌های استریم منبع اصلی برای اجبار به پاکسازی فوری در پس‌زمینه.

پاسخ صحیح و توضیح:

• پاسخ صحیح: الف

• دلیل صحت: Kafka Streams از یک لایه کش داخلی با پشتیبانی حافظه استفاده می‌کند که درست بالای State Store فیزیکی و محلی RocksDB قرار دارد. افزایش statestore.cache.max.bytes به Kafka Streams اجازه می‌دهد تا تغییرات وضعیت، تجمیع‌ها (Aggregations) و به‌روزرسانی‌های بیشتری را مستقیماً در حافظه سیستم بافر کند. این کار به طور قابل توجهی دفعات عملیات نوشتن گران‌قیمت در نمونه محلی RocksDB را کاهش داده، Thrashing دیسک فیزیکی را کم می‌کند و نرخ انتقال اپلیکیشن را پایدار می‌سازد.

• دلیل نادرست بودن گزینه‌های دیگر:

• گزینه ب نادرست است: اگرچه جایگزینی عملیات Stateful با Stateless وابستگی به دیسک را از بین می‌برد، اما منطق بنیادی اپلیکیشن را تغییر می‌دهد؛ شما نمی‌توانید بدون مدیریت وضعیت، عملیات Join را انجام دهید.

• گزینه ج نادرست است: غیرفعال کردن تاپیک Changelog، تحمل خطای سیستم (Fault Tolerance) را از بین می‌برد، به این معنی که اگر نمونه استریم کرش کند، State Store نمی‌تواند خود را بازسازی کند.

• گزینه د نادرست است: کوچک کردن فضای Heap در JVM سرعت اجرا را کاهش داده و در صورتی که اپلیکیشن به ساختارهای ردیابی گسترده نیاز داشته باشد، ریسک خطاهای OutOfMemory را افزایش می‌دهد.

• گزینه ه نادرست است: تصادفی کردن کلیدهای رکورد، قوانین Co-partitioning مبتنی بر کلید را که برای Streaming Joins ضروری هستند می‌شکند و باعث جستجوهای داده فاسد می‌شود.

• گزینه و نادرست است: تنظیم اندازه Log Segment در تاپیک‌های منبع بر نگهداری فضای دیسک تأثیر می‌گذارد، اما اصطکاک کش حافظه در موتور زمان اجرای محلی RocksDB را حل نمی‌کند.

چه انتظاراتی داشته باشید

• به تست‌های سوالات مصاحبه خوش آمدید تا شما را برای ارزیابی سوالات مصاحبه کافکا آماده کنیم.

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

• این یک بانک سوالات بسیار بزرگ و اورجینال است.

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

• هر سوال دارای یک توضیح دقیق است.

• با اپلیکیشن Udemy سازگار و در موبایل قابل استفاده است.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.