مدل AMQP 0-9-1 توضیح داده شده است

این راهنما نمای کلی از پروتکل AMQP 0-9-1 ، یکی از پروتکل های پشتیبانی شده توسط RabbitMQ را ارائه می دهد.

نمای کلی سطح بالا از AMQP 0-9-1 و مدل AMQP

AMQP 0-9-1 چیست؟

AMQP 0-9-1 (پروتکل Advanced Message Queing Protocol) یک پروتکل پیام رسانی است که برنامه های مشتری را قادر می سازد تا با کارگزاران میانی پیام رسانی ارتباط برقرار کنند.

کارگزاران و نقش آنها

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

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

مدل AMQP 0-9-1 به طور خلاصه

مدل AMQP 0-9-1 دیدگاه زیر را در مورد جهان دارد: پیام هایی به مبادلات منتشر می شود که اغلب با دفاتر پست یا صندوق های پستی مقایسه می شوند. مبادلات سپس با استفاده از قوانینی به نام اتصالات ، نسخه های پیام را به صف ها توزیع می کنند. سپس کارگزار یا پیام هایی را به مصرف کنندگان مشترک در صف ها ارائه می دهد ، یا مصرف کنندگان پیام را از صف ها در صورت تقاضا دریافت می کنند.

هنگام انتشار پیام ، ناشران ممکن است ویژگی های مختلف پیام (پیام متا-داده) را مشخص کنند. برخی از این داده های متا ممکن است توسط کارگزار مورد استفاده قرار گیرد ، با این حال ، بقیه آن برای کارگزار کاملاً مات است و فقط توسط برنامه هایی که پیام را دریافت می کنند استفاده می شود.

شبکه ها غیرقابل اعتماد هستند و برنامه های کاربردی ممکن است در پردازش پیام ها ناکام باشند ، بنابراین مدل AMQP 0-9-1 دارای مفهوم تأیید پیام است: هنگامی که یک پیام به یک مصرف کننده تحویل داده می شود ، مصرف کننده به کارگزار اطلاع می دهد ، یا به طور خودکار یا به محض انتخاب برنامه نویس برنامهبرای انجام این کارهنگامی که تأیید پیام در حال استفاده است ، یک کارگزار فقط هنگام دریافت اعلان آن پیام (یا گروهی از پیام ها) ، پیام را از یک صف کاملاً حذف می کند.

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

صف ها ، مبادلات و اتصالات در مجموع به عنوان نهادهای AMQP گفته می شود.

AMQP 0-9-1 یک پروتکل قابل برنامه ریزی است

AMQP 0-9-1 یک پروتکل قابل برنامه ریزی است به این معنا که موجودیت های AMQP 0-9-1 و طرح های مسیریابی در درجه اول توسط خود برنامه ها تعریف می شوند، نه یک مدیر کارگزار. بر این اساس، برای عملیات پروتکلی که صف‌ها و مبادلات را اعلام می‌کنند، پیوندهای بین آنها را تعریف می‌کنند، صف‌ها را مشترک می‌کنند و غیره پیش بینی می‌شود.

این به توسعه دهندگان برنامه آزادی زیادی می دهد، اما همچنین باید از تضادهای بالقوه تعاریف آگاه باشند. در عمل، تعارض در تعریف نادر است و اغلب نشان دهنده یک پیکربندی نادرست است.

برنامه‌ها موجودیت‌های AMQP 0-9-1 را اعلام می‌کنند که به آن‌ها نیاز دارند، طرح‌های مسیریابی لازم را تعریف می‌کنند و ممکن است زمانی که دیگر استفاده نمی‌شوند، نهادهای AMQP 0-9-1 را حذف کنند.

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

صرافی ها موجودیت های AMQP 0-9-1 هستند که پیام ها به آنها ارسال می شود. صرافی ها یک پیام را دریافت می کنند و آن را به صف های صفر یا بیشتر هدایت می کنند. الگوریتم مسیریابی مورد استفاده بستگی به نوع تبادل و قوانینی به نام binding دارد. کارگزاران AMQP 0-9-1 چهار نوع مبادله را ارائه می دهند:

علاوه بر نوع تبادل، صرافی ها با تعدادی ویژگی اعلام می شوند که مهمترین آنها عبارتند از:

• نام
• دوام (صرافی ها از راه اندازی مجدد کارگزار جان سالم به در می برند)
• حذف خودکار (مبادله زمانی حذف می شود که آخرین صف از آن خارج شود)
• آرگومان ها (اختیاری، استفاده شده توسط پلاگین ها و ویژگی های خاص کارگزار)

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

صرافی پیش فرض

صرافی پیش فرض یک صرافی مستقیم بدون نام (رشته خالی) است که از قبل توسط کارگزار اعلام شده است. این یک ویژگی خاص دارد که آن را برای برنامه های ساده بسیار مفید می کند: هر صفی که ایجاد می شود به طور خودکار با یک کلید مسیریابی که همان نام صف است به آن متصل می شود.

به عنوان مثال ، هنگامی که شما یک صف را با نام "جستجو-ایندکس-اونلین" اعلام می کنید ، کارگزار AMQP 0-9-1 آن را با استفاده از "جستجو-ایندکسیک-آنلاین" به عنوان کلید مسیریابی ، آن را به مبادله پیش فرض وصل می کند (در این موردزمینه گاهی اوقات به عنوان کلید اتصال گفته می شود). بنابراین ، پیامی که با کلید Routing "جستجو-ایندکس-آن خط" به Exchange Default Exchange منتشر شده است ، به صف "جستجو-ایندکس-اونل" منتقل می شود. به عبارت دیگر ، مبادله پیش فرض به نظر می رسد که می توان پیام ها را مستقیماً به صف ها تحویل داد ، حتی اگر از نظر فنی آن چیزی نیست که اتفاق می افتد.

مبادله مستقیم

مبادله مستقیم پیام ها را به صف ها بر اساس کلید مسیریابی پیام ارائه می دهد. مبادله مستقیم برای مسیریابی تک تک پیام ها ایده آل است (اگرچه می توان از آنها برای مسیریابی چند مرحله ای نیز استفاده کرد). هم اکنون به چگونگی کارکرد آن می پردازیم:

• یک صف با کلید مسیریابی k به مبادله متصل می شود
• هنگامی که یک پیام جدید با مسیریابی کلید R به مبادله مستقیم می رسد ، مبادله اگر k = r آن را به صف منتقل کند

مبادلات مستقیم اغلب برای توزیع وظایف بین چندین کارگر (نمونه های یک برنامه مشابه) به روش دور رابین استفاده می شود. هنگام انجام این کار ، درک این نکته حائز اهمیت است که در AMQP 0-9-1 ، پیام ها بین مصرف کنندگان متعادل می شوند و نه بین صف ها.

مبادله مستقیم را می توان به صورت گرافیکی به شرح زیر نشان داد:

مبادله

یک تبادل فن پیام به تمام صف هایی که به آن محدود می شوند پیام می دهد و کلید مسیریابی نادیده گرفته می شود. اگر صف های N به یک مبادله طرفداری محدود شوند ، وقتی پیام جدیدی برای آن مبادله منتشر می شود ، یک نسخه از پیام به همه صف های n تحویل داده می شود. مبادلات فن برای مسیریابی پیام ها ایده آل است.

از آنجا که یک مبادله فن یک نسخه از پیام را به هر صف متصل به آن تحویل می دهد ، موارد استفاده آن کاملاً مشابه است:

• بازی های گسترده چند نفره آنلاین (MMO) می توانند از آن برای به روزرسانی های تابلوی یا سایر رویدادهای جهانی استفاده کنند
• سایت های خبری ورزشی می توانند از مبادلات فن برای توزیع به روزرسانی نمره به مشتریان تلفن همراه در زمان واقعی استفاده کنند
• سیستم های توزیع شده می توانند به روزرسانی های مختلف حالت و پیکربندی را پخش کنند
• گپ های گروهی می توانند پیام ها را بین شرکت کنندگان با استفاده از مبادله فن توزیع کنند (اگرچه AMQP مفهوم داخلی حضور ندارد ، بنابراین XMPP ممکن است انتخاب بهتری باشد)

مبادله فن می تواند به صورت گرافیکی به شرح زیر نشان داده شود:

مبادله موضوع

