معرفی سیستم آپاچی کافکا (Apache Kafka)

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

کافکا (Kafka) چیست؟ 

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

بیشتر بخوانید: مقایسه RabbitMQ و Kafka

تاریخچه Kafka

پروژه کافکا در ابتدا توسط LinkedIn آغاز شد و سپس مراحل رشد و توسعه را طبق روند زیر طی کرد:

۲۰۱۰: توسعه توسط لینکدین

Kafka ابتدا به عنوان یک سیستم پیام‌رسانی توزیع‌شده توسط LinkedIn توسعه یافت تا حجم عظیمی از داده‌های تولید شده توسط این پلتفرم را مدیریت کند.

۲۰۱۱: منبع‌باز کردن

LinkedIn در سال ۲۰۱۱، Kafka را اوپن‌سورس و آن را به پروژه Apache Software Foundation اهدا کرد. این اقدام، دسترسی و امکان مشارکت در پروژه را برای جامعه گسترده‌ای از توسعه‌دهندگان، فراهم کرد.

۲۰۱۲: تبدیل شدن به پروژه اصلی

Kafka در سال ۲۰۱۲ به پروژه اصلی Apache تبدیل شد. این اتفاق، نشان از رشد و پذیرش آپاچی کافکا در جامعه Open Source بود.

۲۰۱۳: نسخه ۰.۸.۰

عرضه نسخه ۰.۸.۰ Kafka که با معرفی بهبودهای متعددی همراه بود، نقطه عطف مهمی را رقم زد و به این ترتیب موقعیت Kafka به عنوان یک سیستم پیام‌رسانی توزیع‌شده قوی را تثبیت کرد.

۲۰۱۴-۲۰۱۵: پذیرش گسترده‌تر

Kafka به عنوان یک پلتفرم مناسب برای استریمینگ داده‌های Realtime، پردازش رویدادها و جمع‌آوری لاگ، در صنایع مختلف گسترش یافت.

۲۰۱۴: تاسیس Confluent

در سال ۲۰۱۴، برخی از توسعه‌دهندگان اصلی Kafka شرکت Confluent را تاسیس کردند. هدف از تاسیس این شرکت، ارائه راهکارهای تخصصی و خدمات کسب و کاری در زمینه Kafka بود.

۲۰۱۶: معرفی Kafka Streams

کتابخانه پردازش استریم Kafka Streams در نسخه ۰.۱۰.۰ معرفی شد که ابزار مناسبی برای ساخت برنامه‌های پردازش استریم مقیاس‌پذیر و مقاوم در برابر خطا برای توسعه‌دهندگان بود.

۲۰۱۷: نسخه ۱.۰.۰

در نوامبر ۲۰۱۷، Kafka به نسخه ۱.۰.۰ رسید، که تاییدی بر پایداری و ارتقای پلتفرم بود.

اجزای Apache Kafka

در این بخش به بررسی اجزای مختلف کافکا می‌پردازیم.

۱. تاپیک‌ها (Topics)

تاپیک‌ها در Apache Kafka به عنوان کانال‌هایی برای ارسال و دریافت داده‌ها تعریف می‌شوند.

• هر تاپیک در Kafka یک نام دارد. این نام، مشخص کننده یک جریان اطلاعات مشخص است.
  تاپیک‌ها می‌توانند با دسته‌بندی مختلف و یا مشابه برای داده‌ها عمل کنند. برای مثال، یک تاپیک می‌تواند برای داده‌های مربوط به لاگ‌ها، تاپیک دیگر برای رویدادهای کاربران، و غیره تعریف شود.
