RabbitMQ. חלק 2. הבנת חילופים

Exchange - מחליף או נקודת החלפה. נשלחות אליו הודעות. Exchange מפיץ את ההודעה בתור אחד או יותר. הוא מנתב הודעות לתור מבוסס על קישורים שנוצרו (bindings) בינו לבין התור.

Exchange לא תהליך ארלנג. מסיבות של מדרגיות exchange הוא מחרוזת (קישור למודול עם הקוד שבו נמצא לוגיקת הניתוב) במסד הנתונים המוטבע אמנזיה. אלף מחליפים יצרכו רק 1MB של זיכרון.

תוכן העניינים

  • RabbitMQ. חלק 1. מבוא. Erlang, AMQP ו-RPC
  • RabbitMQ. חלק 2. הבנת חילופים
  • RabbitMQ. חלק 3. הבנת תורים וכריכות
  • RabbitMQ. חלק 4. התמודדות עם מה זה מסרים ומסגרות
  • RabbitMQ. חלק 5: פרסום וצריכת ביצועי הודעות
  • RabbitMQ. חלק 6. סקירה של מודולי הפדרציה והשופל
  • RabbitMQ. חלק 7. פרטים על קונקשן ושאנל
  • RabbitMQ. חלק 8. RabbitMQ ב-.NET
  • RabbitMQ. חלק 9. ניטור

החלפה ישירה

Direct exchange - משמש בעת הצורך להעביר הודעה לתורים ספציפיים. ההודעה מתפרסמת למחליף עם הודעה ספציפית מפתח ניתוב ונכנס לכל התורים המשויכים למחליף הזה עם מפתח ניתוב דומה. מפתח הניתוב הוא מחרוזת. ההתאמה מתבצעת באמצעות בדיקת מחרוזות לשוויון.

ייצוג גרפי של זרימת ההודעות:

RabbitMQ. חלק 2. הבנת חילופים

В rabbitmq יש מושג מחליף ברירת מחדל. זה direct exchange ללא שם. אם נעשה שימוש במחליף ברירת המחדל, ההודעה תנותב לתור עם שם השווה ל מפתח ניתוב הודעות.

חילופי נושאים

Topic exchange – דומה direct exchange מאפשר ניתוב סלקטיבי על ידי השוואת מפתח הניתוב. אבל, במקרה זה, המפתח ניתן לפי תבנית. בעת יצירת תבנית, השתמש 0 או יותר מילים (אותיות AZ и az ומספרים 0-9), מופרדים על ידי נקודה, כמו גם סמלים * и #.

  • * - ניתן להחליף במדויק 1 слово
  • # - ניתן להחליף על ידי 0 או יותר מילים

ייצוג גרפי של זרימת ההודעות:

RabbitMQ. חלק 2. הבנת חילופים

החל מהגרסה RabbitMQ 2.4.0 אלגוריתם ניתוב עבור topic exchange התחיל לעבוד עד 145 פעמים מהר יותר. הם השיגו זאת על ידי יישום הגישה נסה ליישם, מה שמרמז על ייצוג של תבניות כמבנה עץ. למשל תבניות a.b.c, a.*.b.c, a.#.c и b.b.c יוצג על ידי המבנה הבא:

RabbitMQ. חלק 2. הבנת חילופים

חיפוש התאמת דפוסים מתבצע מהשורש והולך מלמעלה למטה.

מאפיינים:

  • השימוש במחליף זה יכול להפוך בחירה טובה לפיתוח עתידי אפשרי של האפליקציה, כי תמיד ניתן להתאים אישית תבניות כך שההודעה תתפרסם באופן דומה direct exchange או fanout exchange
  • תבניות שמשתמשות בהן * הרבה יותר מהרמאשר תבניות שמשתמשות בהן #.
  • topic exchange איטי יותר direct exchange

חילופי Fanout

Fanout exchange - כל ההודעות נשלחות לכל התורים גם אם צוין מפתח ניתוב בהודעה.

מאפיינים:

  • RabbitMQ לא עובד עם מפתחות ניתוב ותבניות מה שיש לו השפעה חיובית על הביצועים. זה המהיר ביותר exchange;
  • כל הצרכנים חייבים להיות מסוגלים לעבד את כל ההודעות;

ייצוג גרפי של זרימת ההודעות:

RabbitMQ. חלק 2. הבנת חילופים

החלפת כותרות

Headers exchange - מפנה הודעות לתורים קשורים בהתבסס על השוואה של זוגות של מאפיינים (מפתח, ערך) headers מאפיין הודעה מחייב ודומה. headers הוא Dictionary<ключ, значение>.

אם תוסיף מפתח מיוחד למילון x-match עם משמעות any, אז ההודעה מנותבת אם הזוגות (מפתח, ערך) תואמים חלקית. התנהגות זו דומה לאופרטור or.

var bindingArguments = new Dictinary<String, Object>();
bindingArguments.add("x-match", "any");

מפתח ברירת מחדל x-match מכיל ערך all. המשמעות היא שההודעה מנותבת כאשר הזוגות (מפתח, ערך) תואמים לחלוטין. התנהגות זו דומה לאופרטור and.

ייצוג גרפי של זרימת ההודעות:

RabbitMQ. חלק 2. הבנת חילופים

מאפיינים:

  • גמישות נוספת
  • תקורה חישובית נוספת. כל הזוגות (מפתח, ערך) של התכונה headers יש למיין לפי שם מפתח לפני חישוב ערכי ניתוב הודעות. איטי יותר מסוגי חליפין אחרים.

חילופי גיבוב עקביים

