بررسی الگوریتم KRaft در کافکا

در نسخه‌های جدید Apache Kafka (از نسخه ۳ به بعد)، دیگر از ZooKeeper برای مدیریت و هماهنگی نودهای کلاستر استفاده نمی‌شود.
علت این تغییر، پیچیدگی، وابستگی زیاد و مشکلات هماهنگی بین Kafka و ZooKeeper بود.
به جای آن، Kafka حالا دارای یک لایه‌ی داخلی هماهنگی به نام KRaft (Kafka Raft Metadata Mode) است که خودش تمام کارهای مربوط به مدیریت متادیتا، هماهنگی نودها و انتخاب رهبر را انجام می‌دهد.

به عبارت ساده‌تر:
KRaft همان کاری را می‌کند که قبلاً ZooKeeper انجام می‌داد، اما حالا به‌صورت درون‌ساخت خود Kafka و بسیار بهینه‌تر.

---

🧩 معماری KRaft و نقش‌های آن

در معماری جدید KRaft، هر نود Kafka می‌تواند یکی از این سه نقش را داشته باشد:

1. 🧱 Broker (بروکر):
   • وظیفه‌اش ذخیره و ارسال پیام‌هاست.
   • ارتباط مستقیم با Producer (تولیدکننده) و Consumer (مصرف‌کننده) دارد.
   • داده‌ها (پیام‌ها) را نگه‌داری و بین نودها تکرار (replicate) می‌کند.
2. 🧠 Controller (کنترلر):
   • مسئول مدیریت و نگه‌داری metadata است.
   • تعیین می‌کند که کدام بروکرها فعال‌اند، رهبر هر پارتیشن چه کسی است، و اگر نودی از دسترس خارج شد چه اتفاقی بیفتد.
   • کنترلر مثل مغز کلاستر است.
3. 🧩 Combined Mode (ترکیبی):
   • در محیط‌های کوچک یا آزمایشی، یک نود می‌تواند هم کنترلر و هم بروکر باشد.
   • در محیط‌های تولیدی (production) توصیه می‌شود نقش کنترلرها از بروکرها جدا باشد.

---

⚙️ چرا به الگوریتم اجماع (Consensus) نیاز داریم؟

فرض کن چند نود (سرور) داریم و باید یکی از آن‌ها نقش رهبر را بر عهده گیرد. اگر دو سرور همزمان فکر کنند رهبر هستند، داده‌ها ناهماهنگ می‌شود و سیستم دچار خطا خواهد شد.

برای جلوگیری از این مشکل، ما نیاز به یک الگوریتم اجماع (Consensus Algorithm) داریم تا همه نودها بتوانند با هم توافق کنند که:

• چه کسی رهبر است؟
• آخرین وضعیت داده‌ها چیست؟
• تغییرات جدید چه زمانی معتبر می‌شود؟

Kafka برای این کار از الگوریتم Raft استفاده می‌کند — و در واقع نام KRaft از ترکیب Kafka + Raft گرفته شده است.

---

🔁 الگوریتم Raft در Kafka

الگوریتم Raft به‌صورت خلاصه تضمین می‌کند که همه‌ی نودها در مورد وضعیت متادیتا و رهبر، به توافق برسند.

در هر لحظه:

• یکی از کنترلرها نقش رهبر (Leader) را دارد.
• بقیه پیرو (Follower) هستند.
• اگر رهبر از دسترس خارج شود، پیروها با رأی‌گیری یک رهبر جدید انتخاب می‌کنند.

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

---

🕸️ ارتباط بین اجزای KRaft

بیایید ارتباط‌ها را مرحله‌به‌مرحله مرور کنیم 👇

۱. ارتباط بین کنترلرها (Controller-to-Controller)

در کلاستر، کنترلرها با هم یک Quorum تشکیل می‌دهند — یعنی گروهی از نودها که با هم در مورد متادیتا تصمیم می‌گیرند.

• یکی از آن‌ها به عنوان رهبر کنترلر (Controller Leader) انتخاب می‌شود.
• بقیه در نقش پیرو (Follower) هستند.
• رهبر تمام تغییرات متادیتا (مثل ایجاد تاپیک، حذف پارتیشن، وضعیت بروکرها و غیره) را ثبت می‌کند.
• پیروها این متادیتا را با مکانیزم Pull از رهبر دریافت می‌کنند تا همگام بمانند.