• تاپیک‌ها می‌توانند پیکربندی شوند تا پیغام‌ها را برای مدت زمان مشخصی نگهداری کنند. این قابلیت، تحلیل و بازیابی داده‌ها را در طول زمان ممکن می‌سازد.
• هر تاپیک در آپاچی کافکا به چندین بخش کوچک‌تر به نام پارتیشن تقسیم می‌شود. پارتیشن‌ها مانند بخش‌های مستقل عمل می‌کنند که اطلاعات را درون خود ذخیره می‌کنند؛ به این ترتیب هر تاپیک را می‌توان برای چندین موضوع مورد استفاده قرار داد.
• تاپیک‌ها می‌توانند تعداد پارتیشن‌های خود را به صورت پویا افزایش یا کاهش دهند بدون آنکه نقصی در عملکرد ایجاد شود.
• در هریک از این پارتیشن‌ها پیغام‌ها از اولین تا آخرین پیغام به ترتیب زمان تولید (timestamp) آن‌ها قرار می‌گیرند.
• هر پیغامی که وارد تاپیک می‌شود، یک کلید شامل اطلاعات تشخیصی مربوط به پارتیشن‌بندی خود را دارد. در نتیجه ترتیب و محل ذخیره‌سازی دقیق پیام‌ها قابل تشخیص خواهد بود.

۲. تولیدکننده (Producer)

تولیدکننده‌ها در Apache Kafka مسئول ارسال داده‌ها (به صورت پیام) به تاپیک‌ها هستند. تولیدکننده‌ها می‌توانند داده‌ها را به صورت دسته‌بندی‌شده و ساختارمند به تاپیک‌ها ارسال کنند.

۳. مصرف‌کننده (Consumer)

به عنوان گیرندگان داده‌ها عمل می‌کنند. داده‌ها را از تاپیک‌ها دریافت می‌کنند و می‌توانند آن‌ها را برای پردازش‌های مختلف مورد استفاده قرار دهند. هر مصرف‌کننده می‌تواند پیام‌های موجود در یک یا چند تاپیک داده را پردازش کند.

۴. بروکرها (Brokers)

بروکرها سرورهایی در مرکز معماری سیستم کافکا هستند که مسئولیت ذخیره و مدیریت پیام‌ها در تاپیک‌ها را بر عهده دارند؛ به این معنا که داده‌های ارسالی توسط تولیدکننده‌ها را در تاپیک‌ها ذخیره کرده و به درخواست مصرف‌کننده‌ها در خصوص دریافت داده‌ها پاسخ می‌دهند. همچنین به منظور ایجاد قابلیت پیگیری و تحلیل عملکرد سیستم، لاگ‌های ترافیک داده‌ها و عملکرد سیستم را نگهداری می‌کنند. کافکا از سرویس ZooKeeper جهت مدیریت متناسب بروکرها و همینطور ایجاد هماهنگی میان آن‌ها استفاده می‌کند.

• بروکرها بر روی چندین سرور قرار گرفته و توانایی تقسیم بار (Load Balancing) را دارند. به این ترتیب پیغام‌ها بین بروکرها توزیع شده و به نسبت مساوی بین بروکرها تقسیم می‌شوند.
• هر بروکر مستقل از سایر بروکرها عمل می‌کند.
• در هر بروکر می‌توان به ازای هر پارتیشن موجود در تاپیک، چندین نسخه پشتیبان (Replica) نگهداری کرد.

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

۵. آفست (Offset)

آفست مفهومی است برای جلوگیری از مصرف تکراری پیام‌ها در یک گروه مصرف‌کننده. در واقع مکانیزمی است که نشان می‌دهد یک مصرف‌کننده تا کجا پیام‌ها را خوانده و پردازش کرده است. هر بار که یک مصرف‌کننده یک پیام را مصرف می‌کند، Offset به‌روزرسانی می‌شود.

بیشتر بخوانید: معماری میکروسرویس چیست؟

مفهوم Offset به ازای هر تاپیک و گروه مصرف‌کنندگان (consumer group) نگهداری می‌شود. به این ترتیب، هر گروه مصرف‌کننده می‌داند که از کجا پیام‌ها را خوانده و کدام پیام‌ها هنوز خوانده نشده‌اند. به عبارت دیگر، هر Consumer با استفاده از Offset، این امکان را دارد تا از پیام‌هایی که قبلا خوانده‌ عبور کرده و فقط پیام‌های جدید را بخواند.

