بازگشت به کتابخانهکتابخانه17.7Case Study: صف پیام توزیع‌شده (Kafka خودش)
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 17.7فصل ۱۷Case Study های تکمیلی

Case Study: صف پیام توزیع‌شده (Kafka خودش)

  • ~۱۴ دقیقه
  • ۳ پرسش
  • متن را انتخاب کن تا هایلایت شود

مسئله: خود Kafka را طراحی کن — سیستمی که روزانه تریلیون‌ها پیام را با دوام، ترتیب و تأخیر میلی‌ثانیه‌ای جابه‌جا می‌کند. حالا که درس ۴۲ مصرفش را می‌دانی، وقت ساختنش است.

۱-۲) نیازمندی و تخمین

  • FR: producer بنویسد، consumer با ترتیب بخواند، چند مصرف‌کننده مستقل از یک داده (fan-out)، نگه‌داشت روزها.
  • NFR: throughput میلیون پیام/ثانیه، دوام در برابر مرگ دیسک/گره، تأخیر انتها‌به‌انتها <100ms.
  • تخمین: 1M msg/s × 1KB ≈ 1GB/s نوشتن و چند برابرش خواندن — دیسک sequential تنها راه زنده‌ماندن است.

۳) طراحی — همه‌چیز log است

بینش مرکزی: پیام را مثل صف «بخوان و حذف کن» نگهدار، مثل log فقط-الحاقی (درس ۱۲، همان WAL!) بنویس و به هر مصرف‌کننده اجازه بده با offset خودش بخواند. نوشتن = الحاق انتهای فایل (سریع‌ترین I/O دیسک)؛ خواندن = خواندن ترتیبی. حذف نه بر اساس مصرف که بر اساس زمان/حجم (retention) — همین یک تصمیم، fan-out نامحدود و replay را مجانی می‌کند.

DIAGRAMساختار Kafka
Producer — batch
Broker — پارتیشن = فایل الحاقی
Replica — Leader+Followers
Consumer Group — offset مشترک
(KRaft — متادیتا)
  • پارتیشن واحد مقیاس است: هر پارتیشن یک log مستقل روی یک گره؛ ترتیب فقط درون پارتیشن تضمان است — کلید پیام تعیین‌کننده پارتیشن (هش) پس کلید را بر اساس نیاز ترتیب انتخاب کن (user_id ،order_id).
  • دوام: هر پارتیشن r نسخه روی گره‌های مختلف؛ leader می‌نویسد، follower ها دنبال می‌کنند؛ acks=all یعنی فقط وقتی ack که ISR (نسخه‌های همگام) نوشته باشند — درس ۱۴ در عمل.
  • Consumer group: پارتیشن‌ها بین اعضای گروه تقسیم می‌شوند؛ offset مشترک در Kafka خودش ذخیره است — افزودن مصرف‌کننده = مقیاس خواندن، و rebalance هزینه‌اش است (درس ۴۲).
  • صفحه‌کش سیستم‌عامل: Kafka خودش کش نمی‌کند؛ page cache لینوکس + zero-copy (sendfile) خواندن را تقریباً رایگان می‌کند.

۴) عمق و گلوگاه

  • چرا نه RabbitMQ برای این حجم؟ مدل «تحویل هوشمند بروکر» (ردیابی هر پیام/مصرف‌کننده) در مقیاس تریلیونی نمی‌چرخد؛ Kafka بروکر را احمق و مصرف‌کننده را هوشمند کرد — دقیقاً معکوس.
  • ترتیب سراسری بین پارتیشن‌ها نداری — اگر لازم است (نادر)، یا یک پارتیشن (سقف throughput یک گره) یا ترتیب‌دهی در لایه کاربرد با sequence number.
  • KRaft جای ZooKeeper: متادیتای کلاستر خودش یک log داخلی با Raft (درس ۹) است — یک وابستگی کمتر، failover سریع‌تر.

به زبان ساده

Kafka خودش یک فایل بزرگ فقط-الحاقی است: نوشتن همیشه به ته فایل (سریع‌ترین کار دیسک)، خواندن با offset هر مصرف‌کننده، و مقیاس با تقسیم به پارتیشن.

مثال واقعی

مثل نوار کاغذی تلگراف قدیم: خبرها پشت سر هم به ته نوار اضافه می‌شوند؛ هر خواننده قلمی روی شماره‌ای که رسیده نگه می‌دارد و هر وقت خواست ادامه می‌دهد.

دانش‌سنجی

آزمون درس

۳ Q
01
چرا retention زمانی (نه بر اساس مصرف) انقلابی بود؟
02
تضمین ترتیب Kafka در چه سطحی است؟
03
چرا نوشتن Kafka روی دیسک چرخان هم سریع است؟