نکته مهم: در KRaft برخلاف تصور عمومی، رهبر اطلاعات را “push” نمی‌کند، بلکه نودهای دیگر اطلاعات را “pull” می‌کنند.

---

۲. ارتباط بین بروکر و کنترلر (Broker-to-Controller)

هر بروکر فقط با رهبر کنترلر ارتباط دارد. این ارتباط شامل چند بخش است:

• Heartbeat: بروکر هر چند ثانیه پیام heartbeat می‌فرستد تا نشان دهد در حال کار است.
• Metadata Updates: هر زمان که وضعیت تاپیک‌ها یا پارتیشن‌ها تغییر کند، بروکر از رهبر کنترلر آخرین متادیتا را می‌گیرد.
• Requests: اگر نیاز به انجام عملیاتی مثل ساخت تاپیک باشد، بروکر درخواست را برای کنترلر می‌فرستد تا تغییر متادیتا را اعمال کند.

---

۳. ارتباط بین بروکرها و کلاینت‌ها (Broker-to-Broker / Broker-to-Client)

• Replication بین بروکرها:
  هر پارتیشن در Kafka چند نسخه (Replica) دارد که بین بروکرها توزیع می‌شوند.
  بروکرهای پیرو داده را از بروکر رهبر به‌صورت Pull دریافت می‌کنند.
• ارتباط با Producer / Consumer:
  کلاینت‌ها مستقیماً به بروکرها وصل می‌شوند تا پیام ارسال یا دریافت کنند.
• ارتباط مدیریتی (Admin):
  اگر عملیاتی مثل ساخت تاپیک انجام شود، بروکر ابتدا آن را از سمت کلاینت می‌گیرد، سپس برای ثبت در متادیتا به رهبر کنترلر می‌فرستد.

---

💡 نکات کلیدی درباره KRaft

مورد	توضیح
🔹 ساختار Pull-driven	پیروها داده‌ها و متادیتا را از رهبر Pull می‌کنند
🔹 استقلال از ZooKeeper	تمام مدیریت متادیتا درون Kafka انجام می‌شود
🔹 Quorum Controller	برای اطمینان از صحت و پایداری تصمیمات
🔹 Heartbeat	کنترل سلامت و وضعیت نودها
🔹 Metadata Log	تمام اطلاعات مدیریتی به‌صورت لاگ مشابه داده‌ها ذخیره می‌شود

---

واکاوی الگوریتم Raft در انتخاب کنترلر اصلی Kafka

فرض کنید ما سه سرور داریم که هر سه نقش Controller را در یک کلاستر Kafka ایفا می‌کنند:

Controller-1     Controller-2     Controller-3

همه‌ی این سرورها اطلاعات متادیتا (مثل لیست تاپیک‌ها و پارتیشن‌ها) را در خود نگه می‌دارند، اما فقط یکی از آن‌ها باید رهبر (Leader) باشد — چون وجود چند رهبر باعث می‌شود داده‌ها ناسازگار شوند.

اینجاست که الگوریتم Raft وارد عمل می‌شود.

---

🧩 مرحله ۱: شروع (همه در حالت Follower)

وقتی کلاستر برای اولین بار بالا می‌آید، همه‌ی کنترلرها در حالت Follower (دنبال‌کننده) هستند.
هیچ‌کدام نمی‌داند رهبر کیست، و منتظرند از جایی پیامی دریافت کنند که بگوید “رهبر من هستم”.

اما چون هنوز هیچ رهبری وجود ندارد، بعد از مدت‌زمانی که به آن Election Timeout می‌گویند (مثلاً ۳۰۰ تا ۵۰۰ میلی‌ثانیه)، یکی از آن‌ها تصمیم می‌گیرد خودش کاندید (Candidate) شود.

---

🗳️ مرحله ۲: انتخابات (Election)

فرض کنیم Controller-2 زودتر از بقیه تایم‌اوتش تمام شده است.
او تصمیم می‌گیرد برای رهبر شدن کاندید شود.

در این حالت:

• Controller-2 مقدار term خود را افزایش می‌دهد (یعنی شماره‌ی دوره‌ی انتخاباتی جدید).
• برای بقیه کنترلرها (۱ و ۳) پیام RequestVote می‌فرستد و می‌گوید:
  «من می‌خواهم رهبر شوم، اگر موافقید به من رأی بدهید.»

---

📨 مرحله ۳: رأی‌گیری (Voting)

