صف های سهمیه

Quorum queue یک نوع صف مدرن برای RabbitMQ است که یک صف FIFO با دوام و تکرار شونده را بر اساس الگوریتم اجماع RAFT اجرا می کند. از طریق RabbitMQ 3. 8. 0 موجود است.

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

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

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

برخی از ویژگی ها ، مانند دست زدن به پیام سم ، مخصوص صف های سهمیه است.

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

بررسی اجمالی

مباحث تحت پوشش این راهنما شامل می شود

• و چرا آنها از صف های کلاسیک معرفی شدند
• موارد استفاده اولیه از صف های سهمیه و در هنگام استفاده از آنها
• چگونه می توان مباحث مربوط به صف quorum را اعلام کرد: مدیریت ماکت ، بازگرداندن رهبر ماکت ، تعداد بهینه ماکت ها و غیره
• آنچه صف های سهمیه را از نظر عدم موفقیت رهبری ، ایمنی داده ها و ویژگی های در دسترس بودن ارائه شده توسط صف های Quorum از صف های سهمیه تضمین می کند
• استفاده از منابع از صف quorum ، از همه مهمتر ردپای حافظه آنها

این راهنما آشنایی کلی با خوشه بندی RabbitMQ را فرض می کند.

انگیزه

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

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

سهمیه چیست؟

اگر عمداً ساده شود ، سهمیه در یک سیستم توزیع شده می تواند به عنوان توافق بین اکثر گره ها ((N/2) +1 که N تعداد کل شرکت کنندگان در سیستم است) تعریف شود.

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

تفاوت از صف های آینه ای کلاسیک

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

تفاوت ها در این راهنما پوشش داده شده است.

صف های آینه ای کلاسیک در RabbitMQ محدودیت های فنی دارند که ارائه ضمانت های قابل فهم و پاکسازی معناشناسی را دشوار می کند.

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

مقایسه ویژگی با صف های منظم

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

عملیات زیر به همان روش برای صف های Quorum همانطور که برای صف های منظم انجام می شود کار می کند:

• مصرف (اشتراک) (به جز QoS جهانی و prefetch)
• لغو مصرف کنندگان
• پاکسازی
• حذف

با برخی از عملیات صف تفاوت های جزئی وجود دارد:

برخی از ویژگی ها در حال حاضر توسط صف های Quorum پشتیبانی نمی شوند.

ماتریس

صف های Quorum مدرن همچنین برای بسیاری از بارهای کاری توان بالاتری و تنوع تأخیر کمتری را ارائه می دهد.

صف های بدون بادوام

صف های منظم می توانند غیر بادوام باشند. صف های Quorum همیشه در مورد موارد استفاده فرض شده آنها بادوام است.

انحصار

صف های منحصر به فرد با چرخه عمر اتصال اعلام کننده آنها گره خورده است. صف های Quorum با طراحی تکرار و بادوام هستند ، بنابراین خاصیت منحصر به فرد در متن آنها معنی ندارد. بنابراین صف های سهمیه نمی توانند منحصر به فرد باشند.

صف های Quorum به عنوان صف های موقتی مورد استفاده قرار نمی گیرد.

TTL (قبل از RabbitMQ 3. 10)

صف های Quorum از صف پشتیبانی TTL پشتیبانی می کنند ، اما از پیام TTL پشتیبانی نمی کنید.

TTL (از زمان RabbitMQ 3. 10)

صف های Quorum از هر دو صف TTL و پیام TTL (از جمله پیام هر Queue TTL در صف ها و TTL در هر پیام در ناشران) پشتیبانی می کنند. هنگام استفاده از هر نوع پیام TTL ، سربار حافظه 2 بایت در هر پیام افزایش می یابد.

حد مجاز طول

صف QUORUM از محدودیت های طول صف پشتیبانی دارد.

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

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

حروف مرده

صف های Quorum از مبادلات نامه مرده پشتیبانی می کنند (DLX).

به طور سنتی ، استفاده از DLX در یک محیط خوشه ای بی خطر نبوده است.

از آنجا که صف های Quorum RabbitMQ 3. 10 از یک شکل ایمن تر از مرگ و میر پشتیبانی می کند که از ضمانت های حداقل یک باره برای انتقال پیام بین صف ها استفاده می کند (با محدودیت ها و احتیاط های ذکر شده در زیر).

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

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

در هر زمان ، پیش فرض استراتژی Dead-Letter برای صف های Quorum باقی مانده است و برای سناریوهایی که پیام های Dead Lettered بیشتر از یک ماهیت اطلاعاتی هستند و در آنجا مهم نیست اگر در حمل و نقل بین صف ها از بین بروند یا چه زمانی اهمیتی نمی دهد. محدودیت پیکربندی سرریز ذکر شده در زیر مناسب نیست.