۶. گروه‌های مصرف‌کننده (Consumer Groups)

ابزاری است متشکل از یک یا چند مصرف‌کننده که امکان توزیع پیغام‌های یک تاپیک بین چند مصرف‌کننده را به منظور موازی‌سازی پردازش پیغام‌ها فراهم می‌کند؛ به این ترتیب این ابزار، منجر به افزایش مقیاس‌پذیری و اطمینان از دسترسی به پیغام‌ها می‌شود.

• هر پارتیشن تاپیک، می‌تواند به چندین گروه مصرف‌کننده تعلق داشته باشد. به این ویژگی (MultipleConsumer) گفته می‌شود.

• در یک گروه مصرف‌کننده، هر مصرف‌کننده پیغام‌های موجود در یک تاپیک و یک پارتیشن را در اختیار دارد. هر پیغام تنها یک بار در اختیار یک گروه مصرف‌کننده قرار می‌گیرد و این مکانیزم مطمئن می‌شود که پیغام‌ها به تعداد مصرف‌کنندگان تکرار نمی‌شوند.
• با افزایش تعداد Consumerها در یک گروه، مقیاس‌پذیری افزایش می‌یابد. هر Consumer می‌تواند بر روی پارتیشن‌های مختلف پردازش انجام دهد و این امکان به سادگی افزایش دوام و توانمندی سیستم را فراهم می‌کند.
• در صورت استفاده از گروه‌های مصرف‌کننده، Apache Kafka از یک مفهوم پیشرفته به نام Consumer Lag به منظور نظارت بر پیشرفت Consumer‌ها و اطمینان از دسترسی به تمام دادها در تاپیک‌ها استفاده می‌کند.

نحوه محاسبه Consumer Lag

این مقدار برابر است با تفاوت آخرین Offset در یک پارتیشن و آخرین Offset مصرف شده توسط Consumer.

برای مثال، فرض کنید یک مصرف‌کننده در یک گروه مصرف‌کننده، متوجه می‌شود که Consumer Lag برابر با ۱۰ پیغام است. این به این معناست که مصرف‌کننده تاکنون ۱۰ پیغام از یک پارتیشن خاص تاخیر دارد و به آخرین پیغام ارسال شده نرسیده است. این اطلاعات از این جهت مفیدند که به مصرف‌کننده این امکان را می‌دهند تا اقدامات مناسبی را برای افزایش سرعت پردازش یا تخصیص منابع انجام دهد.

نکته: در صورت افزایش تعداد پارتیشن‌ها یا کاهش تعداد گروه‌های مصرف‌کننده، Apache Kafka به صورت خودکار پارتیشن‌ها را میان گروه‌های مصرف‌کننده توزیع می‌کند.

۷. ZooKeeper

ZooKeeper نقش مهمی در مدیریت و هماهنگی بین اجزای مختلف سیستم کافکا را بر عهده دارد:

• مدیریت بروکرها

مسئولیت مدیریت بروکرها با ZooKeeper است و زمانیکه یک بروکر به سیستم اضافه یا از سیستم حذف می‌شود، اطلاعات مربوط به این تغییرات شامل مشخصات بروکرها و وضعیت آن‌ها، در ZooKeeper نگهداری می‌شود.

• هماهنگی بین Consumer‌ها

زوکیپر با مدیریت Offsetها، این اطمینان را می‌دهد تا همه مصرف‌کننده‌ها با یکدیگر به صورت همگام عمل کنند.

• نگهداری MetaData

