הודעות לגבי הזמנות

התכונה 'סדר ההודעות' ב-Pub/Sub מאפשרת לכם לקבל הודעות בלקוחות הרשומים שלכם בסדר שבו הן פורסמו על ידי לקוחות המפרסם.

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

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

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

סקירה כללית על סדר ההודעות

הסדר ב-Pub/Sub נקבע לפי הגורמים הבאים:

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

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

  הודעות עם מפתח ריק לסידור לא מסודרות.

• מפעילים את האפשרות 'סדר ההודעות'. כדי לקבל את ההודעות בסדר הנכון, צריך להפעיל את האפשרות 'סידור הודעות' במינוי. מידע נוסף זמין במאמר הפעלת סידור הודעות.

  אם לא מפעילים את האפשרות של סדר ההודעות, המינוי מקבל הודעות ללא סדר צפוי. לדוגמה, נניח שמינויים A ו-B שניהם מצורפים לאותו נושא T, וההזמנה מופעלת במינוי A אבל לא במינוי B. למרות ששני המינויים מקבלים את אותה קבוצת הודעות מהנושא T, הסדר נשמר רק במינוי A.

קצב העברת הנתונים (throughput) של הפרסום בכל מפתח הזמנה מוגבל ל-‎1 MBps. התפוקה של כל מפתחות ההזמנה בנושא מוגבלת למכסת הזמינות באזור הפרסום. אפשר להגדיל את המגבלה הזו לכמה GBps.

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

שיקולים לשימוש בהעברת הודעות לפי סדר

בהמשך מופיע מידע חשוב לגבי אופן הפעולה של הודעות מסודרות ב-Pub/Sub:

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

• סדר בתוך מפתח: ההודעות שמתפרסמות עם אותו מפתח סדר צפויות להתקבל לפי הסדר. נניח שאתם מפרסמים את ההודעות 1, 2 ו-3 כדי להזמין את מפתח א'. אם האפשרות להזמנה מופעלת, צפוי שהמוצר 1 יימסר לפני המוצר 2, והמוצר 2 יימסר לפני המוצר 3.

• סדר בין מפתחות: לא צפוי שהודעות שפורסמו עם מפתחות סדר שונים יתקבלו לפי הסדר. נניח שיש לכם מפתחות הזמנה A ו-B. כדי להזמין את מפתח A, ההודעות 1 ו-2 מתפרסמות לפי הסדר. כדי להזמין את מפתח B, ההודעות 3 ו-4 מתפרסמות לפי הסדר. עם זאת, יכול להיות שהודעה 1 תגיע לפני הודעה 4 או אחריה.

• מסירה חוזרת של הודעות: שירות Pub/Sub מספק כל הודעה לפחות פעם אחת, ולכן יכול להיות שהוא יספק הודעות מחדש. שליחה מחדש של הודעה גורמת לשליחה מחדש של כל ההודעות הבאות עבור המפתח הזה, גם אם הן אושרו. נניח שלקוח מנוי מקבל את ההודעות 1, 2 ו-3 עבור מפתח סדר ספציפי. אם הודעה 2 נמסרת מחדש (כי תוקף אישור המסירה פג או כי אישור המסירה בשיטת הכי טוב שאפשר לא נשמר ב-Pub/Sub), גם הודעה 3 נמסרת מחדש. אם גם ההזמנה של ההודעות וגם נושא להודעות ללא מוצא מופעלים במינוי, יכול להיות שההתנהגות הזו לא תתרחש, כי Pub/Sub מעביר הודעות לנושאים להודעות ללא מוצא על בסיס המאמץ הטוב ביותר.

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

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

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

• שילוב עם Dataflow: אל תפעילו את האפשרות 'הזמנת הודעות' למינויים כשמגדירים את Dataflow עם Pub/Sub. ל-Dataflow יש מנגנון משלו משלו לסידור כל ההודעות, כדי להבטיח סדר כרונולוגי של כל ההודעות כחלק מפעולות של חלונות. השיטה הזו של הזמנה שונה מהגישה של Pub/Sub שמבוססת על מפתח הזמנה. שימוש במפתחות לסידור נתונים ב-Dataflow עלול להפחית את הביצועים של צינור הנתונים.

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

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

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

