Mengurutkan pesan

Pengurutan pesan adalah fitur di Pub/Sub yang memungkinkan Anda menerima pesan di klien pelanggan sesuai urutan pesan tersebut dipublikasikan oleh klien penayang.

Misalnya, asumsikan bahwa klien penerbit di suatu region memublikasikan pesan 1, 2, dan 3 secara berurutan. Dengan pengurutan pesan, klien pelanggan menerima pesan yang dipublikasikan dalam urutan yang sama. Agar dapat dikirimkan secara berurutan, klien penerbit harus memublikasikan pesan di region yang sama. Namun, pelanggan dapat terhubung ke region mana pun dan jaminan pengurutan tetap dipertahankan.

Pengurutan pesan adalah fitur yang berguna untuk skenario seperti pengambilan perubahan database, pelacakan sesi pengguna, dan aplikasi streaming yang penting untuk mempertahankan kronologi peristiwa.

Halaman ini menjelaskan konsep pengurutan pesan dan cara menyiapkan klien pelanggan untuk menerima pesan secara berurutan. Untuk mengonfigurasi klien penayang untuk pengurutan pesan, lihat Menggunakan kunci pengurutan untuk memublikasikan pesan.

Ringkasan pengurutan pesan

Pengurutan di Pub/Sub ditentukan oleh hal berikut:

• Kunci pengurutan: Ini adalah string yang digunakan dalam metadata pesan Pub/Sub dan merepresentasikan entity yang pesannya harus diurutkan. Panjang kunci pengurutan dapat mencapai 1 KB. Untuk menerima sekumpulan pesan yang diurutkan di suatu region, Anda harus memublikasikan semua pesan dengan kunci pengurutan yang sama di region yang sama. Beberapa contoh kunci pengurutan adalah ID pelanggan dan kunci utama baris dalam database.

  Throughput publikasi pada setiap kunci pengurutan dibatasi hingga 1 MBps. Throughput di semua kunci pengurutan pada topik dibatasi hingga kuota yang tersedia di region publikasi. Batas ini dapat ditingkatkan hingga beberapa unit GBps.

  Kunci pengurutan tidak setara dengan partisi dalam sistem pesan berbasis partisi karena kunci pengurutan diharapkan memiliki kardinalitas yang jauh lebih tinggi daripada partisi.

• Aktifkan pengurutan pesan: Ini adalah setelan langganan. Jika pengurutan pesan diaktifkan untuk langganan, klien pelanggan akan menerima pesan yang dipublikasikan di region yang sama dengan kunci pengurutan yang sama sesuai dengan urutan saat pesan tersebut diterima oleh layanan. Anda harus mengaktifkan setelan ini di langganan.

  Asumsikan Anda memiliki dua langganan A dan B yang terlampir pada topik T yang sama. Langganan A dikonfigurasi dengan pengurutan pesan diaktifkan dan langganan B dikonfigurasi tanpa pengurutan pesan diaktifkan. Dalam arsitektur ini, langganan A dan B menerima kumpulan pesan yang sama dari topik T. Jika Anda memublikasikan pesan dengan kunci pengurutan di region yang sama, langganan A menerima pesan sesuai urutan saat pesan tersebut dipublikasikan. Sedangkan, langganan B menerima pesan tanpa urutan yang diharapkan.

Secara umum, jika solusi Anda mengharuskan klien penayang mengirim pesan yang diurutkan dan tidak diurutkan, buat topik terpisah, satu untuk pesan yang diurutkan dan satu lagi untuk pesan yang tidak diurutkan.

Pertimbangan saat menggunakan pengiriman pesan berurutan

Daftar berikut berisi informasi penting terkait perilaku pengiriman pesan yang diurutkan di Pub/Sub:

• Pengurutan dalam kunci: Pesan yang dipublikasikan dengan kunci pengurutan yang sama diharapkan diterima secara berurutan. Asumsikan bahwa untuk kunci pengurutan A, Anda memublikasikan pesan 1, 2, dan 3. Dengan pengaktifan pemesanan, 1 diharapkan dikirim sebelum 2 dan 2 diharapkan dikirim sebelum 3.

• Pengurutan lintas kunci: Pesan yang dipublikasikan dengan kunci pengurutan yang berbeda tidak diharapkan diterima secara berurutan. Misalkan Anda memiliki kunci pemesanan A dan B. Untuk kunci pengurutan A, pesan 1 dan 2 dipublikasikan secara berurutan. Untuk kunci pengurutan B, pesan 3 dan 4 dipublikasikan secara berurutan. Namun, pesan 1 dapat tiba sebelum atau setelah pesan 4.