اطلاعاتی همچون تعداد پارتیشن‌ها و موقعیت آن‌ها در بروکرها و همچنین مشخصات تاپیک‌ها، در ZooKeeper نگهداری می‌شود که این اطلاعات در فرایند درخواست و ارسال داده‌های مورد نیاز Consumer‌ها و تولیدکننده‌ها است.

• توزیع بار

با کمک اطلاعاتی که در ZooKeeper از وضعیت سیستم موجود است، می‌توان نسبت به توزیع بار متناسب بر روی بروکرها بر اساس ظرفیت و وضعیت آن‌ها اقدام نمود. این توزیع بار بر اساس اطلاعات موجود در ZooKeeper و  توسط کلاینت‌های کافکا صورت می‌گیرد.

• Locks

به منظور جلوگیری از concurrency در تغییرات، از مکانیزم Locks بهره می‌برد. به این ترتیب که وقتی یک Thread یا Process یک قفل می‌شود، سایر Thread‌ها تا زمان آزاد شدن Thread قفل شده امکان دسترسی به آن را ندارند.

نحوه عملکرد آپاچی کافکا

برای درک بهتر نحوه عملکرد کافکا، در زیر چند سناریو ساده را به عنوان مثال ارائه می‌دهیم:

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

استفاده از Apache Kafka برای ارسال ایونت‌های تغییرات در بین چندین ماژول، یکی از مصارف شایع و کاربردی این سیستم است.

نحوه عملکرد Apache Kafka برای ارسال ایونت‌های تغییرات

۱. برای هر نوع ایونت یا گروه ایونت‌ها، یک یا چند تاپیک در Kafka تعریف می‌شود. به عنوان مثال، یک تاپیک ممکن است برای ایونت‌های مربوط به سفارشات، یک تاپیک دیگر برای ایونت‌های مربوط به پرداخت‌ها و … باشد.

۲. در هر ماژول یا سرویس که تغییرات را ایجاد می‌کند، یک تولیدکننده ایجاد می‌شود. این تولیدکننده مسئول ارسال ایونت‌ها به تاپیک‌های مربوط به تغییرات است. برای مثال، وقتی یک سفارش جدید ایجاد می‌شود، تولیدکننده می‌تواند یک ایونت مربوط به آن سفارش را به تاپیک “OrderEvents” ارسال کند.

۳. مسئولیت مدیریت ایونت‌ها در تاپیک‌ها و انتقال آن‌ها به مصرف‌کننده‌ها با بروکرها است.

۴. در هر ماژول یا سرویسی که نیاز به استفاده از ایونت‌ها دارد، یک یا چند مصرف‌کننده ایجاد می‌شود که به تاپیک‌های مربوط به ایونت‌های مورد نیاز متصل می‌شوند و ایونت‌ها را دریافت می‌کنند.

۵. اگر بیش از یک مصرف‌کننده در یک ماژول یا یک گروه ایجاد شود، آن‌ها می‌توانند به صورت موازی ایونت‌ها را پردازش کنند.

با این سناریو، هر ماژول یا سرویس می‌تواند تغییرات خود را به صورت ایونت‌ها اعلام کرده و ماژول‌های دیگر می‌توانند این تغییرات را  دریافت کنند. این سیستم توزیع شده و ایونت‌گرا به توسعه‌دهندگان این امکان را می‌دهد که سیستم‌های بزرگ و پیچیده را با اطمینان بالا و قابلیت مقیاس‌پذیری بهبود دهند.

سیستم لاگ‌ها

سناریوی دیگری که به عنوان تست برای تشریح عملکرد کافکا بررسی می‌کنیم، سیستم لاگ است. فرض کنید یک سیستم بزرگ داریم که لاگ‌هایی از فعالیت‌های کاربران را ثبت می‌کند. می‌خواهیم از Apache Kafka برای جمع‌آوری، انتقال، و پردازش این لاگ‌ها استفاده کنیم.

۱. ابتدا یک تاپیک به نام «Logs» در Kafka ایجاد می‌کنیم. این تاپیک برای ذخیره لاگ‌ها و اطلاعات مربوط به فعالیت‌های کاربران استفاده می‌شود.

