הרשמות לשליפה

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

במינוי שליפה, לקוח מנוי מבקש הודעות משרת Pub/Sub.

במצב משיכה אפשר להשתמש באחד משני ממשקי ה-API של השירות, Pull או StreamingPull. כדי להריץ את ה-API שנבחר, אפשר לבחור ספריית לקוח ברמה גבוהה ש-Google מספקת, או ספריית לקוח ברמה נמוכה שנוצרת באופן אוטומטי. אפשר גם לבחור בין עיבוד אסינכרוני וסינכרוני של הודעות.

לפני שמתחילים

לפני שקוראים את המסמך הזה, חשוב לוודא שמכירים את הנושאים הבאים:

תהליך העבודה של מינוי שליפה

במינוי שליפה, לקוח המינוי יוזם בקשות לשרת Pub/Sub כדי לאחזר הודעות. לקוח המנוי משתמש באחד מהממשקי ה-API הבאים:

רוב הלקוחות המנויים לא שולחים את הבקשות האלה ישירות. במקום זאת, הלקוחות מסתמכים על ספריית הלקוח ברמה גבוהה שסופקה על ידי Google Cloud, שמבצעת בקשות משיכה של נתונים בסטרימינג באופן פנימי ומעבירה הודעות באופן אסינכרוני. ללקוח של מנוי שצריך שליטה רבה יותר באופן שליפת ההודעות, Pub/Sub משתמש בספריית gRPC ברמה נמוכה שנוצרת באופן אוטומטי. הספרייה הזו שולחת בקשות משיכה או בקשות משיכה של סטרימינג באופן ישיר. הבקשות האלה יכולות להיות סנכרוניות או לא סנכרוניות.

שתי התמונות הבאות מציגות את תהליך העבודה בין לקוח של מינוי לבין מינוי מסוג pull.

זרימת ההודעות במינוי שליפה
איור 1. תהליך העבודה של מינוי שליפה



רצף ההודעות במינוי מסוג streamingPull
איור 2. תהליך העבודה של מינוי לסטרימינג של נתונים

תהליך עבודה מסוג Pull

תהליך העבודה של משיכת נתונים מוצג באיור 1 ומתבצע באופן הבא:

  1. לקוח המנוי קורא במפורש לשיטה pull, שמבקשת הודעות למסירה. הבקשה הזו היא PullRequest כמו שמופיע בתמונה.

  2. שרת Pub/Sub מגיב עם אפס או יותר הודעות ומזהי אישור. תשובה עם אפס הודעות או עם שגיאה לא מציינת בהכרח שאין הודעות זמינות לקבלה. התשובה הזו היא PullResponse כמו שמופיע בתמונה.

  3. לקוח המנוי קורא במפורש לשיטה acknowledge. הלקוח משתמש במזהה האישור שהוחזר כדי לאשר שההודעה עברה עיבוד ואין צורך להעביר אותה שוב.

בבקשת משיכה אחת של סטרימינג, לקוח מנוי יכול לקבל כמה תגובות בגלל החיבור הפתוח. לעומת זאת, רק תשובה אחת מוחזרת לכל בקשת משיכה.

מאפיינים של מינוי מסוג pull

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

ממשקי API של שירות Pub/Sub

אפשר להשתמש באחד משני ממשקי ה-API הבאים כדי לאחזר הודעות ממנוי מסוג pull ב-Pub/Sub:

  • שליפה
  • StreamingPull

כשמקבלים הודעות באמצעות ממשקי ה-API האלה, צריך להשתמש ב-RPCs מסוג unary Acknowledge ו-ModifyAckDeadline. בקטעים הבאים מתוארים שני ממשקי ה-API של Pub/Sub.

StreamingPull API

במקרים שבהם הדבר אפשרי, ספריות הלקוח של Pub/Sub משתמשות ב-StreamingPull כדי להשיג את התפוקה המקסימלית ואת זמן האחזור הנמוך ביותר. יכול להיות שלעולם לא תשתמשו ב-StreamingPull API באופן ישיר, אבל חשוב לדעת במה הוא שונה מ-Pull API.

‫StreamingPull API מסתמך על חיבור דו-כיווני מתמשך כדי לקבל כמה הודעות כשהן זמינות. זהו תהליך העבודה:

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

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

  3. אם או כשהמכסה של קצב העברת הנתונים נחצה, השרת מפסיק לשלוח הודעות. אבל החיבור לא נותק. השידור יתחדש בכל פעם שתהיה שוב מכסת נתונים מספקת.

  4. בסופו של דבר, הלקוח או השרת סוגרים את החיבור.

ממשק StreamingPull API שומר על חיבור פתוח. שרתי Pub/Sub סוגרים את החיבור באופן מחזורי אחרי פרק זמן מסוים כדי למנוע חיבור קבוע לטווח ארוך. ספריית הלקוח פותחת מחדש באופן אוטומטי חיבור StreamingPull.

ההודעות נשלחות לחיבור כשהן זמינות. לכן, ה-API של StreamingPull מצמצם את זמן האחזור וממקסם את קצב העברת הנתונים של ההודעות.

מידע נוסף על שיטות ה-RPC של StreamingPull: StreamingPullRequest ו- StreamingPullResponse.

