Antrean dan topik yang dipartisi

  • Artikel

Azure Service Bus menggunakan beberapa broker pesan untuk memproses pesan dan beberapa penyimpanan olahpesan untuk menyimpan pesan. Antrean atau topik konvensional ditangani oleh broker pesan tunggal dan disimpan dalam satu penyimpanan olahpesan. Partisi Service Bus memungkinkan antrean dan topik, atau entitas olahpesan, untuk dipartisi di beberapa broker pesan dan penyimpanan olahpesan. Partisi berarti bahwa throughput keseluruhan antrean atau topik yang dipartisi tidak lagi dibatasi oleh kinerja broker pesan tunggal atau penyimpanan pesan. Selain itu, pemadaman sementara penyimpanan olahpesan tidak membuat antrean atau topik yang dipartisi tidak tersedia. Antrean dan topik yang dipartisi dapat berisi semua fitur Service Bus canggih, seperti dukungan untuk transaksi dan sesi.

Catatan

Ada beberapa perbedaan antara SKU Dasar / Standar dan Premium dalam hal pemartisian.

  • Partisi tersedia di pembuatan entitas untuk semua antrean dan topik dalam SKU Dasar atau Standar. Namespace dapat memiliki entitas yang dipartisi dan tidak dipartisi.
  • Pemartisian tersedia di pembuatan namespace layanan untuk SKU olahpesan Premium, dan semua antrean dan topik di namespace layanan tersebut akan dipartisi. Setiap entitas yang dipartisi yang sebelumnya dimigrasikan di namespace Premium akan terus berfungsi seperti yang diharapkan.
  • Saat partisi diaktifkan di SKU Dasar atau Standar, kami akan selalu membuat 16 partisi.
  • Saat partisi diaktifkan di SKU Premium, jumlah partisi ditentukan selama pembuatan namespace layanan.

Tidak dimungkinkan untuk mengubah opsi partisi pada namespace, antrean, atau topik yang ada; Anda hanya dapat mengatur opsi saat membuat entitas.

Cara kerjanya

Setiap antrean atau topik yang dipartisi terdiri dari beberapa partisi. Setiap partisi disimpan di penyimpanan olahpesan yang berbeda dan ditangani oleh broker pesan yang berbeda. Saat pesan dikirim ke antrean atau topik yang dipartisi, Service Bus menetapkan pesan ke salah satu partisi. Pemilihan dilakukan secara acak oleh Service Bus atau dengan menggunakan kunci partisi yang dapat ditentukan oleh pengirim.

Saat klien ingin menerima pesan dari antrean yang dipartisi, atau dari langganan ke topik yang dipartisi, Service Bus meminta semua partisi untuk pesan, lalu mengembalikan pesan pertama yang diperoleh dari salah satu penyimpanan olahpesan ke penerima. Service Bus membuat cache pesan lain dan mengembalikannya saat menerima lebih banyak permintaan. Klien penerima tidak mengetahui partisi; perilaku yang menghadap klien dari antrean atau topik yang dipartisi (misalnya, baca, selesaikan, tangguhkan, deadletter, prefetching) identik dengan perilaku entitas biasa.

Operasi intip pada entitas yang tidak dipartisi selalu mengembalikan pesan terlama, tetapi tidak pada entitas yang dipartisi. Sebaliknya, ia mengembalikan pesan tertua di salah satu partisi yang broker pesannya merespons terlebih dahulu. Tidak ada jaminan bahwa pesan yang dikembalikan adalah yang tertua di semua partisi.

Tidak ada biaya tambahan saat mengirim pesan ke, atau menerima pesan dari, antrean atau topik yang dipartisi.

Catatan

Operasi mengintip mengembalikan pesan tertua dari partisi berdasarkan nomor urutnya. Untuk entitas yang dipartisi, nomor urutan diberikan sesuai dengan partisi. Untuk informasi selengkapnya, lihat Urutan pesan dan tanda waktu.