فعال کردن حداقل در یک زمان مرده

برای فعال کردن حداقل نامه مرده AT-once برای یک صف سهمیه منبع ، تمام خط مشی های زیر را اعمال کنید (یا آرگومان های معادل صف شروع از X-):

• استراتژی Dead-Letter را روی Least-once قرار دهید (پیش فرض در یک بارداری است).
• سرریز را برای رد نشر تنظیم کنید (پیش فرض قطره ای است).
• تبادل برگه مرده را پیکربندی کنید.
• ویژگی FALL FLAG STREAM_QUEUE را فعال کنید (به طور پیش فرض برای خوشه های RabbitMQ ایجاد شده در 3. 9 یا بالاتر).

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

به صورت اختیاری ، یک کلید با رونق-کشته شده را پیکربندی کنید.

محدودیت ها

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

احتیاط

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

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

پیامهای با ضایعات مرده "زنده" در نظر گرفته می شوند تا زمانی که توسط صف (های) هدف مرده تأیید نشده باشند.

موارد کمی وجود دارد که پیام های نامه ای مرده به موقع از صف منبع حذف نمی شوند:

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

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

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

در صورت نیاز به توان پایین (هزاران پیام در ثانیه) ، می توان با تنظیمات Dead_letter_Worker_Consumer_Prefetch در بخش برنامه خرگوش پرونده پیکربندی پیشرفته افزایش یافت.

برای یک صف QUORUM منبع ، می توان استراتژی نامه مرده را به صورت پویا از at-once به حداقل یکپارچه و برعکس تغییر داد. اگر استراتژی کشته شده یا به طور مستقیم از حداقل یک باره به یکپارچه یا غیرمستقیم تغییر یابد ، به عنوان مثال با تغییر سرریز از رد کردن به سمت قطره ، هر پیام مرده ای که هنوز تأیید نشده استتوسط تمام صف های هدف حذف می شود.

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

حالت تنبل (از آنجا که RabbitMQ 3. 10)

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

پیکربندی حد حافظه هنوز مجاز است اما هیچ تاثیری ندارد. تنها گزینه اکنون به طور موثری همان پیکربندی است: X-Max-in-Memory-length = 0

حالت تنبل (قبل از RabbitMQ 3. 10)

صف های Quorum محتوای خود را بر روی دیسک (در هر مورد نیاز قایق) و همچنین در حافظه ذخیره می کنند (تا حد حافظه پیکربندی شده).

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

QoS جهانی

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

از PREFETCH AR-CONSUMER QOS استفاده کنید ، که به طور پیش فرض در چندین مشتری محبوب است.

اولویت های

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

رسیدگی به پیام سمی

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

حمایت سیاسی

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

موارد استفاده

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

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

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

ناشران باید از تأیید ناشر استفاده کنند زیرا اینگونه است که مشتریان می توانند با سیستم اجماع Quorum در تعامل باشند. ناشر تأیید می کند که فقط پس از انتشار پیام منتشر شده با موفقیت در سهمیه گره ها صادر می شود و در چارچوب سیستم "ایمن" تلقی می شود.

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

هنگام استفاده از صف quorum

در بعضی موارد نباید از صف های سهمیه استفاده شود. آنها به طور معمول شامل:

• ماهیت موقت صف ها: صف های گذرا یا منحصر به فرد ، صف بالا در صف بالا (نرخ اعلامیه و حذف)
• کمترین تأخیر ممکن: الگوریتم اجماع اساسی به دلیل ویژگی های ایمنی داده های خود دارای تأخیر ذاتاً بالاتر است
• هنگامی که ایمنی داده ها اولویت نیست (به عنوان مثال برنامه ها از تأییدیه های دستی استفاده نمی کنند و ناشر تأیید نمی شود)
• باقیمانده صف بسیار طولانی (جریان ها احتمالاً مناسب تر هستند)

استفاده

همانطور که قبلاً گفته شد ، صف های Quorum بیشتر اصول را با سایر انواع صف به اشتراک می گذارند. یک کتابخانه مشتری که می تواند آرگومان های صف اختیاری را مشخص کند ، قادر به استفاده از صف های Quorum خواهد بود.

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

اعلام

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

اعلام یک صف با آرگومان نوع x-queue تنظیم شده به حد نصاب، یک صف حد نصاب را با حداکثر پنج تکرار (ضریب تکرار پیش فرض)، یکی در هر گره خوشه اعلام می کند.

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

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

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

عملیات مشتری

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

• (اشتراک) (محدودیت های واکشی اولیه QoS را در نظر داشته باشید)
• لغو مصرف کنندگان
• پاکسازی پیام های صف
• حذف صف

با برخی از عملیات صف تفاوت های جزئی وجود دارد:

