https://virgool.io/feed/@tohid.dadashnejad fa 2026-06-12 06:34:15 https://files.virgool.io/upload/users/154326/avatar/RCIbBO.png?height=120&width=120 https://virgool.io/@tohid.dadashnejad https://virgool.io/@tohid.dadashnejad/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D8%A8%DB%8C%D9%86-rabbitmq-%D9%88-kafka-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-i2lfndkvnwci مقدمهبعنوان یک معمار نرم افزار که بیشتر اوقات با مایکروسرویس ها درگیر هستیم، همیشه این سوال برامون پیش اومده که بهتره از RabbitMQ استفاده کنیم یا Kafka؟ خیلی از برنامه نویسا این دو ابزار رو یک جایگزینی برای هم میبینن. ‌علارغم اینکه این حرف اشتباه نیست تفاوتهای مختلفی هم بین این دو پلتفرم وجود داره.درنتیجه، سناریوهای مختلف به راه‌حل‌های مختلف و مناسبی نیاز دارن، و انتخاب یک راه‌حل نامناسب می‌تونه به شدت طراحی، توسعه و نگهداری نرم افزار رو تحت تاثیر قرار بده.تو قسمت اول این مقاله به بررسی مفاهیم پیاده سازی داخلی RabbitMQ و Kafka پرداختیم تو این قسمت قراره تفاوت‌های قابل توجه این (تفاوت‌هایی که هر مهندس نرم افزار باید بدونه) دو تکنولوژی رو باهم بررسی کنیم.نهایتا در مورد پترن‌های معماری که اغلب سعی داریم با این ابزارها پیاده سازی کنیم، صحبت میکنیم و نقاط ضعف و قدرت هر ابزاری رو در سناریوهای مختلف مورد بررسی قرار میدیم.توجه 1درصورتی که با ساختار داخلی RabbitMQ و Kafka آشنا نیستین حتما پیشنهاد میکنیم که قسمت اول این مقاله رو مطالعه کنید یا حداقل یه نگاه مختصری به دیاگرام‌ها و تصاویرش داشته باشین.توجه 2پیرو پست قبلی یکی از دوستان در مورد Apache Pulsar از من پرسیده بودن. Pulsar هم یک messaging platform هست و ادعا میکنه که ترکیبی از بهترین امکانات RabbitMQ و Kafka رو داره.به عنوان یک پلتفرم مدرن خیلی امیدوار کننده به نظر میاد ولی در هر صورت این ابزار هم مانند سایر ابزارها میتونه نقاط ضعف و قوت خودشو داشته باشه. به هر حال سعی میکنم در آینده یک مقاله ای هم راجع به مقایسه Apache Pulsar بنویسم ولی فعلا بهتره روی RabbitMQ و Kafka تمرکز کنیم.تفاوت‌های قابل توجه بین RabbitMQ و Kafkaربیت ام کیو یک Message broker هست در حالی که Kafka یک Dirtributed streaming platform هست. حالا شاید بنظرتون این دوتا فقط از لحاظ معنایی باهم تفاوت داشته باشن ولی این مستلزم پیامدهایی هست که میتونه بر توانی‌های ما برای پیاده سازی راحت تو موارد مختلف تاثیر بزاره.برای مثال بهترین کاربرد Kafka پردازش جریان داده هاس درحالی که RabbitMQ به اون صورت ترتیب پیام‌هارو در حین جریان تضمین نمی‌کنه.از طرفی RabbitMQ از تلاش مجدد پیام‌های fail شده و dead-letter exhanges داخل خودش پشتیبانی میکنه درحالی که Kafka یه همچین پیاده سازی‌‌‌های رو در اختیار خود کاربر گذاشته.تو این قسمت این تفاوت‌‌ها و یکسری موارد دیگه برجسته شدن.ترتیب پیام‌هاPhoto by Arshad Pooloo on Unsplashربیت ام کیو تضمین و توجه آنچنانی رو ترتیب پیام‌‌‌هایی که به queue یا exchange ارسال میشن نداره درحالی که شاید بنظرتون این بدیهی باشه که consumer ها پیام‌‌‌هارو با همون ترتیبی که producerها به سمتشون میفرستن پردازش میکنن، ولی باز هم این مساله می‌تونه گمراه کننده باشه.طبق مستندات RabbitMQ در مورد تضمین ترتیب پیام‌ها این چنین بیان شده که:ترتیب پیام‌‌‌ها در صورتی رعایت میشه که اولا داخل یک channel ارسال بشن و از یک exchange یا queue عبور کنن و نهایتا توسط یک outgoing channel به دست consumer برسن. ــــــ RabbitMQ Broker Semanticsبنابراین در صورتی که ما فقط یک consumer داشته باشیم، پیام‌ها به ترتیب ارسال میشن ولی اگر به ازای یک queue چندین consumer داشته باشیم ترتیب پیام‌ها هیچ ضمانتی نداره.این اتفاق زمانی رخ میده که consumerها پیامی رو بنا به دلایلی دوباره داخل queue برگردونن. (مثلا زمانی که پردازش fail میشه) به محض اینکه یک پیام مجددا وارد queue میشه یک consumer دیگه برمیداره و پردازشش میکنه درحالیکه قبل همین پیام، همین consumer پیامی جدیدتر از اینو پردازش کرده بود. بنابراین consumer groupها پیام‌‌‌هارو خارج از ترتیب پردازش میکنن. به این دیاگرام دقت کنید:مثال بهم خوردن ترتیب پیام‌ها در RabbitMQالبته ما می‌تونیم با محدود کردن پردازش همزمان (concurrency) هر consumer باعث بشیم که ترتیب رعایت بشه یا دقیق‌تر اگه بخوام بگم تعداد thread ها در consumer باید به 1 محدود بشه چون پردازش موازی می‌تونه همین مشکل رو برامون بوجود بیاره.ولی خب تو این حالت ما خودمون رو به یک single-threaded consumer محدود کردیم بنابراین زمانی‌که سیستم ما رشد کنه و ما مجبور به scale کردن consumer ها بشیم قطعا با مشکل بزرگی روبرو میشیم.از طرفی Kafka با اطمنیان بسیار زیاد ترتیب پیام‌هارو تو ارسال و پردازش تضمین میکنه به عبارت دیگه Kafka تضمین میکنه پیام‌هایی که وارد یک پارتیشن در یک topic میشن، پردازششون هم به ترتیب انجام میشه. تو قسمت قبل به این اشاره کردیم که Kafka برای جایگذاری پیام‌‌‌ها داخل پارتیشن‌ها از round-robin partitioner استفاده میکنه ولی درکنار این، هر producer ای میتونه یه partition-key روی هر پیامی ست کنه و بدین ترتیب یک جریان منطقی دیتا ایجاد کنه. (مثلا پیام‌هایی که از یک device خاصی میان)اینگونه میشه که پیام‌هایی که از یک جریان خاصی دریافت میشن داخل یک پارتیشن قرار می‌گیرن پس درنتیجه ترتیب پردازششون توسط یک consumer group رعایت میشه.با توجه به اینکه داخل هر consumer group هر پارتیشن توسط یک single-threaded consumer پردازش میشه، بنابراین ما نمی‌تونیم پردازش یک single partition رو scale بکنیم، در عوض می‌تونیم تعداد پارتیشن‌های هر topic رو افزایش بدیم و بدین ترتیب پیام‌های کمتری وارد هر پارتیشن میشن و بعد می‌تونیم برای هر پارتیشن یک consumer در نظر بگیریم.برنده این بخشمشخصه که Kafka برنده این بخش از مقایسه اس چون ترتیب پردازش پیام‌ها توش رعایت شده ولی RabbitMQ تضمین خاصی رو این مساله نداره.مسیریابی پیام‌هاPhoto by Webaroo on Unsplashربیت ام کیو میتونه پیام‌هارو برای consumerهای هر exchange ای، طبق قوانینی که خودشون مشخص کردن بفرسته. یک topic exchange میتونه پیام‌هارو براساس یک هدر اختصاصی بنام routing_key ارسال کنه.همچنین یک headers exchange میتونه با header attribute های بیشتری پیام‌هارو ارسال کنه. هر دو exchange ها بطور قابل توجهی به consumerها کمک می‌کنن تا پیام‌های مورد علاقشونو دریافت کنن. در نتیجه میشه گفت تو این زمنیه RabbitMQ یک معماری و راه‌حل انعطاف‌پذیری فراهم آورده.شاید بعنوان یک برنامه نویس بتونید از Kafka stream job استفاده بکنید، به این صورت که ابتدا پیام‌ها از یک topic خونده و فیلتر بشن و بعد داخل یک topic دیگه ای قرار بگیرن ولی پیاده سازی این مدل، حفظ و نگهداریش هزینه سنگینی داره.برنده این بخشوقتی حرف از routing و filtering پیام‌ها زده میشه قطعا RabbitMQ قابلیت بالاتری نسبت به Kafka داره.زمان سنجی پیام‌هاPhoto by Oliver Hale on Unsplashربیت ام کیو جهت زمان سنجی (Message timing) پیام‌هایی که به queue ارسال میشن، قابلیت‌های مختلفی رو فراهم آورده.عمر پیام (TTL)برای هر پیامی که به RabbitMQ فرستاده میشه میتونیم یک TTL در نظر بگیرم که البته این کارو یا توسط publisher می‌تونیم انجام بدیم یا بعنوان یک policy برای queue در نظر بگیریم. در صورتی که consumer بعد از گذر یک زمان مشخص شده موفق به پردازش پیام نشه، پیام از صف حذف شده و داخل dead-letter exchange منتقل می‌شه.عمر پیام یا TTL برای دستوراتی که به زمان حساس هستن یا به عبارت دیگه بعد از گذر یک زمان مشخصی اهمیت خودشونو از دست میدن، بسیار مهمه.پیام‌های برنامه ریزی (scheduled) / به تاخیر (delayed) انداخته شدهربیت ام کیو با استفاده از یک پلاگین از پیام‌های delayed/scheduled پشتیبانی می‌کنه. پس از اینکه این پلاگین تو exchange فعال شد، producer می‌تونه یک delay روی پیام ست کنه که دراین صورت RabbitMQ پیام‌رو با تاخیر به سمت صف consumer ارسال می‌کنه.این امکان به برنامه نویس‌ها اجازه میده تا برای command های بعدی برنامه ریزی داشته باشن. بعنوان مثال اگر تعداد درخواست‌های یک producer از یک حدی رد شد می‌تونیم درخواست‌های بعدی رو به تعویق بندازیم.کافکا از یه همچین امکاناتی پشتیبانی نمیکنه و هر پیامی رو بلافاصله بعد رسیدنش وارد پارتیشن ها میکنه که همون لحظه هم توسط consumer ها آماده پردازش میشن.همچنین کافکا هیچ مکانیزمی برای پیاده سازی TTL نداره هرچند که می‌تونیم این بخشو تو لایه application پیاده سازی کنیم.باید به یاد داشته باشیم که پارتیشن کافکا append-only هست و کافکا نمی‌تونه زمان پیام و موقعیتشو داخل پارتیشن دستکاری کنه.برنده این بخشتو این بخش RabbitMQ به خاطر ذاتی که داره، بدون هیچ زحمتی برنده اعلام میشه.نگهداری پیام‌هاPhoto by chuttersnap on Unsplashربیت ام کیو هر پیامی رو بعد ازینکه با موفقیت پردازش شد از صف بیرون می‌بره. البته یکی از ویژگیهای هر message-broker ای هست و ما نمی‌تونیم اینو تغییر بدیم.در عوض کافکا هر پیامی رو تا یک مدتی (طبق یکسری تنظیمات از قبل تعریف شده به ازای هر topic) نگه میداره. در کل Kafka به منظور نگه داری پیام‌ها به این موضوع اهمیت نمیده که آیا این پیام پردازش شده یا خیر!مصرف کننده (Consumer)ها به هر تعدادی که بخوان می‌تونن یک پیامی رو پردازش کنن همچنین می‌تونن با دستکاری ایندکس partition که تو خودشون نگه میدارن، عقب‌تر برگردن. بطور دوره‌ای کافکا عمر پیام‌هارو داخل topic بررسی میکنه و اونایی که به حد کافی قدیمی هستن رو حذف می‌کنه.کارایی Kafka به اندازه storage بستگی نداره و بصورت نظری می‌تونه تعداد نامحدودی از پیام‌هارو نگه داره. (البته باید nodeهای شما به حد کافی ظرفیت داشته باشن)برنده این بخشکافکا طوری طراحی شده که بتونه پیام‌هارو نگه داره ولی RabbitMQ خیر. پس تو این قسمت هیچ رقابتی وجود نداره و بدون شک Kafka برنده این بخش اعلام میشه.مدیریت خطاPhoto by Sarah Kilian on Unsplashبرنامه نویس‌ها زمانی که با پیام‌ها، صف‌ها و رویداد‌ها درگیر هستن گمان میکنن که پردازش پیام‌ها همیشه با موفقیت انجام میشه. گذشته از همه اینا، زمانی که producer ها پیامی رو داخل صف یا topic قرار میدن حتی اگر consumer موفق به پردازش این پیام نشه این روند می‌تونه آنقدر تکرار بشه که نهایتا عملیات با موفقیت به اتمام برسه.درحالیکه این مساله درسته، ما باید یه فکر دیگه‌ای هم تو این فرآیند داشته باشیم. ما باید در نظر بگیریم که تو بعضی از سناریو‌ها ممکن پردازش پیامی fail بشه بنابراین باید بتونیم این شرایط رو براحتی مدیریت کنیم حتی اگه راه‌حلش از طریق مداخله انسانی باشه.در کل هنگام پردازش پیام‌ها دو نوع خطا وجود داره:خطاهای گذرا ـــــ این نوع خطاها اغلب به دلیل یه سری مشکلاتی موقتی رخ میدن مانند اتصال شبکه، لود CPU یا کرش یک سرویس که معمولا با تلاش‌های مکرر فرآیند میتونیم مدیریتش کنیم.2. خطاهای ماندگار ــــ این نوع خطاها به دلیل یک مشکل دائمی بوجود میان که با تلاش‌های مکرر نمیشه رفعشون کرد، مانند باگ یا ساختار پیام نامعتبر.بعنوان معمار و توسعه دهنده همیشه باید این سوالارو از خودمون بپرسیم: "اگر پردازش پیامی fail بشه چند بار باید تلاش مجدد داشته باشیم؟ بین هر تلاش مجدد چقدر باید وقفه داشته باشیم؟ چطور باید خطاهای دائمی و موقتی رو از هم تشخیص بدیم؟‌"و از همه مهمتر: "بعد ازینکه تلاش‌های مجدد نتیجه‌ای ندادن باید چیکار کنیم؟"درحالیکه جواب این سوالات domain-specific هستن، پلتفرم‌های messaging برای پیاده‌سازی راه‌حل‌هامون ابزارهایی رو فراهم آوردن.ربیت ام کیو ابزارهایی مانند delivery retries و dead-letter exchanges یا (DLX) برای مدیریت خطای پردازش پیام‌ها در اختیارمون گذاشته. ایده اصلی DLX اینه که RabbitMQ بصورت اتوماتیک message هایی که fail شدن رو طبق یکسری تنظمیات به DLX میفرسته و قانون‌های پردازش بیشتری از جمله تاخیر تلاش‌های مجدد، تعداد تلاش‌های مجدد و تحویل به صف مداخله انسانی (Human intervention queue)، روشون اعمال میکنه.با مطالعه این مقاله می‌تونید با پترن‌های مدیریت تلاش‌های مجدد تو RabbitMQ بیشتر آشنا بشید.مهمترین نکته ای که باید به یاد داشته باشید اینه که تو RabbitMQ زمانی که یک consumer در حال پردازش یک پیامه یا داره تلاش میکنه تا مجددا پردازشش بکنه (حتی قبل از اینکه fail بشه و دوباره به صف برگردونه)، بقیه consumerها می‌تونن پیامهای بعدی رو بصورت همزمان پردازش کنن.درکل عملیات پردازش پیام‌ها، زمانی که یک consumer داره رو یه پیام خاصی تلاش مجدد میکنه، متوقف نمیشه درنتیجه یک consumer می‌تونه پردازش یک پیامو بارها و بارها بدون اینکه کل سیستم تحت تاثیر قرار بده، پردازش کنه.مصرف کننده 1 میتونه پردازش پیام 1 رو بارها تکرار کنه درحالیکه consumerهای دیگه دارن به کارشون ادامه میدن.برخلاف RabbitMQ ما همچین مکانیزمی رو تو Kafka نداریم و این بستگی به خودمون داره که یه همچین مکانیزمی رو تو لایه application پیاده سازی کنیم.همچنین باید توجه داشت، زمانی که یک consumer در حال پردازش یک پیامه بقیه پیام‌های اون پارتیشن نمی‌تونن پردازش بشن.ما نمی‌تونیم پیامی رو رد یا پردازشش رو برای بعد موکول کنیم بخاطر اینکه consumer ها نمی‌تونن ترتیب پیام‌هارو تغییر بدن. همونطور که قبلا هم بهش اشاره شد پارتیشن‌های کافکا append-only هستن.راه‌حل لایه اپلیکیشن اینگونه هست که می‌تونیم پیام‌هایی که fail میشن رو به یه topic دیگه بفرستیم ولی خب تو این حالت ترتیب پیام‌ها بهم میریزه.نمونه یه همچین پیاده سازی توسط مهندسی Uber رو می‌تونیم رو این سایت ببینیم. در صورتی که تاخیر پیام‌ها اهمیتی نداشته باشن استفاده از مانیتورینگ Vanilla Kafka برای مدیریت خطاها میتونه کافی باشه.پیام‌های پارتیش پایینی تا زمانی که consumer رو پردازش یک پیام گیر کرده، انجام نمیشن.برنده این بخشازونجایی که RabbitMQ برای مدیریت خطا مکانیزم خیلی خوبی فراهم آورده، بعنوان برنده این بخش اعلام میشه.مقیاس پذیریPhoto by Graphic Node on Unsplashدر کل معیارهای زیادی برای بررسی پرفورمنس RabbitMQ و Kafka وجود دارن.درحالیکه که معیارهای عمومی قابلیت اجرائی محدودی تو شرایط مختلف دارن، میشه گفت Kafka پرفورمنس بهتری نسبت به RabbitMQ داره، به دلیل اینکه Kafka از sequential disk I/O به منظور تقویت کارایی خودش استفاده می‌کنه.ازونجایی Kafka از پارتیشن ها استفاده می‌کنه پس می‌تونه horizantal scaling بهتری داشته باشه درحالی که RabbitMQ تو vertical scaling بهتر جواب میده. ( تفاوت بین horizonal scaling و vertical scaling)سیستم‌های گسترش یافته Kafka معمولا می‌تونن صدها هزار یا حتی میلیون‌ها پیام رو در ثانیه مدیریت کنن.در گذشته توسط Pivotal ثبت شده بود که یک کلاستر RabbitMQ در هر ثانیه یک میلیون پیام رو مدیریت میکنه. البته باید گفت این‌ کارو با یک کلاستر 30 نودی و لود بهینه شده که بین چندین queue و exchange پخش می‌شد،انجام داده.برنده این بخشدر حالیکه هر دو پلتفرم لود بسیار سنگینی رو ‌می‌تونن مدیریت کنن، Kafka بهتر می‌تونه scale بشه و طبیعتا پرفورمنس بهتری نسبت به RabbitMQ داره و برنده این بخش اعلام میشه.پیچیدگی سمت ConsumerPhoto by John Barkiple on Unsplashربیت ام کیو از رویکرد smart-broker and dumb-consumer(دلال باهوش و مصرف کننده بی عقل) استفاده میکنه. به این صورت که هر consumer ای برای استفاده از queue رجیستر می‌کنه و به محض اینکه وارد شد RabbitMQ پیام‌هارو جهت پردازش به سمتش ارسال میکنه. همچنین RabbitMQ یک pull API هم داره که زیاد ازش استفاده نمیشه.ربیت ام کیو مدیریت توزیع پیام‌ها بین consumer ها و همچنین و حذف پیام‌ها از queue رو به عهده داره. بنابراین دیگه نیازی نیست consumer خودشو درگیر این مسائل بکنه.همچنین ساختار RabbitMQ طوری هست که در زمان‌های لود سنگین بدون هیچ تغییر تو سیستم یک consumer group می‌تونه از یک consumer به چندین consumer افزایش پیدا کنه.تو این تصویر میبینید که به راحتی consumer ها تو RabbitMQ می‌تونن scale-up و scale-down بشن.درحالیکه Kafka از رویکرود dumb-broker and smart-consumer (دلال بی عقل و مصرف کننده باهوش) استفاده میکنه یعنی consumer های داخل یک consumer group باید خودشون پارتیشن های یک topic رو باهم هماهنگ کنن. ( به خاطر همین هر consumer داخل یک consumer group فقط به یک پارتیشن گوش میده)همچنین Consumer ها باید مدیریت و ذخیره سازی ایندکس پارتیشن هارو انجام بدن که خوشبختانه Kafka SDK این کارو برامون انجام میده و نیاز نیست فکرمونو با این موضوع درگیر کنیم.باید توجه داشت که تو لود پایین یک consumer واحد باید عملیات پردازش و پیگیری چندین پارتیشن رو به تنهایی به عهده بگیره بنابراین سمت consumer به منابع زیادی نیاز خواهیم داشت.تو لود سنگین تعداد consumerهای هر گروهی رو تا جایی میتونیم افزایش بدیم که تعدادشون از تعداد کل پارتیشن‌های یک topic تجاوز نکنه در نتیجه مجبوریم Kafka رو طوری ست کنیم که تو همچین شرایطی پارتیشن های بیشتری اضافه کنه.و زمانی که مجددا لود پایین‌تر میاد ما نمی‌تونیم پارتیشن‌های اضافه رو حذف کنیم بنابراین این باعث سنگین‌تر شدن کار هر consumer ای میشه.پارتیشن‌های Kafka قابل حذف نیستن بنابراین بعد از scale-down کار consumer ها سنگین تر میشه.برنده این بخشتو این بخش RabbitMQ به علت استفاده از رویکرد dumb-consumer برنده اعلام میشه.کجا از کدوم استفاده کنیم؟Photo by Paulius Dragunas on Unsplashو بلاخره رسیدیم به سوال میلیون دلاری: "کجا بهتره از RabbitMQ استفاده کنیم و کجا بهتره از Kafka استفاد کنیم؟"اگه بخوایم تفاوت‌های بالارو خلاصه کنیم به یه همچین نتیجه ای میرسیم:ربیت ام کیو قابل ترجیحه زمانی که ما نیاز داریم به:قوانین پیشرفته و منعطف مسیریابیکنترل زمان سنجی پیام‌ها ( مشخص کردن طول عمر برای پیام یا تاخیر زمان پردازش پیام)مدیریت پیشرفته خطاها ، مخصوصا زمانی که احتمال میدیم پردازش پیام‌ها توسط consumer ها fail بشن. (حالا یا بصورت موقتی یا ماندگار)پیاده سازی راحت سمت consumerکافکا قابل ترجیحه زمانی که ما نیاز داریم به:ترتیب پیام (بصورت سختگیرانه)نگهداری پیام‌های قدیمی بصورت دوره‌ای و امکان بازیابیشون.امکان scale کردن بهتر در زمان‌هایی که روش‌های سنتی جواب نمیدن.تو بیشتر مواقع می‌تونیم هر دو ابزارو پیاده سازی کنیم این بیشتر به عنوان معمار نرم‌افزار به ما بستگی داره که برای هرکاری کدومشو انتخاب کنیم. همچنین موقع انتخاب باید محدودیت‌های عملکردی(که بالاتر بهش اشاره شد) و غیر عملکردی رو در نظر بگیریم.این محدودیت‌ها شامل:بودن توسعه دهنده‌ای با دانش این پلتفرم‌هادسترسی به راه‌حل‌های ابری در صورت امکانهزینه عملیاتی هر کدوم از راه‌حل‌‌هادسترسی یه SDKها برای اهداف stackهنگام توسعه نرم افزارهای پیچیده شاید بخوایم برای همه نیازهای پیام رسانی فقط از یک ابزار استفاده کنیم ولی طبق تجربیات من استفاده از هر دو می‌تونه فواید زیادی داشته باشه.بعنوان مثال تو سیستم‌های رویداد-گرا می‌تونیم از RabbitMQ برای ارسال دستورات بین سرویس‌ها و از Kafka برای ارسال نوتیفیکیشن‌ رویدادهای bussiness استفاده کنیم.دلیلش اینه که نوتیفیکیشن رویدادها بیشتر برای تهیه منابع، عملیات دسته‌ای(Batch operations) یا در راستای اهداف حسابرسی استفاده می‌شن، درنتیجه Kafka تو این حالت به خاطر نگه داشتن پیام‌ها می‌تونه کارایی بهتری داشته باشه.از طرفی دستورات بین سرویس ها به عملیات بیشتری سمت consumer ها نیاز دارن و هر پردازشی می‌تونه fail بشه و قطعا ما به مدیریت پیشرفته خطاها نیاز داریم که اینجا RabbitMQ بیشتر میدرخشه. احتمالا در آینده مقاله ای با جزئیات بیشتر راجع به همین بنویسم ولی شما همیشه تو ذهنتون داشته باشید: "نسبت به نیازهای سیستم ممکن مسیر شما عوض بشه"جمع بندیمن نوشتن این دو مقاله رو با این دیدگاه شروع کردم که ممکن خیلی از برنامه‌نویسا این دو ابزارو جایگزینی برای هم ببینن، در هر صورت امیدوارم با خوندن این دو مقاله به تفاوت‌های ساختاری، فنی و پیاده سازی این دو ابزار پی برده باشید.در کل تفاوت‌ها می‌تونن رو موارد استفاده این دو ابزار تاثیر بزارن در نتیجه هر دو ابزار عالی هستن و می‌تونن تو موارد مختلفی استفاده بشن.بنابراین به عنوان یک معمار نرم‌افزار باید نیازمندی‌های یک سیستم رو خوب متوجه بشیم، اولویت بندی کنیم و نسبت به شرایط بهترین ابزارو انتخاب کنیم.دوستان این مقاله ترجمه شده مقاله زیر می باشد:https://medium.com/better-programming/rabbitmq-vs-kafka-1779b5b70c41 توحید داداش نژاد توحید داداش نژاد Fri, 10 Jul 2020 17:28:28 +0430 https://virgool.io/@tohid.dadashnejad/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D8%A8%DB%8C%D9%86-rabbitmq-%D9%88-kafka-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-b3dgqgjhzzqh مقدمهبعنوان یک معمار نرم افزار که بیشتر اوقات با مایکروسرویس ها درگیر هستیم، همیشه این سوال برامون پیش اومده که بهتره از RabbitMQ استفاده کنیم یا Kafka؟ خیلی از برنامه نویسا این دو ابزار رو یک جایگزینی برای هم میبینن. ‌علارغم اینکه این حرف اشتباه نیست تفاوتهای مختلفی هم بین این دو پلتفرم وجود داره. درنتیجه، سناریوهای مختلف به راه‌حل‌های مختلف و مناسبی نیاز دارن، و انتخاب یک راه‌حل نامناسب می‌تونه به شدت طراحی، توسعه و نگهداری نرم افزار رو تحت تاثیر قرار بده.تو این مقاله ابتدا در مورد پترن‌های Asynchronous messaging (پیام رسانی ناهمگام) صحبت میکنیم بعد به بررسی ساختار داخلی RabbitMQ و Kafka می‌پردازیم و نهایتا تو بخش دوم این مقاله تفاوت‌های عمده، مزایا و معایب این دو پلتفرم رو باهم بررسی میکنیم. Asynchronous Messaging Patternsتو این حالت، فرآیندهای تولید پیام توسط producer و پردازش توسط consumer از هم جدا شدن. در‌کل تو سیستم های messaging دو پترن مهم وجود داره: message queueing و publish/subscribeMessage queueingتو این پترن queue (صف)، producer (تولید کننده) ها و consumer (مصرف کننده) ها رو از هم جدا میکنه. چندین producer می‌تونن به یک صف یکسان پیام ارسال کنن. همچنین زمانی که یک consumer درحال پردازش یک پیامه یا locked میشه یا از دسترس خارج میشه، علاوه بر این هر consumer فقط یک نوع پیام خاصی رو می‌تونه پردازش کنه.Message queuing Publish/subscribeتو این پترن یک پیام می‌تونه به صورت همزمان توسط چندین consumer دریافت و پردازش بشه. به عبارت دیگه یک publisher می‌تونه چندین consumer رو از یک رویداد خاصی باخبر کنه. خیلی از سیستم های queuing بجای pub/sub از اصطلاح topics استفاده میکنن ولی تو RabbitMQ تاپیک یک نوع پیاده سازی pub/sub محسوب میشه یا بهتره بگیم یک نوع exchange محسوب میشه. در هر صورت من تو این مقاله برای اشاره به pub/sub از واژه topics استفاده میکنم.Publish/subscribeدر کل میشه گفت ما دو نوع subscription بیشتر نداریم:1. An ephemeral subscription تو این حالت قرارداد بین consumer و publisher تا زمانی که consumer فعال هست، برقراره و با shut down شدن consumer قرارداد و پیامهایی که باید توسط consumer پردازش میشدن از بین میرن. 2. A durable subscriptionتو این حالت قرارداد بین consumer و publisher تا زمانی که به صراحت حذف نشده برقراره و با shut down شدن consumer پلتفرم، قرارداد و پیام‌‌هارو نگه میداره که بعدا عملیات پردازشش دوباره انجام بشه.RabbitMQاین ابزار یک message broker هست که البته اخیرا بهش service bus هم میگن که بصورت native از هر دو پترنی که بالاتر بهش اشاره شد پشتیبانی میکنه. یه سری message broker های دیگه ای هم هستن از جمله ActiveMQ ، ZeroMQ، Azure Service Bus و Amazon Simple Queue Service که همه اینا نقاط مشترک زیادی دارن و بسیاری از مفاهیم که تو این مقاله توضیح داده شدن شامل اینا هم میشن.Queuesربیت ام کیو از message queuing کلاسیک پشتیبانی میکنه یعنی یک برنامه نویس می‌تونه یک صف نامگذاری شده تعریف کنه و بعد publisher ها می‌تونن پیام‌هاشونو از طریق این صف ارسال کنن. از اون طرف consumer ها هم که دارن به همین صف گوش میدن می‌تونن پیام‌هارو دریافت و پردازش کنن.Message exchangesربیت ام کیو حالت pub/sub رو با استفاده از exchange ها پیاده سازی کرده. یعنی یک publisher پیامو میده به exchange بدون اینکه اطلاعی از صفی که قرار پیامش توش ارسال بشه داشته باشه. هر consumer ای که میخواد با exchange ارتباط برقرار کنه یک صف ایجاد میکنه و بعد exchange از طریق همون صف پیام‌هارو به consumer میفرسته. همچنین exchange می‌تونه براساس یک سری routing rules پیامهای خاصی رو به consumer فیلتر کنه.RabbitMQ message exchangeنکته مهمی که وجود داره اینه که RabbitMQ از هر دو حالت durable و ephemeral پشتیبانی میکنه. این consumer هست که می‌تونه تصمیم بگیره که کدوم حالت انتخاب بکنه و این کار رو توسط API ربیت انجام میده. طبق معماری RabbitMQ همچنین می‌تونیم یک رویکرد ترکیبی داشته باشیم، به این صورت که یک گروهی از consumer هارو بزاریم که بتونن پیام‌هارو بصورت رقابتی بر روی یک صف پردازش بکنن. تو این حالت علاوه بر پیاده سازی pub/sub امکان scale کردن consumer هارو هم داریم.Pub/sub and queuing combinedApache Kafkaکافکا یک message broker نیست بلکه یک distributed streaming platform هست.برخلاف RabbitMQ که بر مبنای exchange و queue پیاده سازی شده، لایه ذخیره سازی کافکا با استفاده از partitioned transaction log پیاده سازی شده. همچنین کافکا یک Streams API فراهم کرده که با استفاده ازش میشه streamهارو بصورت real-time پردازش کرد و همچنین یک Connectors API جهت ادغام با data source های مختلف که این موضوعات خارج از بحث اصلی این مقاله هستن.سرویس های ابری یک سری راه‌حل های جایگزین برای لایه ذخیره سازی Kafka تدارک دیدن از جمله Azure Event hubs یا تا حدودی AWS Kinesis Data Streams که هم مختص cloud هستن و هم Open source که در هر صورت باز خارج از موضوع این مقاله ان.Topicsکافکا queue رو پیاده سازی نمیکنه در عوض مجموعه ای از رکوردهارو داخل دسته بندیهایی به نام topics ذخیره میکنه.به ازای هر topic، کافکا پارتیشن‌هایی از پیام‌هارو نگه میداره. هر پارتیشن از یک سری پیام‌های متوالی مرتب سازی شده، غیر قابل تغییر تشکیل یافته که هر پیامی بصورت پیوسته بهش الحاق میشه.کافکا هر پیامی رو به محض اینکه میرسه به این پارتیشن ها اضافه میکنه. بصورت پیش فرض به منظور توزیع پیامها بصورت یکنواخت بین پارتیشن ها از round-robin partitioner استفاده میکنه.تولید کننده های پیام می‌تونن این رفتار رو به منظور ایجاد یک جریان منطقی تغییر بدن. بعنوان مثال در یک اپلیکیشن multitenant شاید بخوایم یک جریان منطقی بر اساس هر tenant ID ایجاد کنیم. تو یک سناریویه IoT شاید بخوایم id هر producer ای مدام به یک پارتیشن خاصی map بشه تو این حالت خیالمون راحته که ترتیب پیامها و پردازششون رعایت میشه.Kafka producersمصرف کننده (Consumer) ها ایندکس پارتیشن هارو نگه میدارن و بصورت پی‌در‌پی پیام‌هارو میخونن.هر consumer به تنهایی میتونه دیتای چندین topic رو بخونه، همچنین میشه تعداد consumer ها رو به تعداد پارتیشن های موجود scale کرد. درنتیجه زمانی که میخوایم یک topic بسازیم باید باید به دقت ، توان messaging ای که از topic انتظار داریم رو در نظر داشته باشیم. به گروهی از consumer ها که باهم دیتای یک topic رو میخونن consumer group گفته میشه. Kafka API مدیریت balancing پردازش پارتیشن بین consumer ها، داخل consumer group و همچنین ذخیره ایندکس فعلی پارتیشن برای هر consumer رو به عهده داره. Kafka consumersپیاده سازی messaging pattern توسط Kafkaپیاده سازی Kafka یه جورایی مشابه pub/sub تو RabbitMQ.یک producer میتونه پیامهایی رو به یک topic خاصی ارسال کنه و چندین consumer group می‌تونن این پیامو پردازش کنن. به منظور مدیریت Load هر consumer group می‌تونه بصورت جداگانه scale بشه. همچنین ازونجایی که consumer ها ایندکس پارتیشن رو نگه میدارن پس می‌تونن مشخص کنن که subscription شون بصورت durable باشه که بعد از هر بار ریستارت ادامه پیام‌هارو پردازش کنن یا بصورت ephemeral باشه و با هر بار ریستارت از آخرین پیامی که وارد پارتیشن شده کارشونو شروع کنن.در هر صورت این پترن مناسبی برای message-queuing نیست. خب البته که میتونیم یه consumer group ساده برای شبیه سازی message-queuing کلاسیک داشته باشیم ولی خب این می‌تونه یه سری مشکلات داشته باشه که تو قسمت دوم این مقاله بصورت مفصل بهش اشاره خواهد شد.نکته ای که باید بهش توجه کرد اینه که Kafka بدون در نظر گرفتن اینکه آیا پیام‌ها consume شدن یانه اونارو تا یک مدت زمانی (که از قبل تنظیم شده) نگه میداره. به این معنی که consumer ها می‌تونن پیام‌های قبلی رو دوباره بخونن. علاوه بر این برنامه نویس ها می‌تونن از لایه ذخیره سازی Kafka در جهت پیاده سازی سرویس هایی مانند audit log استفاده بکنن. نتیجه گیریدرحالی که RabbitMQ و Kafka ‌می‌تونن جایگزینی برای هم باشن ولی باید اینم بدونیم که نحوه پیاده سازیشون کاملا متفاوته. در نتیجه ما نمی‌تونیم این دوتا رو عضوی از یک دسته بندی ببینیم چون یکیش message broker هست و اونیکی distributed streaming platform. در کل دوستان عزیز ما همیشه باید تفاوت بین ابزارهارو خوب شناسایی کنیم و تشخیص بدیم که برای هر سناریو کدومیک گزینه بهتریه.تو قسمت دوم این مقاله به بررسی تفاوت های این دو می‌پردازیم و همچنین مشخص میکنیم تو چه شرایطی از چه ابزاری استفاده بکنیم.دوستان این مقاله ترجمه شده مقاله زیر می باشد:https://medium.com/better-programming/rabbitmq-vs-kafka-1ef22a041793 توحید داداش نژاد توحید داداش نژاد Tue, 07 Jul 2020 21:19:32 +0430