۲. یک تولیدکننده ایجاد می‌کنیم که مسئول ارسال لاگ‌ها به تاپیک «Logs» است. هر بار که یک کاربر وارد سیستم می‌شود یا یک عملیات انجام می‌دهد، تولیدکننده اطلاعات مربوط به این فعالیت را به تاپیک ارسال می‌کند.

۳. چندین بروکر Kafka وجود دارد که مسئول ذخیره لاگ‌ها و مدیریت ارتباطات بین تولیدکننده و مصرف‌کننده هستند.

۴. حالا یک یا چند مصرف‌کننده، ایجاد می‌کنیم که به تاپیک «Logs» متصل می‌شوند و لاگ‌ها را دریافت می‌کنند.

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

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

مزایا و کاربردها

مجموعه مزایایی که Apache Kafka را به یک گزینه محبوب برای ایجاد ساختارهای استریمینگ داده در معماری‌های توزیع‌پذیر تبدیل می‌کند عبارتند از:

توان عملیاتی بالا

آپاچی کافکا به منظور ارائه راهکار با توان عملیاتی بالا و latency پایین در استریمینگ داده طراحی شده است و این قابلیت را دارد که حجم زیادی از پیام‌ها را در هر ثانیه پردازش کند؛ در نتیجه آن را برای سناریوهایی که پردازش به صورت Realtime ضروری است، مناسب می‌کند.

قابلیت مقیاس‌پذیری

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

مقاومت در برابر خطا

در سیستم Kafka، داده‌ها در Broker‌های مختلف ذخیره می‌شوند تا اطمینان حاصل ‌شود که اگر یک broker با مشکل مواجه شد، داده‌ها همچنان در دسترس هستند. این رویکرد، سیستم کافکا را به یک سیستم reliable تبدیل می‌کند.

دوام

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

پردازش Realtime

با توجه به اینکه تولیدکنندگان و مصرف‌کنندگان در سیستم کافکا با داده‌های استریم کار می‌کنند، قابلیت پردازش داده به صورت Realtime در این سیستم وجود دارد که این قابلیت امکان پشتیبانی از فریم‌ورک‌های پردازش استریم (مانند Kafka Streams)  را برای ساخت برنامه‌های تحلیل و پاسخ Realtime به داده‌ها فراهم می‌کند.

جداسازی تولیدکنندگان و مصرف‌کنندگان

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

Event Sourcing

معماری لاگ محور Kafka آن را به ابزاری مناسب جهت استفاده از Event Sourcing تبدیل می‌کند. به این ترتیب که رویدادها در یک لاگ ایمن ذخیره می‌شوند و تاریخچه کاملی از تغییرات به منظور کشف خطا و رصد عملکرد وجود دارد.

سازگاری با زبان‌های برنامه‌نویسی متفاوت

Kafka کتابخانه‌های متعددی را برای زبان‌های برنامه‌نویسی مختلف دارد که این امکان را فراهم می‌کند تا توسعه‌دهندگان با استفاده از زبان‌های مختلف برنامه‌نویسی بتوانند از امکانات این سیستم استفاده کنند.

Ecosystem

Kafka یک جامعه OpenSource پویا دارد و اکوسیستم آن شامل اتصال‌ها و ادغام‌های متنوع با ابزارها و پلتفرم‌های دیگر است. این گستردگی اکوسیستم قابلیت‌ها و تعامل را افزایش می‌دهد.

سازگاری با تکنولوژی‌های BigData

Kafka به صورت سریع و آسان با سایر تکنولوژی‌های بیگ دیتا مانند Apache Hadoop و Apache Spark ادغام می‌شود.

امنیت داده

با استفاده از راهکارهای امنیت داده مانند رمزنگاری SSL/TLS، مکانیزم‌های احراز هویت و مجوز دهی ، محرمانگی و صحت اطلاعات مبادله شده درون سیستم Kafka تضمین می‌شود.