• (پوشش بالا)
• تنظیم پیش واکشی QoS برای مصرف کنندگان

تکرار و محل داده

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

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

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

کنترل ضریب تکرار اولیه

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

مانند صف های آینه ای کلاسیک، ضریب تکرار (تعداد کپی هایی که یک صف دارد) را می توان برای صف های حد نصاب پیکربندی کرد.

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

این ممکن است برای خوشه های بزرگتر یا خوشه ای با تعداد حتی گره ها مطلوب نباشد. برای کنترل تعداد اعضای صف quorum ، هنگام اعلام صف ، آرگومان صف X-initial-initial-initial را تنظیم کرد. آرگومان اندازه گروه ارائه شده باید یک عدد صحیح باشد که از صفر و کوچکتر یا مساوی با اندازه خوشه خرگوش فعلی باشد. صف quorum برای اجرای زیر مجموعه تصادفی از گره های RabbitMQ موجود در خوشه در زمان اعلامیه راه اندازی می شود.

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

مکان رهبر صف

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

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

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

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

1. تنظیم کلید خط مشی خط رهبر-رهبر (توصیه شده)
2. با تعریف کلید queue_leader_locator در پرونده پیکربندی (توصیه شده)
3. با استفاده از آرگومان صف اختیاری X-que-Leader-Locator

مقادیر یاب رهبر صف پشتیبانی پشتیبانی می شوند

• Client-Local: گره ای را انتخاب کنید که صف را اعلام می کند به آن متصل است. این مقدار پیش فرض است.
• متعادل: اگر در مجموع کمتر از 1000 صف (صف های کلاسیک، صف های حد نصاب و استریم ها) وجود دارد، گرهی را انتخاب کنید که میزبان حداقل تعداد رهبران صف حد نصاب است. اگر به طور کلی بیش از 1000 صف وجود دارد، یک گره تصادفی انتخاب کنید.

مدیریت کپی ها (اعضای گروه حد نصاب)

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

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

چندین دستور CLI برای انجام عملیات فوق ارائه شده است:

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

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

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

توازن مجدد کپی ها

پس از اعلام، رهبران صف حد نصاب RabbitMQ ممکن است به طور نابرابر در سراسر خوشه RabbitMQ توزیع شوند. برای تعادل مجدد از دستور rabbitmq-queues rebalance استفاده کنید. نکته: این گره هایی را که صف های حد نصاب در آن قرار دارند تغییر نمی دهد. برای تغییر عضویت به جای آن به مدیریت کپی ها مراجعه کنید.

تعادل مجدد زیرمجموعه ای از صف های انتخاب شده با نام امکان پذیر است:

یا صف های حد نصاب در مجموعه خاصی از میزبان های مجازی:

رفتار - اخلاق

یک صف حد نصاب بر پروتکل توافقی به نام Raft برای اطمینان از ثبات و ایمنی داده ها متکی است.

هر صف حد نصاب دارای یک ماکت اولیه (یک لیدر در اصطلاح Raft) و صفر یا بیشتر ماکت ثانویه (به نام فالوور) است.

یک رهبر زمانی انتخاب می شود که خوشه ابتدا تشکیل شود و بعداً اگر رهبر در دسترس نباشد.

انتخاب رهبر و مدیریت شکست

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

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

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

تحمل خطا و حداقل تعداد کپی آنلاین

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

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

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

برای اندازه های گره صف نصاب بزرگتر از 5، عملکرد کمی کاهش می یابد. ما اجرای صف های حد نصاب را در بیش از 7 گره RabbitMQ توصیه نمی کنیم. اندازه پیش فرض صف حد نصاب 3 است و با استفاده از آرگومان صف x-quorum-initial-group-size قابل کنترل است.

ایمنی داده ها

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

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

هیچ تضمینی برای پیام هایی ارائه نشده است که با استفاده از مکانیسم تأیید ناشر تأیید نشده اند. چنین پیام هایی را می توان "میانه راه" ، در یک بافر سیستم عامل از بین برد یا در غیر این صورت نتوانست به رهبر صف برسد.

دسترسی

یک صف سهمیه باید بتواند اقلیت اعضای صف را تحمل کند و بدون تأثیر کمی در دسترس بودن در دسترس نباشد.

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

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

اگر یک سهم از گره ها قابل بازیابی نباشد (بگویید اگر 2 از 3 گره RabbitMQ به طور دائم از بین برود) صف به طور دائم در دسترس نیست و نیاز به حذف و بازآفرینی دارد.