מחליף זה הוא חיבור и לא מובנה в RabbitMQ.

Consistent-hashing exchange (החלפה עקבית hash) - משמש כאשר ישנם תורים מרובים שהם נמענים פוטנציאליים של הודעה וכאשר אתה צריך לטעון איזון ביניהם. ההודעה משויכת לתור לפי משקל (ערך מחרוזת מותנה מ 0 - n).

משקל שווה של תורים - מציין שכל תור יקבל בערך אותה כמות הודעות (כל הודעה תוכנס לתור אחד בלבד). אין ערובה מלאה להפצה אחידה של הודעות.

ייצוג גרפי של זרימת ההודעות:

RabbitMQ. חלק 2. הבנת חילופים

Hash מחושב על סמך מפתח ניתוב או נכס headers הודעות. אם לכל ההודעות שפורסמו היו מפתחות ניתוב שונים, או headers, אז ההתפלגות תתרחש לפי משקל. אחרת, ייעשה שימוש במפתח הניתוב, או headers.

אמור לעזור כאשר תפוקת הצרכן צריכה לגדול יותר מאשר פתרון עם מספר צרכנים המשתמשים באותו תור.

שילוב של מחליפים (E2E)

ניתן לשלב את ההתנהגות של כל המחליפים באמצעות תקשורת Exchange-to-Exchange (שילוב של מחליפים אינו כלול במפרט AMQP. זוהי הרחבת פרוטוקול מהצד RabbitMQ).

ייצוג גרפי של זרימת ההודעות:

RabbitMQ. חלק 2. הבנת חילופים

מאת E2E נוכל למצוא את התצורה הנכונה להרחבה העונה על דרישות נוכחיות וגדלות כאחד.

צור Exchange

המחליף נוצר באמצעות סינכרוני RPC בקשה לשרת. הבקשה נעשית בשיטה Exchange.Declare, נקרא עם פרמטרים:

  • שם מחליף
  • סוג מחליף
  • אפשרויות אחרות

דוגמה ליצירה exchange באמצעות RabbitMQ.Client:

//...
channel.ExchangeDeclare(
    exchange: "my_exchange",
    type: "direct",
    durable: "false",
    autoDelete: "false",
    arguments: null
);
//...

  • exchange - שם המחליף שאנו רוצים ליצור. השם חייב להיות ייחודי
  • type - סוג מחליף
  • durable - אם מותקן true, אז exchange יהיה קבוע. זה יאוחסן בדיסק ויוכל לשרוד הפעלה מחדש של שרת/ברוקר. אם הערך false, אז exchange הוא זמני ויוסר כאשר השרת/ברוקר יופעל מחדש
  • autoDelete - מחיקה אוטומטית. Exchange יימחק כאשר כל התורים המשויכים יימחקו
  • arguments הם טיעונים אופציונליים. לרוב, דרך הטיעונים שנקבעו alternative exchange (מחליף חלופי). אם הודעה לא יכולה לעבור במסלול המקורי, ניתן לשלוח אותה למרכזיה חלופית כדי לנתב אותה בנתיב אחר.

RabbitMQ. חלק 2. הבנת חילופים

אם יצירה exchange אולי, אז השרת ישלח ללקוח סינכרוני RPC לענות Exchange.DeclareOk. אם יצירה הוא בלתי אפשרי (היה סירוב לבקשה Exchange.Declare) אז הערוץ ייסגר שרת באמצעות פקודה אסינכרונית Channel.Close והלקוח יקבל חריגה Operation InterruptedException, שיכיל את קוד השגיאה ואת התיאור שלו.

יש ליצור מחליף לפני הפרסום. אם תפרסם הודעה למחליף לא קיים - RabbitMQ להסיר אותו בשקט.

צור GUI של Exchange

עבור לפאנל הניהול RabbitMQ תחת משתמש guest (שם משתמש: guest וסיסמא: guest). שימו לב שהמשתמש guest יכול להתחבר רק מ-localhost. כעת נעבור ללשונית Exchanges ולחץ על Add a new exchange. מלאו את המאפיינים:

RabbitMQ. חלק 2. הבנת חילופים

רוב הנכסים תוארו לעיל. כאן נציין שאם קבענו Internal, אז ניתן להשתמש בהחלפה רק עבור E2E. Producer לא יוכל לשלוח הודעות למרכזייה כזו.

מסקנה

כאשר מפתחים מערכת, נוח לתאר את הטופולוגיה ניתוב באמצעות גרף. אבל לפני שמתחילים לבנות גרף, כדאי להדגיש את הנתיבים עם תעבורה גבוהה, כי. הם דורשים תפוקה גבוהה יותר (ביצועים). לאחר מכן, אתה יכול לסווג את התנועה. ואז להתחיל לבנות.

אם בגרף הבנוי קיים סט סופי מפתחות ניתוב, אם כן, כדאי להסתכל על כמה fanout exchange, שהם 1:1 הקשורים למפתח הניתוב. זכור את זה fanout exchange הכי מהיר.

אם מספר המסלולים נוטה לאינסוף, כדאי לשים לב אליו topic exchange או, אם התבנית אינה נחוצה, אז אתה יכול לבחור direct exchnge, כי הוא מהיר יותר topic exchange.

שילובים של שונים exchange אמור לעזור לך למצוא את המתאים. תצורה ניתנת להרחבה, העונה על דרישות המערכת הנוכחיות והן הגוברת.

כמות exchange והתורים צריכים להיות מינימליים בהשוואה למספר המסלולים.

במאמר הבא, נתחיל להבין יותר על תורים וכריכות.

תזכור

מקור: www.habr.com

הוספת תגובה