Pull API

ממשק ה-API הזה הוא RPC מסורתי עם ארגומנט יחיד שמבוסס על מודל של בקשה ותגובה. תשובה אחת לבקשת משיכה תואמת לבקשת משיכה אחת. זהו תהליך העבודה:

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

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

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

השימוש ב-Pull API לא מבטיח זמן אחזור נמוך וקצב העברת נתונים גבוה של הודעות. כדי להשיג תפוקה גבוהה וזמן אחזור נמוך באמצעות Pull API, אתם צריכים להגיש כמה בקשות בו-זמנית. בקשות חדשות נוצרות כשבקשות ישנות מקבלות תשובה. תכנון פתרון כזה עלול להוביל לשגיאות וקשה לתחזוקה. מומלץ להשתמש בממשק StreamingPull API בתרחישי שימוש כאלה.

מומלץ להשתמש ב-Pull API במקום ב-StreamingPull API רק אם נדרשת לכם שליטה מלאה בפרמטרים הבאים:

  • מספר ההודעות שקליינט המנוי יכול לעבד
  • הזיכרון והמשאבים של הלקוח

אפשר להשתמש ב-API הזה גם כשהמנוי הוא שרת proxy בין Pub/Sub לבין שירות אחר שפועל בצורה יותר מבוססת-משיכה.

מידע נוסף על שיטות Pull REST: Method: projects.subscriptions.pull.

מידע נוסף על שיטות Pull RPC: PullRequest ו-PullResponse.

סוגים של מצבי עיבוד הודעות

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

מצב משיכה אסינכרוני

במצב משיכה אסינכרוני, קבלת ההודעות מופרדת מעיבוד ההודעות בלקוח של המנוי. זהו מצב ברירת המחדל ברוב הלקוחות של המנויים. במצב משיכה אסינכרוני אפשר להשתמש ב-StreamingPull API או ב-unary Pull API. במשיכה אסינכרונית אפשר להשתמש גם בספריית לקוח ברמה גבוהה או בספריית לקוח ברמה נמוכה שנוצרת באופן אוטומטי.

בהמשך המאמר מוסבר על ספריות לקוח.

מצב משיכה סינכרוני

במצב משיכה סינכרוני, קבלת ההודעות ועיבודן מתרחשים ברצף ולא מופרדים זה מזה. לכן, בדומה ל-StreamingPull לעומת ממשקי API של unary Pull, עיבוד אסינכרוני מציע חביון נמוך יותר וקצב העברה גבוה יותר בהשוואה לעיבוד סינכרוני.

מומלץ להשתמש במצב משיכה סינכרוני רק באפליקציות שבהן זמן אחזור נמוך וקצב העברת נתונים גבוה הם לא הגורמים החשובים ביותר בהשוואה לדרישות אחרות. לדוגמה, יכול להיות שאפליקציה מוגבלת לשימוש רק במודל תכנות סינכרוני. לחלופין, יכול להיות שאפליקציה עם מגבלות על משאבים תדרוש שליטה מדויקת יותר בזיכרון, ברשת או במעבד. במקרים כאלה, צריך להשתמש במצב סינכרוני עם ה-API של Pull מסוג unary.

ספריות לקוח של Pub/Sub

‫Pub/Sub מציע ספריית לקוח ברמה גבוהה וברמה נמוכה שנוצרת באופן אוטומטי.

ספריית לקוח Pub/Sub ברמה גבוהה

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

מומלץ להשתמש ב-pull אסינכרוני וב-StreamingPull API עם ספריית הלקוח ברמה גבוהה. לא כל השפות שנתמכות ב-Google Cloud תומכות גם ב-Pull API בספריית הלקוח ברמה גבוהה.

מידע על שימוש בספריות לקוח ברמה גבוהה זמין במאמר ספריות לקוח של Pub/Sub.

ספריית לקוח Pub/Sub ברמה נמוכה שנוצרה אוטומטית

ספריית לקוח ברמה נמוכה זמינה למקרים שבהם צריך להשתמש ישירות ב-Pull API. אפשר להשתמש בעיבוד סינכרוני או אסינכרוני עם ספריית הלקוח שנוצרה אוטומטית ברמה נמוכה. כשמשתמשים בספריית לקוח ברמה נמוכה שנוצרת אוטומטית, צריך לקודד ידנית תכונות כמו משלוח לפי סדר, משלוח בדיוק פעם אחת, בקרה על זרימת נתונים וניהול חכירה.

אפשר להשתמש במודל עיבוד סינכרוני כשמשתמשים בספריית הלקוח ברמה נמוכה שנוצרה אוטומטית לכל השפות הנתמכות. יכול להיות שתשתמשו בספריית הלקוח ברמה נמוכה שנוצרה אוטומטית ובמשיכה סינכרונית במקרים שבהם הגיוני להשתמש ישירות ב-Pull API. לדוגמה, יכול להיות שיש לכם לוגיקה קיימת של אפליקציה שמסתמכת על המודל הזה.

כדי להשתמש ישירות בספריות לקוח ברמה נמוכה שנוצרו באופן אוטומטי, אפשר לעיין במאמר סקירה כללית של Pub/Sub APIs.

המאמרים הבאים