מידע נוסף על השימוש בסדר ההודעות זמין בנושאים הבאים של שיטות מומלצות:

• שיטות מומלצות להצגת הודעות מסודרות בפרסום

• שיטות מומלצות להצגת הודעות בסדר מסוים בתהליך ההרשמה

התנהגות של לקוח שרשום למינוי בנוגע לסדר ההודעות

לקוחות מנויים מקבלים הודעות לפי הסדר שבו הן פורסמו באזור ספציפי. ב-Pub/Sub יש דרכים שונות לקבלת הודעות, כמו לקוחות של מנויים שמחוברים למינויים מסוג pull ו-push. ספריות הלקוח משתמשות ב-streamingPull (למעט PHP).

מידע נוסף על סוגי המינויים האלה זמין במאמר בחירת סוג מינוי.

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

לקוחות של מנויים ב-StreamingPull

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

שליפת הודעות ללקוחות של מנויים

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

• כל ההודעות של מפתח הזמנה ב-PullResponse מסודרות ברשימה בסדר הנכון.

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

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

לקוחות של מינוי Push

ההגבלות על שליחת נתונים (push) מחמירות יותר מאלה על משיכת נתונים (pull). במינוי דחיפה, ‏ Pub/Sub תומך רק בהודעה אחת שלא נמסרה לכל מפתח הזמנה בכל פעם. כל הודעה נשלחת לנקודת קצה של Push כבקשה נפרדת. לכן, שליחת הבקשות במקביל תגרום לאותה בעיה כמו שליחת כמה קבוצות של הודעות עם אותו מפתח הזמנה למנויים בו-זמנית. מינויים להודעות פוש לא מתאימים לנושאים שבהם מתפרסמות הודעות לעיתים קרובות עם אותו מפתח סידור, או במקרים שבהם זמן האחזור חשוב במיוחד.

ייצוא לקוחות מנויים

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

הפעלת האפשרות להזמנת מוצרים בהודעות

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

אפשר להגדיר את הנכס של סדר ההודעות כשיוצרים מינוי באמצעות Google Cloud המסוף, Google Cloud CLI או Pub/Sub API.

המסוף

כדי ליצור מינוי עם מאפיין סדר ההודעות:

1. נכנסים לדף Subscriptions במסוף Google Cloud .

לדף "מינויים"

1. לוחצים על יצירת מינוי.

2. מזינים מזהה מינוי.

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

4. בקטע Message ordering, בוחרים באפשרות Order messages with an ordering key.

5. לוחצים על יצירה.

gcloud

כדי ליצור מינוי עם המאפיין של סדר ההודעות, משתמשים בפקודה gcloud pubsub subscriptions create ובדגל --enable-message-ordering:

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
  --enable-message-ordering

מחליפים את SUBSCRIPTION_ID במזהה המינוי.

אם הבקשה מבוצעת בהצלחה, בשורת הפקודה תוצג הודעת אישור:

Created subscription [SUBSCRIPTION_ID].

REST

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

PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID
Authorization: Bearer $(gcloud auth application-default print-access-token)

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: מזהה הפרויקט של הפרויקט עם הנושא
• ‫SUBSCRIPTION_ID: מזהה המינוי

בגוף הבקשה, מציינים את הפרטים הבאים:

{
  "topic": TOPIC_ID,
  "enableMessageOrdering": true,
}

מחליפים את TOPIC_ID במזהה של הנושא לצירוף למינוי.

אם הבקשה מצליחה, התשובה היא המינוי בפורמט JSON:

{
  "name": projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID,
  "topic": projects/PROJECT_ID/topics/TOPIC_ID,
  "enableMessageOrdering": true,
}

C++‎

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של C++‎ במאמר תחילת העבודה המהירה: שימוש בספריות לקוח. מידע נוסף זמין במאמרי העזרה של Pub/Sub C++ API.

namespace pubsub = ::google::cloud::pubsub;
namespace pubsub_admin = ::google::cloud::pubsub_admin;
[](pubsub_admin::SubscriptionAdminClient client,
   std::string const& project_id, std::string const& topic_id,
   std::string const& subscription_id) {
  google::pubsub::v1::Subscription request;
  request.set_name(
      pubsub::Subscription(project_id, subscription_id).FullName());
  request.set_topic(pubsub::Topic(project_id, topic_id).FullName());
  request.set_enable_message_ordering(true);
  auto sub = client.CreateSubscription(request);
  if (sub.status().code() == google::cloud::StatusCode::kAlreadyExists) {
    std::cout << "The subscription already exists\n";
    return;
  }
  if (!sub) throw std::move(sub).status();

  std::cout << "The subscription was successfully created: "
            << sub->DebugString() << "\n";
}

