<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های سینا کاظمین</title><link>https://virgool.ir/feed/@m_14986095</link><description></description><language>fa</language><pubDate>2026-11-11 09:30:21</pubDate><image><url>https://virgool.ir/images/default-avatar.jpg</url><title>سینا کاظمین</title><link>https://virgool.ir/@m_14986095</link></image><item><title>مفاهیم rabbitmq (بخش ۱)</title><link>https://virgool.ir/@m_14986095/مفاهیم-rabbitmq-بخش-۱-d1ikgyb1fyhg</link><description>امروز میخوام راجع به rabbitmq یکم توضیح بدم مباحثی که همه تقریبا برنامه نویس های کمی با سابقه در نهایت بهش برمیخورن و چه بهتر که مفهوم رو به خوبی درک کرده باشیم و لازم به حفظ کردن متد های library های مختلف برای زبان های مختف نیست چون روش های استفاده ازشون متفاوته و به وقت نیاز با یک سرچ ساده به سادگی قابل انجامه مبحث پیچیده و عجیبی هم نیست ولی مفاهیم یا به اصطلاح abstraction های زیادی هستند که شاید در پروژه های کمتری استفاده شوند و در صورت استفاده نکردن از آنها در طولانی مدت شاید فراموش شوند . نکته ای که باید توجه کنیم وجود مفاهیم و اصطلاحات نسبتا مختلف rabbitmq نباید باعث بشه که ما حتما از این قابلیت ها در پروژمون استفاده کنیم چون که باعث پیچیدگی بیشتر میشه و باید سعی کنیم از overuse کردن خودداری کنیم و اگر حتما این ابزار میتوانست performance سیستم را بهتر کند از آن استفاده کنیم.در ابتدا ما یک channel ایجاد میکنیم برای ایجاد connection که یک session است و ما میتوانیم session را ببندیم.نحوه کلی ساز و کار rabbitmq به این صورت هست که یک publisher پیامی رو که هر چیزی میتواند باشد مثل یک string یا int یا JSON یا حتی یک request object به داخل صف میفرستد و در سمتی دیگر consumer قرار دارد که ابتدا subscribe انجام میدهد و سپس دیتای مورد نظر رو دریافت میکند به ترتیب!این ساده ترین استفاده از rabbitmq است که consumer هم میتواند داخل خود اپلیکیشن باشد یا از سرویس دیگری که صرفا برای استفاده از message داخل queue است.مایکروسرویس :یکی از کاربرد هایی که زیاد هم استفاده میشه در رابطه با ارتباط بین مایکروسرویس هاست که اصطلاحا از rabbitmq به عنوان broker استفاده میکنیم که ارتباط بین سرویس ها برقرار باقی بمونه و در سیستم خود fault tolerance داشته باشیم که در صورت اخلال در کار یکی از سرویس ها بقیه سرویس ها به کار خود ادامه دهند و اخلالی در کار کل سیستم به وجود نیاد . به این صورت که سرویسی که کار سنگینی را انجام میدهد مثل محاسبه یا ساخت فایل مثلا گزارش اگر دچار اخلال شد بقیه سرویس هایی که با این سرویس در ارتباط بودن بدون هیچ مشکلی به کار خود ادامه میدهند و request خود را به داخل queue میفرستند و بعد از up شدن دوباره سرویس request object ها رو به عنوان consumer از queue دریافت میکنه و به کارش ادامه میده.این نکته رو هم بگم که مایکروسرویس بودن دلیلی برای جدا بودن سرور ها نیست و همه میتوانند داخل یک سرور باشند. حالا این موضوع مطرح میشود که هرکدام از این message ها مربوط به یک سرویس خاص است و دلیلی نداره که بقیه سرویس ها آن message هارا دریافت کنند هرچند message نامربوط اخلالی در کارشان ایجاد نکند که اینجا مبحث  exchange و binding پیش میاد.با استفاده از exchange ما میتوانیم message ها را به queue خاصی bind کنیم که consumer با subscribe کردن به queue مورد نظر message را دریافت میکند.در مقاله بعدی با انواع exchange ها آشنا میشیم.</description><category>سینا کاظمین</category><author>سینا کاظمین</author><pubDate>Wed, 17 Aug 2022 20:55:42 +0430</pubDate></item></channel></rss>