مبادلات مبادله پیام های مسیر را به یک یا بسیاری از صف ها بر اساس تطبیق بین کلید مسیریابی پیام و الگویی که برای اتصال یک صف به مبادله استفاده شده است ، مبادله می کند. از نوع مبادله موضوع اغلب برای اجرای تغییرات مختلف الگوی انتشار/مشترک استفاده می شود. مبادلات موضوع معمولاً برای مسیریابی چند مرحله ای از پیام ها استفاده می شود.

مبادلات موضوع مجموعه ای از موارد بسیار گسترده ای از موارد استفاده دارد. هر زمان که مشکلی شامل چندین مصرف کننده/برنامه ها باشد که به طور انتخابی انتخاب می کنند کدام نوع پیام ها را می خواهند دریافت کنند ، باید استفاده از مبادلات موضوع در نظر گرفته شود.

• توزیع داده های مربوط به موقعیت جغرافیایی خاص ، به عنوان مثال ، نقاط فروش
• پردازش کار پس زمینه انجام شده توسط چندین کارگر ، هر یک قادر به انجام مجموعه خاصی از کارها هستند
• به روزرسانی قیمت سهام (و به روزرسانی در مورد انواع دیگر داده های مالی)
• به روزرسانی های خبری که شامل طبقه بندی یا برچسب زدن است (به عنوان مثال ، فقط برای یک ورزش یا تیم خاص)
• ارکستر خدمات از انواع مختلف در ابر
• معماری توزیع شده/نرم افزار خاص سیستم عامل یا بسته بندی که در آن هر سازنده می تواند فقط یک معماری یا سیستم عامل را اداره کند

مبادله عناوین

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

با استفاده از بیش از یک هدر برای تطبیق ، می توان یک صف را به مبادله هدر وصل کرد. در این حالت ، کارگزار به یک بخش اطلاعات دیگر از توسعه دهنده برنامه نیاز دارد ، یعنی آیا باید پیام هایی را با هر یک از هدر تطبیق یا همه آنها در نظر بگیرد؟این همان چیزی است که استدلال الزام آور "X-Match" برای آن وجود دارد. هنگامی که استدلال "X-Match" روی "هر" تنظیم می شود ، فقط یک مقدار هدر تطبیق کافی است. از طرف دیگر ، تنظیم "X-Match" به "همه" دستورالعمل هایی که تمام مقادیر باید مطابقت داشته باشند.

برای "هر" و "همه" ، از هدر هایی که با رشته X شروع می شوند ، برای ارزیابی مسابقات استفاده نمی شوند. تنظیم "X-Match" به "Any-With-X" یا "All-With-X" همچنین از هدر استفاده می شود و از رشته X- برای ارزیابی مسابقات استفاده می شود.

مبادلات هدر را می توان به عنوان "مبادلات مستقیم در استروئیدها" مورد بررسی قرار داد. از آنجا که آنها بر اساس مقادیر هدر مسیر هستند ، می توانند به عنوان مبادلات مستقیم استفاده شوند که در آن کلید مسیریابی نیازی به یک رشته ندارد. به عنوان مثال می تواند یک عدد صحیح یا هش (فرهنگ لغت) باشد.

صف

صف در مدل AMQP 0-9-1 بسیار شبیه به صف در سایر سیستم های پیام و کار است: آنها پیام هایی را که توسط برنامه ها مصرف می شوند ، ذخیره می کنند. صف ها برخی از خصوصیات را با مبادلات به اشتراک می گذارند ، اما همچنین برخی از خصوصیات اضافی دارند:

• نام
• بادوام (صف از راه اندازی مجدد کارگزار زنده خواهد ماند)
• منحصر به فرد (فقط توسط یک اتصال استفاده می شود و هنگام بسته شدن این اتصال حذف می شود)
• AUTO-DELETE (صف که حداقل یک مصرف کننده داشته است ، هنگام عدم اشتراک مصرف کننده ، حذف می شود)
• آرگومان ها (اختیاری ؛ توسط افزونه ها و ویژگی های خاص کارگزار مانند پیام TTL ، حد طول صف و غیره استفاده می شود)

قبل از استفاده از صف ، باید اعلام شود. اعلام صف باعث ایجاد آن می شود اگر از قبل وجود نداشته باشد. اگر صف از قبل وجود داشته باشد و ویژگی های آن همانند اعلامیه باشد ، این اعلامیه هیچ تاثیری نخواهد داشت. هنگامی که ویژگی های صف موجود مانند موارد موجود در اعلامیه نیست ، یک استثناء در سطح کانال با کد 406 (پیش شرط_فیل) مطرح می شود.

