صف

این راهنما نمای کلی از صف در RabbitMQ را ارائه می دهد. از آنجا که بسیاری از ویژگی های موجود در یک سیستم پیام رسانی به صف ها مربوط می شود ، به معنای این نیست که یک راهنمای جامع باشد بلکه یک مرور کلی است که پیوندهایی را به سایر راهنماهای ارائه می دهد.

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

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

جریان یک ساختار داده پیام رسانی جایگزین موجود در RabbitMQ است. جریان ها ویژگی های مختلفی را از صف ها ارائه می دهند.

برخی از مباحث کلیدی که در این راهنما پوشیده شده است

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

برای مباحث مربوط به مصرف کنندگان ، به راهنمای مصرف کنندگان مراجعه کنید. صف ها و جریان های Quorum همچنین راهنماهای اختصاصی دارند.

اصول اولیه

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

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

نام

صف ها دارای اسامی هستند تا برنامه ها بتوانند به آنها مراجعه کنند.

برنامه های کاربردی ممکن است نام صف را انتخاب کنند یا از کارگزار بخواهند نامی برای آنها ایجاد کند. نامهای صف ممکن است حداکثر 255 بایت کاراکتر UTF-8 باشد.

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

صف های با نام سرور

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

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

خواص

صف ها دارای خواصی هستند که نحوه رفتار آنها را تعریف می کنند. مجموعه ای از خصوصیات اجباری و نقشه ای از اختیاری وجود دارد:

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

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

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

اعلامیه و هم ارزی اموال

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

استدلال های اختیاری

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

این نقشه توسط ویژگی ها و افزونه های مختلفی مانند استفاده می شود

• نوع صف (به عنوان مثال سهمیه یا کلاسیک)
• پیام و صف TTL
• حد مجاز طول صف
• حداکثر تعداد اولویت ها
• اولویت های مصرف کننده

بیشتر استدلال های اختیاری پس از اعلام صف قابل تغییر است اما استثنائاتی وجود دارد. به عنوان مثال ، نوع صف (X-Queue-Type) و حداکثر تعداد اولویت های صف (-اورتریت X-Max) باید در زمان اعلامیه صف تنظیم شوند و پس از آن قابل تغییر نیست.

استدلال های صف اختیاری را می توان از چند طریق تنظیم کرد:

• به گروه های صف با استفاده از سیاست ها (توصیه می شود)
• بر اساس هر صف وقتی که یک صف توسط مشتری اعلام می شود

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

نحوه ارائه آرگومان های اختیاری توسط مشتری از کتابخانه مشتری تا کتابخانه مشتری متفاوت است اما معمولاً استدلال در کنار دوام ، auto_delete و سایر آرگومان های عملکرد (روش) است که صف ها را اعلام می کند.

سفارش پیام

صف در RabbitMQ به مجموعه پیام ها سفارش داده می شود. پیام ها به صورت FIFO به صورت فیوکو مورد استفاده قرار می گیرند و (به مصرف کنندگان تحویل داده می شوند).

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

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

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

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

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

دوام

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

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

صف های گذرا در بوت گره حذف می شوند. بنابراین آنها با طراحی ، از راه اندازی مجدد گره زنده نمی مانند. پیام ها در صف های گذرا نیز دور ریخته می شوند.

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

نحوه انتخاب

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

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

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

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

صف های موقت

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

سه راه برای حذف خودکار صف وجود دارد:

• صف های انحصاری (زیر پوشش داده شده است)
• TTLها (همچنین در زیر پوشش داده شده است)
• حذف خودکار صف ها

یک صف حذف خودکار زمانی که آخرین مصرف کننده آن لغو شود (مثلاً با استفاده از basic. cancel در AMQP 0-9-1) یا از بین برود (کانال یا اتصال بسته شده یا اتصال TCP با سرور از بین می رود) حذف می شود.

برای مثال، اگر یک صف هرگز مصرف کننده ای نداشته باشد، به عنوان مثال، وقتی تمام مصرف با استفاده از روش basic. get (API "کشش") اتفاق می افتد، به طور خودکار حذف نمی شود. برای چنین مواردی از صف های انحصاری یا صف TTL استفاده کنید.

صف های انحصاری

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

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

ایجاد صف های انحصاری با نام سرور معمول است.

بدون توجه به مقدار queue_master_locator، صف های انحصاری بر روی گره "client-local" (گرهی که مشتری که صف را به آن وصل می کند) اعلام می شود.