Penggunaan tombol partisi

Ketika pesan diantrekan ke dalam antrean atau topik yang dipartisi, Service Bus memeriksa keberadaan kunci partisi. Jika menemukan kunci partisi, ia memilih partisi berdasarkan kunci itu. Jika tidak menemukan kunci partisi, ia memilih partisi berdasarkan algoritma internal.

Masukkan kunci partisi

Beberapa skenario, seperti sesi atau transaksi, mengharuskan pesan disimpan dalam partisi tertentu. Semua skenario ini memerlukan penggunaan kunci partisi. Semua pesan yang menggunakan kunci partisi yang sama ditetapkan ke partisi yang sama. Jika partisi tidak tersedia untuk sementara, Service Bus mengembalikan kesalahan.

Bergantung pada skenario, properti pesan yang berbeda digunakan sebagai kunci partisi:

SessionId: Jika pesan memiliki set properti ID sesi, maka Service Bus menggunakannya sebagai kunci partisi. Dengan cara ini, semua pesan yang berada dalam sesi yang sama ditangani oleh broker pesan yang sama. Sesi memungkinkan Service Bus menjamin pengurutan pesan serta konsistensi status sesi.

PartitionKey: Jika pesan memiliki properti kunci partisi tetapi bukan set properti ID sesi, maka Service Bus menggunakan nilai properti kunci partisi sebagai kunci partisi. Jika pesan mengatur properti ID sesi dan kunci partisi, kedua properti harus identik. Jika properti kunci partisi diatur ke nilai yang berbeda dari properti ID sesi, Service Bus mengembalikan pengecualian operasi yang tidak valid. Properti kunci partisi harus digunakan jika pengirim mengirim pesan transaksi yang sadar nonsession. Kunci partisi memastikan semua pesan yang dikirim dalam transaksi ditangani oleh broker pesan yang sama.

MessageId: Jika antrean atau topik dibuat dengan fitur deteksi duplikat dan properti ID sesi atau kunci partisi tidak diatur, maka nilai properti ID pesan berfungsi sebagai kunci partisi. (Pustaka klien Microsoft secara otomatis menetapkan ID pesan jika aplikasi pengirim tidak menetapkannya.) Dalam hal ini, semua salinan pesan yang sama ditangani oleh broker pesan yang sama. ID ini memungkinkan Service Bus mendeteksi dan menghilangkan pesan duplikat. Jika fitur deteksi duplikat tidak diaktifkan, Service Bus tidak akan menganggap properti ID pesan sebagai kunci partisi.

Tidak menggunakan kunci partisi

Dengan tidak adanya kunci partisi, Service Bus mendistribusikan pesan dengan cara round-robin ke semua partisi antrean atau topik yang dipartisi. Jika partisi yang dipilih tidak tersedia, Service Bus menetapkan pesan ke partisi yang berbeda. Dengan cara ini, operasi pengiriman berhasil meskipun penyimpanan olahpesan tidak tersedia untuk sementara. Akan tetapi, Anda tidak akan mencapai pemesanan terjamin yang disediakan kunci partisi.

Untuk diskusi yang lebih mendalam tentang tradeoff antara ketersediaan (tidak ada kunci partisi) dan konsistensi (menggunakan kunci partisi), lihat Ketersediaan dan konsistensi di Event Hubs. Kecuali untuk ID partisi yang tidak diekspos ke pengguna, informasi ini berlaku sama untuk entitas Service Bus yang dipartisi.

Untuk memberi Service Bus cukup waktu untuk mengantrekan pesan ke dalam partisi yang berbeda, nilai batas waktu yang ditentukan klien yang mengirim pesan harus lebih besar dari 15 detik. Nilai default 60 detik disarankan.