هر کدام از کنترلرهای دیگر (۱ و ۳) بررسی می‌کنند:

• آیا این درخواست از یک term جدیدتر آمده است؟
• آیا قبلاً در این term به کسی رأی داده‌اند؟

اگر پاسخ مثبت باشد و شرایط درست باشد، آن‌ها به Controller-2 رأی می‌دهند.

✅ در الگوریتم Raft، برای برنده شدن، کاندید باید اکثریت آرا (majority) را به‌دست آورد.
مثلاً در ۳ نود، باید حداقل ۲ رأی داشته باشد.

---

👑 مرحله ۴: انتخاب رهبر

وقتی Controller-2 دو رأی (از خودش و یکی از بقیه) می‌گیرد، اعلام می‌کند:
«من رهبر جدید هستم.»

از این لحظه به بعد:

• او Controller Leader است.
• بقیه نودها (۱ و ۳) دوباره به حالت Follower برمی‌گردند و از او پیروی می‌کنند.
• رهبر مسئول نگه‌داری و انتشار متادیتا در بین کنترلرها می‌شود.

---

🔁 مرحله ۵: هماهنگی و تکرار (Replication)

رهبر (Controller-2) حالا لاگ متادیتا را مدیریت می‌کند.
وقتی یک تغییر رخ می‌دهد — مثلاً ساخت یک Topic جدید — ابتدا رهبر آن را در لاگ خود می‌نویسد، سپس بقیه کنترلرها آن تغییر را از او pull می‌کنند تا لاگ‌شان هم همگام شود.

وقتی اکثریت کنترلرها تأیید کردند که این تغییر را ثبت کرده‌اند، رهبر می‌گوید:
«تغییر قطعی (Committed) شد.»

---

⚡ مرحله ۶: خرابی رهبر و انتخاب دوباره

اگر Controller-2 (رهبر فعلی) از کار بیفتد یا پاسخ ندهد:

• کنترلرهای پیرو متوجه می‌شوند که مدت زیادی است heartbeat از او نگرفته‌اند.
• دوباره انتخابات جدیدی آغاز می‌شود (همان مراحل قبل).
• یکی از بقیه کنترلرها (مثلاً Controller-1) کاندید می‌شود و با رأی اکثریت، رهبر جدید می‌شود.

به این ترتیب، سیستم همیشه یک رهبر فعال دارد و هیچ‌وقت بی‌رهبر نمی‌ماند.

---

🧠 جمع‌بندی ساده

مرحله	وضعیت
۱️⃣ همه Follower هستند	در انتظار پیام رهبر
۲️⃣ یک نفر Candidate می‌شود	درخواست رأی می‌دهد
۳️⃣ اکثریت رأی می‌دهند	رهبر جدید انتخاب می‌شود
۴️⃣ رهبر با heartbeat بقیه را هماهنگ نگه می‌دارد	پایداری برقرار می‌شود
۵️⃣ اگر رهبر از کار افتاد	انتخابات جدید برگزار می‌شود

---

🎯 مثال تصویری در ذهن

تصور کن سه نفر در یک گروه کاری هستند:
هرکدام منتظرند یکی مسئول شود. اگر کسی داوطلب شد و بقیه هم قبول کردند، او مدیر می‌شود.
مدیر مرتب به بقیه پیام می‌دهد (heartbeat) که “من هنوز اینجام و مدیریت را بر عهده دارم”.
اگر مدتی از او خبری نشود، دوباره رأی‌گیری می‌کنند تا مدیر جدید انتخاب شود.

Kafka هم دقیقاً با همین منطق کنترلر رهبر خود را انتخاب می‌کند.

🎯 جمع‌بندی

در معماری KRaft:

• کنترلرها وظیفه‌ی هماهنگی و مدیریت متادیتا را بر عهده دارند.
• بروکرها پیام‌ها را ذخیره و بین کلاینت‌ها توزیع می‌کنند.
• همه چیز بر پایه‌ی الگوریتم Raft پیش می‌رود تا سیستم همیشه سازگار و پایدار بماند.

اگر بخواهیم این ساختار را با مثالی انسانی توضیح دهیم:

کنترلر رهبر مثل مدیر اصلی شرکت است، کنترلرهای پیرو مثل معاونان او هستند که اطلاعات را مرتب از مدیر می‌گیرند، و بروکرها مثل شعبه‌های شرکت‌اند که مستقیم با مشتریان (Producer و Consumer) در ارتباط‌اند.