قابلیت استفاده به عنوان‌هاب داده مرکزی

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

امنیت در Apache Kafka

امکانات امنیتی Kafka شامل مواردی مانند دسترسی کاربران و نقش‌ها، استفاده از SSL برای ارتباطات رمزگذاری شده، و احراز هویت (authentication) می‌شوند.

آیا می‌توان یک پیام را به صورت محرمانه برای یک Consumer ارسال نمود؟

تاپیک‌ها برای تمام مصرف‌کننده‌هایی که به آن متصل می‌شوند، در دسترس هستند. این به این معناست که تمام Consumerهایی که اجازه دسترسی به تاپیک را دارند، می‌توانند پیام‌ها را ببینند.

اگر نیاز به ارسال پیام به یک Consumer خاص یا گروه خاص از کانسومرها دارید، می‌توانید از راهکارهای دیگر استفاده کنید. به عنوان مثال:

۱. تاپیک‌های مختلف برای دسترسی محدودتر

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

۲. استفاده از امکانات امنیتی آپاچی کافکا

با استفاده از دسترسی‌ها، نقش‌ها و احراز هویت Kafka، سطح دسترسی به تاپیک‌ها را مدیریت کنید.

۳. رمزگذاری پیام‌ها

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

همچنین در نسخه‌های جدید‌تر آپاچی کافکا، امکانات جدیدی در زمینه امنیت افزوده شده است.

معرفی RabbitMQ

پیش از تشریح تفاوت این دو تکنولوژی بیاید کمی با RabbitMQ آشنا شویم:

RabbitMQ یک Message Broker (مدیریت پیام) است که از پروتکل AMQP (یا Advanced Message Queuing Protocol) برای انتقال پیام‌ها و اطلاعات بین سیستم‌ها استفاده می‌کند. این سیستم توسط شرکت LShift توسعه داده شده و در سال ۲۰۰۷ به صورت آزاد منتشر شد. در ادامه، تاریخچه RabbitMQ به طور خلاصه مرور خواهیم کرد.

RabbitMQ امروزه یکی از Message Broker‌های معروف و پرکاربرد در صنعت نرم‌افزار است و برای انتقال پیام‌ها و تسهیل تبادل داده بین سیستم‌ها مورد استفاده قرار می‌گیرد.

مروری بر تاریخچه RabbitMQ

۲۰۰۷: تولید

RabbitMQ از ابتدا توسط شرکت LShift توسعه داده شد. توسعه این پروژه از تحقیقات انجام شده در زمینه معماری‌های Message-Oriented Middleware) MOM) گرفته شده بود.

۲۰۰۸-۲۰۰۹: آزمایش محدود

در این دوره، RabbitMQ به صورت آزمایشی و محدود منتشر شد و توجه گسترده‌تری از جامعه نرم‌افزاری به خود جلب کرد.

۲۰۰۹: انتشار اولیه

در اوایل سال ۲۰۰۹، RabbitMQ به عنوان یک پروژه متن‌باز تحت مجوز Mozilla Public License منتشر شد.

۲۰۱۰: انتقال به EMC

در سال ۲۰۱۰، شرکت SpringSource که در آن زمان بخشی از شرکت VMware بود، Rabbit Technologies را که توسعه‌دهنده RabbitMQ بود، خریداری کرد. این شرکت به زودی توسط EMC خریده شد.

۲۰۱۳: انتقال به Pivotal

Pivotal Labs از EMC جدا شد و RabbitMQ به عنوان یک محصول اصلی در Pivotal Software قرار گرفت.

۲۰۱۵: انتقال به VMware

در سال ۲۰۱۵، Pivotal Labs به VMware تغییر نام داد و RabbitMQ به عنوان یکی از محصولات اصلی این شرکت باقی ماند.