Tombol partisi "menyematkan" pesan ke partisi tertentu. Jika penyimpanan olahpesan yang menyimpan partisi ini tidak tersedia, Service Bus mengembalikan kesalahan. Dengan tidak adanya kunci partisi, Service Bus dapat memilih partisi yang berbeda dan operasi akan berhasil. Oleh karena itu, disarankan agar Anda tidak menyediakan kunci partisi kecuali diperlukan.

Topik tingkat lanjut

Gunakan transaksi dengan entitas yang dipartisi

Pesan yang dikirim sebagai bagian dari transaksi harus menentukan kunci partisi. Kuncinya bisa menjadi salah satu properti berikut: ID sesi, kunci partisi, atau ID pesan. Semua pesan yang dikirim sebagai bagian dari transaksi yang sama harus menentukan kunci partisi yang sama. Jika Anda mencoba mengirim pesan tanpa kunci partisi dalam transaksi, Service Bus mengembalikan pengecualian operasi yang tidak valid. Jika Anda mencoba mengirim beberapa pesan dalam transaksi yang sama yang memiliki kunci partisi yang berbeda, Service Bus mengembalikan pengecualian operasi yang tidak valid. Contohnya:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    ServiceBusMessage msg = new ServiceBusMessage("This is a message");
    msg.PartitionKey = "myPartitionKey";
    await sender.SendMessageAsync(msg); 
    ts.Complete();
}
committableTransaction.Commit();

Jika salah satu properti yang berfungsi sebagai kunci partisi diatur, Service Bus menyematkan pesan ke partisi tertentu. Perilaku ini terjadi apabila transaksi digunakan atau tidak. Disarankan agar Anda tidak menentukan kunci partisi jika tidak diperlukan.

Menggunakan transaksi di dalam sesi dengan entitas yang dipartisikan

Untuk mengirim pesan transaksional ke topik atau antrean yang mengetahui sesi, pesan harus memiliki set properti ID sesi. Jika properti kunci partisi juga ditentukan, properti harus identik dengan properti ID sesi. Jika berbeda, Service Bus mengembalikan pengecualian operasi yang tidak valid.

Tidak seperti antrean atau topik reguler (nonpartisi), tidak dimungkinkan untuk menggunakan satu transaksi untuk mengirim beberapa pesan ke sesi yang berbeda. Jika dicoba, Service Bus mengembalikan pengecualian operasi yang tidak valid. Contohnya:

CommittableTransaction committableTransaction = new CommittableTransaction();
using (TransactionScope ts = new TransactionScope(committableTransaction))
{
    ServiceBusMessage msg = new ServiceBusMessage("This is a message");
    msg.SessionId = "mySession";
    await sender.SendMessageAsync(msg); 
    ts.Complete();
}
committableTransaction.Commit();

Penerusan pesan otomatis dengan entitas yang dipartisi

Service Bus mendukung penerusan pesan otomatis dari, ke, atau antara entitas yang dipartisi. Anda dapat mengaktifkan fitur ini saat membuat atau memperbarui antrean dan langganan. Untuk informasi selengkapnya, lihat Mengaktifkan penerusan pesan. Jika pesan menentukan kunci partisi (ID sesi, kunci partisi atau ID pesan), kunci partisi tersebut digunakan untuk entitas tujuan.