نام های صف

برنامه ها ممکن است نام صف را انتخاب کنند یا از کارگزار بخواهند نامی را برای آنها ایجاد کند. نامهای صف ممکن است حداکثر 255 بایت کاراکتر UTF-8 باشد. یک کارگزار AMQP 0-9-1 می تواند یک نام منحصر به فرد از طرف یک برنامه ایجاد کند. برای استفاده از این ویژگی ، یک رشته خالی را به عنوان آرگومان نام صف منتقل کنید. نام تولید شده با پاسخ اعلامیه صف به مشتری بازگردانده می شود.

نامهای صف شروع شده با "AMQ". برای استفاده داخلی توسط کارگزار محفوظ است. تلاش برای اعلام صف با نامی که این قانون را نقض می کند ، منجر به استثناء سطح کانال با پاسخ کد 403 (Access_Refused) می شود.

دوام صف

در AMQP 0-9-1 ، صف ها را می توان با دوام یا گذرا اعلام کرد. ابرداده از یک صف با دوام روی دیسک ذخیره می شود ، در حالی که ابرداده یک صف گذرا در صورت امکان در حافظه ذخیره می شود.

همین تمایز برای پیام ها در زمان انتشار ایجاد شده است.

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

این موضوع در راهنمای صف ها به تفصیل تر پوشش داده شده است.

زلزله ها

اتصالات قوانینی هستند که مبادلات از آنها (از جمله موارد دیگر) برای هدایت پیام ها به صف استفاده می کنند. برای آموزش مبادله E برای ارسال پیام به صف q ، q باید به E. محدود شود. اتصال ممکن است دارای یک ویژگی کلید مسیریابی اختیاری باشد که توسط برخی از انواع مبادله استفاده می شود. هدف از کلید مسیریابی ، انتخاب برخی از پیام های منتشر شده در مبادله ای است که به صف محدود هدایت می شود. به عبارت دیگر ، کلید مسیریابی مانند یک فیلتر عمل می کند.

برای ترسیم قیاس:

• صف مانند مقصد شماست در شهر نیویورک
• مبادله مانند فرودگاه JFK است
• اتصالات مسیرهایی از JFK به مقصد شما هستند. راه های صفر یا بسیاری برای رسیدن به آن وجود دارد

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

اگر پیامی را نمی توان به هر صف منتقل کرد (به عنوان مثال ، زیرا هیچ اتصال برای مبادله ای که منتشر شده است وجود ندارد) بسته به ویژگی های پیام ناشر تنظیم شده است یا به ناشر بازگردانده می شود.

مصرف کننده

ذخیره پیام در صف ها بی فایده است مگر اینکه برنامه ها بتوانند آنها را مصرف کنند. در مدل AMQP 0-9-1 ، دو روش برای برنامه های کاربردی وجود دارد:

• مشترک شوید تا پیام های ارسال شده به آنها ("فشار API"): این گزینه توصیه شده است
• نظرسنجی ("Pull API"): از این طریق بسیار ناکارآمد است و در بیشتر موارد باید از آنها اجتناب کرد

با "فشار API" ، برنامه ها باید علاقه به مصرف پیام از یک صف خاص را نشان دهند. هنگامی که آنها این کار را انجام می دهند ، ما می گوییم که آنها یک مصرف کننده را ثبت می کنند یا به سادگی در یک صف مشترک می شوند. امکان داشتن بیش از یک مصرف کننده در هر صف یا ثبت نام مصرف کننده اختصاصی وجود دارد (تمام مصرف کنندگان دیگر را در حالی که مصرف می کند ، از صف خارج می کند).

هر مصرف کننده (اشتراک) دارای شناسه ای به نام برچسب مصرف کننده است. می توان از آن برای لغو اشتراک از پیام ها استفاده کرد. برچسب های مصرف کننده فقط رشته ها هستند.

تأیید پیام