quorum queue pollower ماکت هایی که از رهبر جدا شده اند یا در انتخابات رهبر شرکت می کنند ، عملیات صف ارسال شده به آن را نادیده می گیرد تا اینکه از یک رهبر تازه انتخاب شده آگاه شوند. در مورد چنین رویدادهایی هشدارهایی در ورود به سیستم (دریافت شده MSG و مشابه) وجود خواهد داشت. به محض اینکه ماکت یک رهبر تازه منتخب را کشف کرد ، ورودی های مربوط به عملیات صف را که از رهبر ، از جمله افراد افتاده ، همگام سازی می کند ، همگام می کند. بنابراین وضعیت صف quorum سازگار خواهد بود.

خصوصیات عملکرد

صف های QUORUM برای تجارت تأخیر برای توان طراحی شده اند و در برابر صف های آینه ای کلاسیک با دوام در تنظیمات گره 3 ، 5 و 7 در چندین اندازه پیام مورد آزمایش و مقایسه قرار گرفته اند.

در سناریوها با استفاده از هر دو ACK های مصرف کننده و ناشر تأیید می کنند که صف های سهمیه ای مشاهده شده است که دارای توان برتر از صف های آینه ای کلاسیک است.

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

با توجه به ماهیت I/O سنگین صف های سهمیه ، با افزایش اندازه پیام ، توان آنها کاهش می یابد.

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

پیکربندی

چند پارامتر پیکربندی جدید وجود دارد که با استفاده از پرونده پیکربندی پیشرفته می توان آن را تغییر داد.

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

برنامه RA (که کتابخانه RAFT است که صف های Quorum از آن استفاده می کنند) مجموعه ای از پارامترهای قابل تنظیم خود را دارد.

برنامه خرگوش دارای چندین مورد پیکربندی مربوط به صف quorum در دسترس است.

مثال

مثال Advanced. Config زیر تمام مقادیر ذکر شده در بالا را اصلاح می کند:

رسیدگی به پیام سمی

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

صف های Quorum تعداد تلاش های ناموفق تحویل را پیگیری می کنند و آن را در هدر "تحویل X-Count" که با هر پیام مجدداً درج شده است ، در معرض نمایش قرار می دهد.

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

هنگامی که یک پیام بیشتر از حد بازگردانده شده است ، پیام کاهش می یابد یا مرده می شود (در صورت پیکربندی DLX).

استفاده از منابع

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

صف های حد نصاب از یک WAL (Write-Ahead-log) برای همه عملیات ها استفاده می کنند. عملیات WAL هم در حافظه ذخیره می شود و هم روی دیسک نوشته می شود. هنگامی که فایل WAL فعلی به یک حد از پیش تعریف شده رسید، به یک فایل بخش WAL بر روی دیسک ریخته می شود و سیستم شروع به انتشار حافظه مورد استفاده توسط آن دسته از ورودی های گزارش می کند. سپس فایل های بخش در طول زمان فشرده می شوند زیرا مصرف کنندگان تحویل را تایید می کنند. فشرده سازی فرآیندی است که فضای دیسک را بازیابی می کند.

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

مقدار پیش فرض 512 مگابایت است. این بدان معنی است که در هنگام بارگذاری ثابت، ردپای حافظه میز WAL می تواند به 512 مگابایت برسد.

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

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

قبل از RabbitMQ 3. 10 می توانست مقدار حافظه ای را که هر صف حد نصابی برای بخشی از گزارش خود در حافظه استفاده می کند، محدود کنیم. توجه داشته باشید که این محدودیت ها با محدودیت های جدول Raft WAL در حافظه و محدودیت های طول صف متفاوت است.

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

• x-max-in-memory-length محدودیتی را برای تعداد پیام ها تعیین می کند. باید یک عدد صحیح غیر منفی باشد.
• x-max-in-memory-bytes محدودیتی را به عنوان اندازه کل متن پیام (بارهای پرداختی) بر حسب بایت تعیین می کند. باید یک عدد صحیح غیر منفی باشد.

از آنجایی که RabbitMQ 3. 10 این تنظیمات منسوخ شده اند. هنوز هم می توان آنها را تنظیم کرد اما تاثیری ندارند. رفتار جدید عملاً مانند تنظیم x-max-in-memory-length=0 است که هیچ متن پیامی را در حافظه نگه نمی دارد.

درخواست های مکرر

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

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

افزایش استفاده از اتم

اجرای داخلی صف های حد نصاب، نام صف را به یک اتم Erlang تبدیل می کند. اگر صف هایی با نام های دلخواه به طور مداوم ایجاد و حذف شوند، ممکن است ثبات طولانی مدت سیستم RabbitMQ را تهدید کند (اگر اندازه جدول اتم به حداکثر حد مجاز برسد، به طور پیش فرض حدود 1M). در این مرحله استفاده از صف های حد نصاب به این صورت توصیه نمی شود.

دریافت کمک و ارائه بازخورد

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

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

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