Pertimbangan dan pedoman

  • Fitur konsistensi tinggi: Jika entitas menggunakan fitur seperti sesi, deteksi duplikat, atau kontrol eksplisit kunci partisi, maka operasi olahpesan selalu dirutekan ke partisi tertentu. Jika salah satu partisi mengalami lalu lintas tinggi atau penyimpanan yang mendasarinya tidak sehat, operasi tersebut akan gagal dan ketersediaan berkurang. Secara keseluruhan, konsistensinya masih jauh lebih tinggi daripada entitas nonpartisi; hanya subset lalu lintas yang mengalami masalah, dibandingkan dengan semua lalu lintas. Untuk informasi selengkapnya, lihat diskusi ketersediaan dan konsistensi ini.
  • Manajemen: Operasi seperti Buat, Perbarui, dan Hapus harus dilakukan pada semua partisi entitas. Jika ada partisi yang tidak sehat, bisa mengakibatkan kegagalan untuk operasi ini. Untuk operasi Dapatkan, informasi seperti jumlah pesan harus diagregasi dari semua partisi. Jika ada partisi yang tidak sehat, status ketersediaan entitas dilaporkan terbatas.
  • Skenario pesan volume rendah: Untuk skenario tersebut, terutama saat menggunakan protokol HTTP, Anda mungkin harus melakukan beberapa operasi penerimaan untuk mendapatkan semua pesan. Untuk menerima permintaan, ujung depan melakukan terima pada semua partisi dan membuat cache semua respons yang diterima. Permintaan penerimaan berikutnya pada koneksi yang sama akan mendapat manfaat dari penembolokan ini dan menerima latensi lebih rendah. Namun, jika Anda memiliki beberapa koneksi atau menggunakan HTTP, koneksi baru dibuat untuk setiap permintaan. Dengan demikian, tidak ada jaminan bahwa ia akan mendarat di node yang sama. Jika semua pesan yang ada dikunci dan di-cache di ujung depan lain, operasi terima mengembalikan null. Pesan akhirnya kedaluwarsa dan Anda dapat menerimanya lagi. Direkomendasikan HTTP tetap aktif. Saat menggunakan partisi dalam skenario volume rendah, operasi penerimaan mungkin memakan waktu lebih lama dari yang diharapkan. Oleh karena itu, sebaiknya Anda tidak menggunakan partisi dalam skenario ini. Hapus entitas partisi yang ada dan buat ulang dengan partisi yang dinonaktifkan untuk meningkatkan kinerja.
  • Menelusuri/Mengintip pesan: Operasi mengintip tidak selalu mengembalikan jumlah pesan yang diminta. Ada dua alasan umum untuk perilaku ini. Salah satu alasannya adalah ukuran agregat kumpulan pesan melebihi ukuran maksimum. Alasan lain adalah bahwa dalam antrean atau topik yang dipartisi, partisi mungkin tidak memiliki cukup pesan untuk mengembalikan jumlah pesan yang diminta. Secara umum, jika aplikasi ingin mengintip/menelusuri sejumlah pesan, aplikasi harus memanggil operasi mengintip berulang kali sampai mendapatkan jumlah pesan itu, atau tidak ada lagi pesan untuk diintip. Untuk informasi selengkapnya, termasuk sampel kode, lihat Penjelajahan pesan.

Batasan entitas yang dipartisi

Saat ini Service Bus memberlakukan batasan berikut pada antrean dan topik yang dipartisi:

  • Untuk namespace premium yang dipartisi, ukuran pesan dibatasi hingga 1 MB saat pesan dikirim satu per satu, dan ukuran batch dibatasi hingga 1 MB saat pesan dikirim dalam batch.
  • Antrean dan topik yang dipartisi tidak mendukung pengiriman pesan yang termasuk dalam sesi yang berbeda dalam satu transaksi.
  • Bus Layanan saat ini memungkinkan hingga 100 antrean atau topik yang dipartisi per namespace layanan untuk SKU Dasar dan Standar. Setiap antrean atau topik yang dipartisi diperhitungkan dalam kuota 10.000 entitas per namespace.

Langkah berikutnya

Anda dapat mengaktifkan partisi dengan menggunakan portal Microsoft Azure, PowerShell, CLI, Templat Resource Manager, .NET, Java, Python, dan JavaScript. Untuk informasi selengkapnya, lihat Mengaktifkan partisi (Dasar/Standar).

Baca tentang konsep inti dari spesifikasi olahpesan Advanced Message Queueing Protocol (AMQP) 1.0 dalam panduan protokol AMQP 1.0.