C#‎

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של C# ‎ במאמר הפעלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub C# API.

using Google.Cloud.PubSub.V1;
using Grpc.Core;

public class CreateSubscriptionWithOrderingSample
{
    public Subscription CreateSubscriptionWithOrdering(string projectId, string topicId, string subscriptionId)
    {
        SubscriberServiceApiClient subscriber = SubscriberServiceApiClient.Create();
        var topicName = TopicName.FromProjectTopic(projectId, topicId);
        var subscriptionName = SubscriptionName.FromProjectSubscription(projectId, subscriptionId);

        var subscriptionRequest = new Subscription
        {
            SubscriptionName = subscriptionName,
            TopicAsTopicName = topicName,
            EnableMessageOrdering = true
        };

        Subscription subscription = null;
        try
        {
            subscription = subscriber.CreateSubscription(subscriptionRequest);
        }
        catch (RpcException e) when (e.Status.StatusCode == StatusCode.AlreadyExists)
        {
            // Already exists.  That's fine.
        }
        return subscription;
    }
}

המשך

בדוגמה הבאה נעשה שימוש בגרסה הראשית של ספריית הלקוח Go Pub/Sub ‏ (v2). אם אתם עדיין משתמשים בספרייה v1, כדאי לעיין במדריך להעברה לגרסה v2. כדי לראות רשימה של דוגמאות קוד מגרסה 1, אפשר לעיין ב דוגמאות הקוד שהוצאו משימוש.

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Go במאמר מדריך למתחילים: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Go API.

import (
	"context"
	"fmt"
	"io"

	"cloud.google.com/go/pubsub/v2"
	"cloud.google.com/go/pubsub/v2/apiv1/pubsubpb"
)

func createWithOrdering(w io.Writer, projectID, topic, subscription string) error {
	// projectID := "my-project-id"
	// topic := "projects/my-project-id/topics/my-topic"
	// subscription := "projects/my-project/subscriptions/my-sub"
	ctx := context.Background()
	client, err := pubsub.NewClient(ctx, projectID)
	if err != nil {
		return fmt.Errorf("pubsub.NewClient: %w", err)
	}
	defer client.Close()

	// Message ordering can only be set when creating a subscription.
	sub, err := client.SubscriptionAdminClient.CreateSubscription(ctx, &pubsubpb.Subscription{
		Name:                  subscription,
		Topic:                 topic,
		EnableMessageOrdering: true,
	})
	if err != nil {
		return fmt.Errorf("CreateSubscription: %w", err)
	}
	fmt.Fprintf(w, "Created subscription: %v\n", sub)
	return nil
}

Java

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Java במאמר התחלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Java API.

import com.google.cloud.pubsub.v1.SubscriptionAdminClient;
import com.google.pubsub.v1.ProjectSubscriptionName;
import com.google.pubsub.v1.ProjectTopicName;
import com.google.pubsub.v1.Subscription;
import java.io.IOException;

public class CreateSubscriptionWithOrdering {
  public static void main(String... args) throws Exception {
    // TODO(developer): Replace these variables before running the sample.
    String projectId = "your-project-id";
    String topicId = "your-topic-id";
    String subscriptionId = "your-subscription-id";

    createSubscriptionWithOrderingExample(projectId, topicId, subscriptionId);
  }

  public static void createSubscriptionWithOrderingExample(
      String projectId, String topicId, String subscriptionId) throws IOException {
    try (SubscriptionAdminClient subscriptionAdminClient = SubscriptionAdminClient.create()) {

      ProjectTopicName topicName = ProjectTopicName.of(projectId, topicId);
      ProjectSubscriptionName subscriptionName =
          ProjectSubscriptionName.of(projectId, subscriptionId);

      Subscription subscription =
          subscriptionAdminClient.createSubscription(
              Subscription.newBuilder()
                  .setName(subscriptionName.toString())
                  .setTopic(topicName.toString())
                  // Set message ordering to true for ordered messages in the subscription.
                  .setEnableMessageOrdering(true)
                  .build());

      System.out.println("Created a subscription with ordering: " + subscription.getAllFields());
    }
  }
}