برنامه های مصرف کننده - یعنی برنامه هایی که پیام های دریافت و پردازش را دریافت می کنند - ممکن است گهگاه نتوانند پیام های فردی را پردازش کنند یا گاهی اوقات فقط خراب می شوند. همچنین امکان مشکلات شبکه ایجاد مشکل وجود دارد. این یک سؤال را ایجاد می کند: چه زمانی کارگزار باید پیام ها را از صف ها حذف کند؟مشخصات AMQP 0-9-1 به مصرف کنندگان این امر را کنترل می کند. دو حالت تأیید وجود دارد:

• پس از کارگزار پیامی را به یک برنامه (با استفاده از روش basic. deliver یا basic. get-ok) ارسال می کند.
• پس از ارسال برنامه ، یک تأیید (با استفاده از روش basic. ack) ارسال می شود.

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

اگر یک مصرف کننده بدون ارسال تصدیق بمیرد ، کارگزار آن را به یک مصرف کننده دیگر تغییر می دهد یا اگر هیچ کس در آن زمان در دسترس نباشد ، کارگزار منتظر خواهد ماند تا حداقل یک مصرف کننده قبل از تلاش مجدد برای همان صف ثبت شود.

رد پیام ها

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

تصدیق منفی

پیام ها با روش basic. reject رد می شوند. یک محدودیت وجود دارد که Basic. Reject دارد: هیچ راهی برای رد پیام های متعدد وجود ندارد ، همانطور که می توانید با تصدیق انجام دهید. با این حال ، اگر از RabbitMQ استفاده می کنید ، یک راه حل وجود دارد. RabbitMQ یک برنامه افزودنی AMQP 0-9-1 را ارائه می دهد که به عنوان تأیید منفی یا NACKS شناخته می شود. برای اطلاعات بیشتر ، لطفاً به تأییدیه ها و راهنماهای پس زمینه BASIC. NACK مراجعه کنید.

پیام های مقدماتی

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

توجه داشته باشید که RabbitMQ فقط از پیش نمایش سطح کانال پشتیبانی می کند ، نه از پیش تنظیم اتصال یا اندازه مبتنی بر اندازه.

ویژگی های پیام و بارگذاری

پیام های موجود در مدل AMQP 0-9-1 دارای ویژگی هایی هستند. برخی از ویژگی ها به حدی متداول هستند که مشخصات AMQP 0-9-1 آنها را تعریف می کند و توسعه دهندگان برنامه نیازی به فکر کردن در مورد نام دقیق ویژگی ندارند. چند نمونه است

• نوع محتوا
• رمزگذاری محتوا
• کلید مسیریابی
• حالت تحویل (پایدار یا نه)
• اولویت پیام
• زمان انتشار انتشار پیام
• دوره انقضا
• شناسه برنامه ناشر

برخی از ویژگی ها توسط کارگزاران AMQP استفاده می شود ، اما بیشتر آنها برای تفسیر توسط برنامه هایی که آنها را دریافت می کنند ، باز هستند. برخی از ویژگی ها اختیاری هستند و به عنوان هدر شناخته می شوند. آنها در HTTP شبیه به X-Headers هستند. ویژگی های پیام هنگام انتشار پیام تنظیم می شوند.

پیام ها همچنین دارای بار (داده هایی هستند که آنها حمل می کنند) ، که کارگزاران AMQP به عنوان یک آرایه بایت مات رفتار می کنند. کارگزار بار را بازرسی یا اصلاح نمی کند. این امکان وجود دارد که پیام ها فقط دارای ویژگی ها و بدون بار باشند. استفاده از قالب های سریال سازی مانند JSON ، THRIFT ، بافر پروتکل و MessagePack برای سریال سازی داده های ساختار یافته به منظور انتشار آن به عنوان بار پیام است. همسالان پروتکل به طور معمول برای برقراری ارتباط با این اطلاعات از زمینه های "نوع محتوا" و "رمزگذاری محتوا" استفاده می کنند ، اما این فقط توسط کنوانسیون است.

پیام ها ممکن است به صورت مداوم منتشر شوند ، که باعث می شود کارگزار آنها را به دیسک ادامه دهد. اگر سرور مجدداً راه اندازی شود ، سیستم تضمین می کند که پیام های مداوم دریافت نشده از بین نرود. به سادگی انتشار یک پیام به یک تبادل بادوام یا این واقعیت که صف (های) که از آن استفاده می شود بادوام است ، پیامی را پایدار نمی کند: همه اینها به حالت پایداری پیام بستگی دارد. انتشار پیام ها به عنوان مداوم بر عملکرد تأثیر می گذارد (دقیقاً مانند فروشگاه های داده ، دوام با هزینه خاصی در عملکرد ارائه می شود).