۲۰۱۷: شکل‌گیری RabbitMQ در Rabbit Technologies

در سال ۲۰۱۷، Rabbit Technologies تصمیم به جدا شدن از VMware گرفت و به شکل یک شرکت مستقل با نام Pivotal Software شکل گرفت.

۲۰۱۹: انتقال به Pivotal Software

در سال ۲۰۱۹، VMware تصمیم به انتقال RabbitMQ به یک مجموعه نرم‌افزاری جدا از Pivotal Software گرفت.

۲۰۲۰: انتقال به VMware Tanzu

در سال ۲۰۲۰، Pivotal Software توسط VMware به نام VMware Tanzu تغییر نام داد و RabbitMQ همچنان به عنوان یک محصول کلیدی در زیرساخت توسعه نرم‌افزار مدرن شناخته می‌شود.

تفاوت Apache Kafka و RabbitMQ

هر دو این محصولات سیستم‌ مدیریت پیام (Message Broker) هستند و هر یک از این سیستم‌ها قابلیت‌ها و محدودیت‌های خود را دارند؛ بنابراین انتخاب بین Apache Kafka و RabbitMQ بستگی به نیازها و خصوصیات خاص پروژه شما دارد.

مقایسه ویژگی‌های Apache Kafka و RabbitMQ

۱. مدل پیام

Apache Kafka

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

پیام‌ها در Kafka به شکل «تاپیک» ارسال می‌شوند و می‌توانند توسط چندین Consumer مصرف شوند.

RabbitMQ

از مدل پیام «صف» (Queue) برای انتقال پیام‌ها استفاده می‌کند. پیام‌ها به یک صف ارسال می‌شوند و یک Consumer مصرف می‌کند. همچنین می‌توان چندین صف داشت و پیام‌ها به ترتیب ارسال، به صف‌ها اضافه می‌شوند.

۲. دقت در توزیع داده

Apache Kafka

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

RabbitMQ

برای سناریوهایی که نیاز به دقت در انتقال پیام و اطمینان از رسیدن آن دارند مناسب است. پیام‌ها به ترتیب و با دقت به Consumer ارسال می‌شوند.

۳. عملکرد و تحمل خطا

Apache Kafka

برای سناریوهایی که نیاز به تحمل خطا و بازده بالا و قابلیت مقیاس‌پذیری دارند مناسب است.

RabbitMQ

برای سناریوهایی که نیاز به تضمین رسیدن پیام‌ها و قابلیت‌های پیشرفته‌تری در مدیریت صف‌ها دارند مناسب است. تاکید بر قابلیت اطمینان و انعطاف پذیری دارد.

۴. پروتکل ارتباطی

Apache Kafka

از پروتکل خاص به نام Kafka Protocol برای ارتباط با تولیدکنندگان و مصرف‌کنندگان استفاده می‌کند.

RabbitMQ

از پروتکل AMQP برای ارتباط استفاده می‌کند.

۵. زبان‌های برنامه‌نویسی

Apache Kafka

از اکثر زبان‌های برنامه‌نویسی پشتیبانی می‌کند.

RabbitMQ

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

نتیجه‌گیری

اگر تاکید بر ویژگی‌های لاگ‌محور، دوام، مقیاس‌پذیری، و پردازش استریم به صورت زمان واقعی باشد، Apache Kafka به دلیل معماری لاگ‌محور، قابلیت مقیاس‌پذیری، مقاومت در برابر خطا، و حمایت داخلی از پردازش استریم یک انتخاب قوی است. اگر تاکید بر پیام‌رسانی سنتی با سادگی باشد و پردازش به صورت زمان واقعی اولویت اصلی نباشد، RabbitMQ می‌تواند برای جمع‌آوری لاگ‌ها استفاده شود، به ویژه در سناریوهایی که مدل‌های صفی سنتی مناسب‌تر بوده و ویژگی‌های پردازش استریم اصلی نباشند.