Node.js

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Node.js במאמר הפעלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Node.js API.

/**
 * TODO(developer): Uncomment these variables before running the sample.
 */
// const topicNameOrId = 'YOUR_TOPIC_NAME_OR_ID';
// const subscriptionNameOrId = 'YOUR_SUBSCRIPTION_NAME_OR_ID';

// Imports the Google Cloud client library
const {PubSub} = require('@google-cloud/pubsub');

// Creates a client; cache this for further use
const pubSubClient = new PubSub();

async function createSubscriptionWithOrdering(
  topicNameOrId,
  subscriptionNameOrId,
) {
  // Creates a new subscription
  await pubSubClient
    .topic(topicNameOrId)
    .createSubscription(subscriptionNameOrId, {
      enableMessageOrdering: true,
    });
  console.log(
    `Created subscription ${subscriptionNameOrId} with ordering enabled.`,
  );
  console.log(
    'To process messages in order, remember to add an ordering key to your messages.',
  );
}

Node.js

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Node.js במאמר הפעלה מהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Node.js API.

/**
 * TODO(developer): Uncomment these variables before running the sample.
 */
// const topicNameOrId = 'YOUR_TOPIC_NAME_OR_ID';
// const subscriptionNameOrId = 'YOUR_SUBSCRIPTION_NAME_OR_ID';

// Imports the Google Cloud client library
import {PubSub} from '@google-cloud/pubsub';

// Creates a client; cache this for further use
const pubSubClient = new PubSub();

async function createSubscriptionWithOrdering(
  topicNameOrId: string,
  subscriptionNameOrId: string,
) {
  // Creates a new subscription
  await pubSubClient
    .topic(topicNameOrId)
    .createSubscription(subscriptionNameOrId, {
      enableMessageOrdering: true,
    });
  console.log(
    `Created subscription ${subscriptionNameOrId} with ordering enabled.`,
  );
  console.log(
    'To process messages in order, remember to add an ordering key to your messages.',
  );
}

Python

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Python במאמר תחילת העבודה המהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של ה-API בשפת Python של Pub/Sub.

from google.cloud import pubsub_v1

# TODO(developer): Choose an existing topic.
# project_id = "your-project-id"
# topic_id = "your-topic-id"
# subscription_id = "your-subscription-id"

publisher = pubsub_v1.PublisherClient()
subscriber = pubsub_v1.SubscriberClient()
topic_path = publisher.topic_path(project_id, topic_id)
subscription_path = subscriber.subscription_path(project_id, subscription_id)

with subscriber:
    subscription = subscriber.create_subscription(
        request={
            "name": subscription_path,
            "topic": topic_path,
            "enable_message_ordering": True,
        }
    )
    print(f"Created subscription with ordering: {subscription}")

Ruby

בדוגמה הבאה נעשה שימוש בספריית הלקוח של Ruby Pub/Sub בגרסה 3. אם אתם עדיין משתמשים בספרייה v2, כדאי לעיין במדריך להעברה לגרסה v3. כדי לראות רשימה של דוגמאות קוד של Ruby v2, אפשר לעיין ב דוגמאות הקוד שהוצאו משימוש.

לפני שמנסים את הדוגמה הזו, צריך לפעול לפי הוראות ההגדרה של Ruby במאמר תחילת העבודה המהירה: שימוש בספריות לקוח. מידע נוסף מופיע במאמרי העזרה של Pub/Sub Ruby API.

# topic_id        = "your-topic-id"
# subscription_id = "your-subscription-id"

pubsub = Google::Cloud::PubSub.new
subscription_admin = pubsub.subscription_admin

subscription = subscription_admin.create_subscription \
  name: pubsub.subscription_path(subscription_id),
  topic: pubsub.topic_path(topic_id),
  enable_message_ordering: true

puts "Pull subscription #{subscription_id} created with message ordering."

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

• לקריאת הפוסט בבלוג על משלוח מסודר

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

• מעקב אחרי המינוי.

• מידע נוסף על פרסום הודעות עם מפתחות הזמנה