تأیید پیام

از آنجا که شبکه ها غیرقابل اعتماد هستند و برنامه های کاربردی از بین می روند ، اغلب لازم است نوعی تأیید پردازش داشته باشید. بعضی اوقات فقط لازم است که این واقعیت را دریافت کنید که یک پیام دریافت شده است. گاهی اوقات اذعان به این معنی است که یک پیام توسط یک مصرف کننده تأیید و پردازش شده است ، به عنوان مثال ، به عنوان داشتن داده های اجباری تأیید شده و به یک فروشگاه داده ادامه می یابد یا فهرست بندی می شود.

این وضعیت بسیار متداول است ، بنابراین AMQP 0-9-1 دارای یک ویژگی داخلی به نام تأیید پیام (که بعضاً به عنوان ACK ها گفته می شود) است که مصرف کنندگان برای تأیید تحویل پیام و/یا پردازش استفاده می کنند. اگر یک برنامه خراب شود (کارگزار AMQP هنگام بسته شدن اتصال ، این موضوع را متوجه می شود) ، اگر تأییدیه برای یک پیام انتظار می رود اما توسط کارگزار AMQP دریافت نشده است ، این پیام مجدداً مورد استفاده قرار می گیرد (و احتمالاً بلافاصله در صورت وجود به مصرف کننده دیگر تحویل داده می شود. وجود دارد)

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

روشهای AMQP 0-9-1

AMQP 0-9-1 به عنوان تعدادی از روش ها ساختار یافته است. روشها عملیاتی هستند (مانند روشهای HTTP) و هیچ ارتباطی با روشهای در زبانهای برنامه نویسی شی گرا ندارند. روشهای پروتکل در AMQP 0-9-1 به کلاس ها گروه بندی می شوند. کلاس ها فقط گروه های منطقی روشهای AMQP هستند. مرجع AMQP 0-9-1 جزئیات کاملی از همه روشهای AMQP دارد.

بگذارید نگاهی به کلاس Exchange ، گروهی از روش های مربوط به عملیات مبادله ها بیندازیم. این شامل عملیات زیر است:

• Exchange. Declare
• Exchange. Declare-OK
• Exchange. Delete
• Exchange. Delete-OK

(توجه داشته باشید که مرجع سایت RabbitMQ همچنین شامل پسوندهای خاص RabbitMQ به کلاس Exchange است که در این راهنما بحث نخواهیم کرد).

عملیات فوق جفت های منطقی: Exchange. declare and Exchange. declare-OK ، Exchange. delete و Exchange. delete-OK. این عملیات "درخواست ها" (ارسال شده توسط مشتری) و "پاسخ ها" (ارسال شده توسط کارگزاران در پاسخ به "درخواست های" فوق) است.

به عنوان نمونه ، مشتری از کارگزار می خواهد با استفاده از روش Exchange. declare مبادله جدیدی را اعلام کند:

همانطور که در نمودار بالا نشان داده شده است ، Exchange. declare چندین پارامتر دارد. آنها مشتری را قادر می سازند نام ، نوع ، پرچم دوام و غیره را مشخص کنند.

اگر عملیات موفق شود ، کارگزار با روش Exchange. declare-OK پاسخ می دهد:

Exchange. Declare-OK به جز شماره کانال هیچ پارامتر حمل نمی کند (کانال ها بعداً در این راهنما توضیح داده می شوند).

دنباله وقایع برای یک جفت روش دیگر در کلاس روش AMQP 0-9-1 بسیار مشابه است: queue. declare و queue. declare-ok:

همه روشهای AMQP 0-9-1 همتایان ندارند. برخی (Basic. Publish که به طور گسترده ترین استفاده می شود) روشهای "پاسخ" مربوطه و برخی دیگر (به عنوان مثال Basic. get) بیش از یک "پاسخ" ممکن ندارند.

اتصالات