صف های تکراری و توزیع شده

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

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

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

جریان یکی دیگر از ساختار داده های تکرار شده است که توسط RabbitMQ پشتیبانی می شود ، با مجموعه ای متفاوت از عملیات و ویژگی های پشتیبانی شده.

محدودیت زمان به زندگی و طول

صف ها می توانند طول خود را محدود کنند. صف ها و پیام ها می توانند TTL داشته باشند.

هر دو ویژگی را می توان برای انقضاء داده ها استفاده کرد و به عنوان راهی برای محدود کردن تعداد منابع (RAM ، فضای دیسک) یک صف می تواند حداکثر استفاده کند ، به عنوان مثال. هنگامی که مصرف کنندگان آفلاین می شوند یا توان آنها در پشت ناشران قرار می گیرد.

در حافظه و ذخیره دوام

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

انتشار پیام ها به عنوان گذرا نشان می دهد که RabbitMQ باید پیام های زیادی را در RAM نگه دارد. با این حال ، صف ها حتی پیام های گذرا به دیسک را در هنگام یافتن خود تحت فشار حافظه قرار می دهند.

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

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

اولویت های

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

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

اگر صف اولویت مورد نظر باشد ، توصیه می کنیم از 1 تا 10 استفاده کنید. در حال حاضر استفاده از اولویت های بیشتر منابع بیشتری را مصرف می کند (فرآیندهای ارلانگ).

استفاده از CPU و ملاحظات موازی

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

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

معیارها و نظارت

RabbitMQ چندین معیارهای مربوط به صف ها را جمع می کند. بسیاری از آنها از طریق RabbitMQ HTTP API و UI مدیریت موجود است که برای نظارت طراحی شده است. این شامل طول صف ، نرخ ورود و خروج ، تعداد مصرف کنندگان ، تعداد پیام ها در ایالت های مختلف (به عنوان مثال آماده برای تحویل یا عدم دسترسی) ، تعداد پیام های RAM در مقابل دیسک و غیره است.

RabbitMQCTL می تواند صف ها و برخی از معیارهای اساسی را لیست کند.

معیارهای زمان اجرا مانند استفاده از برنامه ریز VM ، فرآیند GC فرآیند GC ، Queue (Erlang) ، مقدار RAM که توسط فرآیند صف استفاده می شود ، می توان با استفاده از افزونه RabbitMQ-Top و صفحات صف های شخصی در UI مدیریت ، طول صندوق پستی صف را دسترسی پیدا کرد.

مصرف کنندگان و تصدیق

پیام ها را می توان با ثبت نام مصرف کننده (اشتراک) مصرف کرد ، به این معنی که RabbitMQ پیام ها را به مشتری فشار می دهد ، یا به طور جداگانه برای پروتکل هایی که از این پشتیبانی می کنند (به عنوان مثال روش Basic. get AMQP 0-9-1) ، به طور مشابه با HTTP دریافت می کنند.

به محض اینکه تحویل به سوکت اتصال ارسال می شود ، پیام های تحویل شده را می توان به طور صریح یا به طور خودکار تصدیق کرد.

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

پیش تنظیم و اضافه بار مصرف کننده

حالت تأیید خودکار همچنین می تواند مصرف کنندگان را تحت الشعاع قرار دهد که نمی توانند پیام ها را به سرعت تحویل دهند. این می تواند منجر به رشد دائمی حافظه و/یا تعویض سیستم عامل برای روند مصرف کننده شود.

حالت تأیید دستی راهی برای تعیین محدودیت در تعداد تحویل های برجسته (تأیید نشده): کانال QoS (prefetch) فراهم می کند.

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

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

پیام ها بیان می کنند

بنابراین پیام های Enqueed می توانند در یکی از دو ایالت قرار بگیرند:

• آماده برای تحویل
• تحویل داده شده اما هنوز توسط مصرف کننده تصدیق نشده است

تجزیه پیام توسط ایالت را می توان در UI مدیریت یافت.

تعیین طول صف

تعیین طول صف از چند طریق امکان پذیر است:

• با AMQP 0-9-1 ، با استفاده از یک ویژگی در پاسخ روش queue. declare (queue. declare-ok). نام فیلد Message_Count است. نحوه دسترسی به آن از کتابخانه مشتری تا کتابخانه مشتری متفاوت است.
• با استفاده از API RabbitMQ HTTP.
• با استفاده از دستور RabbitMQCTL List_queues.

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

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

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

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

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