• Pengiriman ulang pesan: Pub/Sub mengirimkan setiap pesan setidaknya satu kali, sehingga layanan Pub/Sub dapat mengirim ulang pesan. Pengiriman ulang pesan akan memicu pengiriman ulang semua pesan berikutnya untuk kunci tersebut, bahkan pesan yang telah dikonfirmasi. Asumsikan bahwa klien pelanggan menerima pesan 1, 2, dan 3 untuk kunci pengurutan tertentu. Jika pesan 2 dikirim ulang (karena batas waktu konfirmasi telah berakhir atau konfirmasi upaya terbaik tidak bertahan di Pub/Sub), maka pesan 3 juga dikirim ulang. Jika pengurutan pesan dan topik yang dihentikan pengirimannya diaktifkan pada langganan, perilaku ini mungkin tidak benar, karena Pub/Sub meneruskan pesan ke topik yang dihentikan pengirimannya berdasarkan upaya terbaik.

• Penundaan konfirmasi dan topik pesan yang tidak terkirim: Pesan yang tidak dikonfirmasi untuk kunci pengurutan tertentu berpotensi menunda pengiriman pesan untuk kunci pengurutan lainnya, terutama selama server dimulai ulang atau perubahan traffic. Untuk menjaga ketertiban di seluruh acara tersebut, pastikan semua pesan dikonfirmasi tepat waktu. Jika konfirmasi tepat waktu tidak memungkinkan, pertimbangkan untuk menggunakan topik pesan yang tidak terkirim untuk mencegah penahanan pesan tanpa batas waktu. Perlu diketahui bahwa urutan mungkin tidak dipertahankan saat pesan ditulis ke topik pesan yang tidak terkirim.

• Afinitas pesan (klien streamingPull): Pesan untuk kunci yang sama biasanya dikirimkan ke klien subscriber streamingPull yang sama. Afinitas diharapkan saat pesan belum diproses untuk kunci pengurutan ke klien pelanggan tertentu. Jika tidak ada pesan yang belum selesai, afinitas dapat berubah untuk load balancing atau saat klien terputus.

  Untuk memastikan pemrosesan yang lancar meskipun ada potensi perubahan afinitas, sangat penting untuk mendesain aplikasi streamingPull Anda sedemikian rupa sehingga dapat menangani pesan di klien mana pun untuk kunci pengurutan tertentu.

• Integrasi dengan Dataflow: Jangan aktifkan pengurutan pesan untuk langganan saat mengonfigurasi Dataflow dengan Pub/Sub. Dataflow memiliki mekanisme sendiri untuk pengurutan total pesan, yang memastikan urutan kronologis di semua pesan sebagai bagian dari operasi windowing. Metode pengurutan ini berbeda dengan pendekatan berbasis kunci pengurutan Pub/Sub. Menggunakan kunci pengurutan dengan Dataflow berpotensi mengurangi performa pipeline.

• Penskalaan otomatis: Pengiriman terurut Pub/Sub dapat diskalakan hingga miliaran kunci pengurutan. Jumlah kunci pengurutan yang lebih besar memungkinkan pengiriman paralel yang lebih banyak kepada pelanggan karena pengurutan berlaku untuk semua pesan dengan kunci pengurutan yang sama.

• Kompromi performa: Pengiriman yang diurutkan memiliki beberapa kompromi. Dibandingkan dengan pengiriman yang tidak berurutan, pengiriman yang berurutan mengurangi ketersediaan publikasi dan meningkatkan latensi pengiriman pesan end-to-end. Dalam kasus pengiriman yang berurutan, failover memerlukan koordinasi untuk memastikan pesan ditulis dan dibaca dalam urutan yang benar.

• Tombol cepat: Saat menggunakan pengurutan pesan, semua pesan dengan kunci pengurutan yang sama dikirim ke klien pelanggan Anda sesuai urutan penerimaannya oleh layanan. Callback pengguna tidak berjalan hingga callback selesai untuk pesan sebelumnya. Throughput maksimum untuk pesan yang berbagi kunci pengurutan yang sama saat dikirimkan ke pelanggan tidak dibatasi oleh Pub/Sub , tetapi oleh kecepatan pemrosesan klien pelanggan Anda. Kunci panas terjadi saat backlog dibuat pada setiap kunci pengurutan karena jumlah pesan yang dihasilkan per detik melebihi jumlah pesan yang dapat diproses pelanggan per detik. Untuk mengurangi tombol panas, gunakan tombol yang paling terperinci yang dapat Anda gunakan dan minimalkan waktu pemrosesan per pesan. Anda juga dapat memantau metrik subscription/oldest_unacked_message_age untuk nilai yang meningkat, yang mungkin menunjukkan tombol hot key.

Untuk mengetahui informasi selengkapnya tentang cara menggunakan pengurutan pesan, lihat topik praktik terbaik berikut:

• Praktik terbaik untuk pengurutan pesan dalam penerbitan

• Praktik terbaik untuk pengiriman pesan yang berurutan dalam berlangganan

Perilaku klien pelanggan untuk pengurutan pesan

Klien pelanggan menerima pesan sesuai urutan saat pesan tersebut dipublikasikan di wilayah tertentu. Pub/Sub mendukung berbagai cara untuk menerima pesan, seperti klien pelanggan yang terhubung ke langganan pull dan push. Library klien menggunakan streamingPull (kecuali PHP).

Untuk mempelajari lebih lanjut jenis langganan ini, lihat Memilih jenis langganan.

Bagian berikut membahas arti menerima pesan secara berurutan untuk setiap jenis klien pelanggan.

Klien subscriber StreamingPull

Saat menggunakan library klien dengan streamingPull, Anda harus menentukan callback pengguna yang berjalan setiap kali pesan diterima oleh klien subscriber. Dengan library klien, untuk kunci pengurutan tertentu, callback dijalankan hingga selesai pada pesan dalam urutan yang benar. Jika pesan dikonfirmasi dalam callback tersebut, semua komputasi pada pesan akan terjadi secara berurutan. Namun, jika callback pengguna menjadwalkan pekerjaan asinkron lain pada pesan, klien subscriber harus memastikan bahwa pekerjaan asinkron dilakukan secara berurutan. Salah satu opsi adalah menambahkan pesan ke antrean kerja lokal yang diproses secara berurutan.

Klien pelanggan pull

Untuk klien pelanggan yang terhubung ke langganan pull, pengurutan pesan Pub/Sub mendukung hal berikut:

• Semua pesan untuk kunci pengurutan dalam PullResponse berada dalam urutan yang tepat dalam daftar.

• Hanya satu batch pesan yang dapat belum diproses untuk kunci pengurutan pada satu waktu.

Persyaratan bahwa hanya satu batch pesan yang dapat belum diproses dalam satu waktu diperlukan untuk mempertahankan pengiriman yang berurutan karena layanan Pub/Sub tidak dapat memastikan keberhasilan atau latensi respons yang dikirim untuk permintaan pull pelanggan.

Klien pelanggan push

Pembatasan pada push bahkan lebih ketat daripada pembatasan pada pull. Untuk langganan push, Pub/Sub hanya mendukung satu pesan yang belum diproses untuk setiap kunci pengurutan dalam satu waktu. Setiap pesan dikirim ke endpoint push sebagai permintaan terpisah. Oleh karena itu, mengirim permintaan secara paralel akan menimbulkan masalah yang sama seperti mengirim beberapa batch pesan untuk kunci pengurutan yang sama guna menarik pelanggan secara bersamaan. Langganan push mungkin bukan pilihan yang baik untuk topik yang pesannya sering dipublikasikan dengan kunci pengurutan yang sama atau jika latensi sangat penting.

Mengekspor klien pelanggan

Ekspor langganan mendukung pesan yang diurutkan. Untuk langganan BigQuery, pesan dengan kunci pengurutan yang sama akan ditulis ke tabel BigQuery-nya secara berurutan. Untuk langganan Cloud Storage, pesan dengan kunci pengurutan yang sama mungkin tidak semuanya ditulis ke file yang sama. Jika berada dalam file yang sama, pesan untuk kunci pengurutan akan berurutan. Jika tersebar di beberapa file, pesan selanjutnya untuk kunci pengurutan dapat muncul dalam file dengan nama yang memiliki stempel waktu lebih awal daripada stempel waktu dalam nama file dengan pesan sebelumnya.

Mengaktifkan pemesanan pesan

Untuk menerima pesan secara berurutan, tetapkan properti pengurutan pesan pada langganan tempat Anda menerima pesan. Menerima pesan secara berurutan dapat meningkatkan latensi. Anda tidak dapat mengubah properti pengurutan pesan setelah Anda membuat langganan.

Anda dapat menetapkan properti pengurutan pesan saat membuat langganan menggunakan Trusted Cloud konsol, Google Cloud CLI, atau Pub/Sub API.

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

Created subscription [SUBSCRIPTION_ID].

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

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

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

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";
}

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;
    }
}

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
}

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());
    }
  }
}

/**
 * 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.',
  );
}

/**
 * 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.',
  );
}

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}")

# 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."

Langkah berikutnya

• Baca postingan blog tentang pengiriman berurutan.

• Untuk terus memublikasikan pesan jika terjadi error yang tidak dapat dicoba lagi, lihat Mencoba lagi permintaan dengan kunci pengurutan.

• Pantau langganan Anda.

• Baca tentang cara memublikasikan pesan dengan kunci pengurutan.