اتصالات AMQP 0-9-1 به طور معمول طولانی مدت است. AMQP 0-9-1 یک پروتکل سطح برنامه است که از TCP برای تحویل قابل اعتماد استفاده می کند. اتصالات از تأیید اعتبار استفاده می کنند و با استفاده از TLS می توانند محافظت شوند. هنگامی که یک برنامه دیگر نیازی به اتصال به سرور نداشته باشد ، باید به جای بستن ناگهانی اتصال TCP ، اتصال AMQP 0-9-1 خود را ببندد.

کانال

برخی از برنامه ها به ارتباطات متعدد به کارگزار نیاز دارند. با این حال ، نگه داشتن بسیاری از اتصالات TCP در همان زمان نامطلوب است زیرا انجام این کار منابع سیستم را مصرف می کند و پیکربندی فایروال ها را دشوارتر می کند. اتصالات AMQP 0-9-1 با کانال هایی که می توان به عنوان "اتصالات سبک وزن که یک اتصال TCP را به اشتراک می گذارند" چند برابر شوند.

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

یک کانال فقط در زمینه اتصال وجود دارد و هرگز به تنهایی وجود ندارد. وقتی اتصال بسته شد ، همه کانال های آن نیز هستند.

برای برنامه هایی که از چندین موضوع/فرآیند برای پردازش استفاده می کنند ، باز کردن کانال جدید در هر موضوع/فرآیند بسیار معمول است و کانال های بین آنها را به اشتراک نگذارید.

میزبان مجازی

این امکان را برای یک کارگزار واحد فراهم می کند که میزبان چندین "محیط" جدا شده (گروه هایی از کاربران ، مبادلات ، صف ها و غیره) باشد ، AMQP 0-9-1 شامل مفهوم میزبان های مجازی (VHOSTS) است. آنها مشابه میزبان های مجازی هستند که توسط بسیاری از سرورهای وب محبوب مورد استفاده قرار می گیرند و محیط های کاملاً جدا شده ای را ارائه می دهند که در آن نهادهای AMQP زندگی می کنند. مشتری های پروتکل مشخص می کنند که چه مواردی را می خواهند در هنگام مذاکره اتصال از آنها استفاده کنند.

AMQP قابل گسترش است

AMQP 0-9-1 دارای چندین نقطه پسوند است:

به توسعه دهندگان اجازه دهید طرح های مسیریابی را اجرا کنند که انواع تبادل ارائه شده خارج از جعبه به خوبی پوشش نمی دهند ، به عنوان مثال ، مسیریابی مبتنی بر ژئوداتا.
• اعلامیه مبادلات و صف ها می تواند شامل ویژگی های اضافی باشد که کارگزار می تواند از آن استفاده کند. به عنوان مثال ، پیام هر صف TTL در RabbitMQ به این روش اجرا می شود.
• پسوندهای خاص کارگزار به پروتکل. به عنوان مثال ، پسوندهایی را که RabbitMQ پیاده سازی می کند ، ببینید. می توان معرفی کرد
• کارگزاران را می توان با افزونه های اضافی گسترش داد ، به عنوان مثال ، RabbitMQ Management Frontend و HTTP API به عنوان یک افزونه اجرا می شوند.

این ویژگی ها مدل AMQP 0-9-1 را حتی انعطاف پذیر تر و کاربردی برای طیف گسترده ای از مشکلات می کند.

AMQP 0-9-1 مشتری اکوسیستم

بسیاری از مشتری های AMQP 0-9-1 برای بسیاری از زبانها و سیستم عامل های برنامه نویسی محبوب وجود دارد. برخی از آنها اصطلاحات AMQP را از نزدیک دنبال می کنند و فقط اجرای روش های AMQP را ارائه می دهند. برخی دیگر از ویژگی های اضافی ، روش های راحتی و انتزاع برخوردار هستند. برخی از مشتری ها ناهمزمان (غیر مسدود کننده) هستند ، برخی همزمان (مسدود کننده) هستند ، برخی از هر دو مدل پشتیبانی می کنند. برخی از مشتریان از پسوندهای خاص فروشنده پشتیبانی می کنند (به عنوان مثال ، پسوندهای خاص RabbitMQ).

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

کمک و ارائه بازخورد

اگر در مورد محتوای این راهنما یا هر موضوع دیگری که مربوط به RabbitMQ است ، سؤالی دارید ، دریغ نکنید که از آنها در لیست پستی RabbitMQ سؤال کنید.

به ما در بهبود اسناد کمک کنید

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