Bagikan melalui

Sesi pesan

Sesi Azure Service Bus memungkinkan pemrosesan bersama dan terurut dari urutan pesan terkait yang tidak terbatas. Sesi dapat digunakan dalam pola masuk pertama, keluar pertama (FIFO) dan permintaan-respons. Artikel ini memperlihatkan cara menggunakan sesi untuk mengimplementasikan pola-pola ini saat menggunakan Bus Layanan.

Nota

Tingkat dasar Service Bus tidak mendukung sesi. Tingkatan standar dan premium mendukung sesi. Untuk perbedaan antara tingkatan ini, lihat Harga Service Bus.

Pola 'masuk pertama, keluar pertama' (FIFO)

Untuk mencapai pemrosesan FIFO dalam memproses pesan dari antrean atau langganan Service Bus, gunakan sesi. Service Bus tidak preskriptif tentang sifat hubungan antara pesan, dan juga tidak menentukan model khusus untuk menentukan di mana urutan pesan dimulai atau berakhir.

Pengirim dapat memulai sesi saat mengirimkan pesan ke dalam topik atau antrean dengan mengatur properti ID sesi ke pengidentifikasi unik yang ditentukan oleh aplikasi. Pada tingkat protokol AMQP 1.0 , nilai ini memetakan ke properti id grup .

Pada antrean atau langganan yang mendukung sesi, sesi terbentuk ketika ada setidaknya satu pesan dengan ID sesi. Setelah sesi ada, tidak ada waktu atau API yang ditentukan saat sesi kedaluwarsa atau menghilang. Secara teoritis, pesan dapat diterima untuk sesi hari ini, lalu pesan berikutnya dalam waktu satu tahun, dan jika ID sesi cocok, sesi tersebut dianggap sama dari perspektif Service Bus.

Namun, biasanya, aplikasi menentukan di mana sekumpulan pesan terkait dimulai dan berakhir. Azure Service Bus tidak memberlakukan aturan tertentu. Misalnya, aplikasi Anda dapat mengatur properti Label untuk pesan pertama sebagai awal, untuk pesan perantara sebagai konten, dan agar pesan terakhir berakhir. Posisi relatif pesan konten dapat dihitung sebagai delta SequenceNumber pesan saat ini dari pesan awalSequenceNumber.

Penting

Ketika sesi diaktifkan pada antrean atau langganan, aplikasi klien tidak dapat lagi mengirim/menerima pesan reguler. Klien harus mengirim pesan sebagai bagian dari sesi dengan mengatur ID sesi dan diterima dengan menerima sesi. Klien mungkin masih mengakses antrian atau langganan dengan sesi yang diaktifkan. Lihat Penjelajahan pesan.

API untuk sesi tersedia pada klien antrian dan langganan. Ada dua cara untuk menerima sesi dan pesan: model imperatif, di mana Anda mengontrol kapan dan bagaimana pesan diterima secara manual, dan model berbasis handler, yang menyederhanakan hal-hal dengan secara otomatis mengelola perulangan dan pemrosesan pesan.

Untuk sampel, gunakan tautan di bagian Sampel .

Fitur sesi

Sesi menyediakan demultiplexing bersamaan dari aliran pesan yang saling terkait sambil mempertahankan dan menjamin pengiriman yang dipesan.

Diagram yang memperlihatkan bagaimana fitur Sesi mempertahankan pengiriman yang dipesan.

Seorang klien membuat alat penerima sesi untuk menerima sebuah sesi. Ketika klien menerima dan menyelenggarakan sesi, klien memegang kunci eksklusif pada semua pesan dengan ID sesi tersebut dalam antrean atau langganan. Ini mempertahankan kunci eksklusif pada semua pesan dengan ID sesi yang tiba kemudian.

Kunci dilepaskan saat Anda memanggil metode penutupan pada penerima atau ketika masa berlaku kunci berakhir. Ada juga metode pada penerima untuk memperbarui kunci. Sebagai gantinya, Anda dapat menggunakan fitur perpanjangan kunci otomatis tempat Anda dapat menentukan durasi waktu yang ingin Anda perpanjang. Kunci sesi harus diperlakukan seperti kunci eksklusif pada file, yang berarti bahwa aplikasi harus menutup sesi segera setelah tidak lagi membutuhkannya dan/atau tidak mengharapkan pesan lebih lanjut.

Ketika beberapa penerima bersamaan menarik dari antrean, pesan milik sesi tertentu dikirim ke penerima tertentu yang saat ini memegang kunci untuk sesi tersebut. Dengan operasi itu, aliran pesan yang terselang-seling dalam satu antrean atau langganan dipisahkan secara bersih ke penerima yang berbeda, dan penerima tersebut juga dapat beroperasi di komputer klien yang berbeda, karena manajemen kunci terjadi di pihak layanan, di dalam Service Bus.

Ilustrasi sebelumnya menunjukkan tiga penerima sesi serentak. Satu Sesi dengan SessionId = 4 tidak memiliki klien aktif dan pemilik, yang berarti bahwa tidak ada pesan yang dikirimkan dari sesi khusus ini. Sesi berfungsi dalam banyak cara seperti antrean sub.

Kunci sesi yang dipegang oleh penerima sesi adalah payung bagi penguncian pesan yang digunakan oleh modus penyelesaian peek-lock. Hanya satu penerima yang dapat mengunci sesi. Penerima mungkin memiliki banyak pesan dalam penerbangan, tetapi pesan diterima secara berurutan. Mengabaikan pesan akan mengakibatkan pesan yang sama dikirim ulang pada operasi penerimaan berikutnya.

Status sesi pesan

Ketika alur kerja diproses dalam sistem cloud berskala tinggi dan ketersediaan tinggi, penanganan alur kerja yang terkait dengan sesi tertentu harus dapat pulih dari kegagalan yang tidak terduga dan dapat melanjutkan pekerjaan yang diselesaikan sebagian pada proses atau mesin yang berbeda dari tempat pekerjaan dimulai.

Fasilitas status sesi memungkinkan anotasi sesi pesan yang ditentukan aplikasi di dalam broker, sehingga status pemrosesan yang direkam relatif terhadap sesi tersebut tersedia secara instan ketika sesi diperoleh oleh prosesor baru.

Dari perspektif Service Bus, status sesi pesan adalah objek biner buram yang dapat menyimpan data dengan ukuran satu pesan, yaitu 256 KB untuk Service Bus Standard, dan 100 MB untuk Service Bus Premium. Status pemrosesan relatif terhadap sesi dapat ditahan di dalam status sesi, atau status sesi dapat menunjuk ke beberapa lokasi penyimpanan atau rekaman database yang menyimpan informasi tersebut.

Metode untuk mengelola status sesi, SetState, dan GetState, dapat ditemukan pada objek penerima sesi. Sesi yang sebelumnya tidak memiliki status sesi mengembalikan referensi null untuk GetState. Status sesi yang ditetapkan sebelumnya dapat dihapus dengan meneruskan null ke metode SetState pada penerima.

Status sesi tetap selama tidak dibersihkan (mengembalikan null), bahkan jika semua pesan dalam sesi digunakan.

Status sesi yang disimpan dalam antrean atau dalam langganan dihitung dalam kuota penyimpanan entitas tersebut. Ketika aplikasi selesai dengan sesi, disarankan bagi aplikasi untuk menghapus status yang disimpannya untuk mencegah biaya manajemen eksternal.

Dampak jumlah pengiriman

Definisi jumlah pengiriman per pesan dalam konteks sesi sedikit bervariasi dari definisi tanpa adanya sesi. Berikut adalah tabel yang meringkas saat jumlah pengiriman bertambah.

Skenario Apakah jumlah pengiriman pesan bertambah
Sesi diterima, tetapi kunci sesi kedaluwarsa (karena waktu habis) Ya
Sesi diterima, pesan dalam sesi tidak selesai (meskipun dikunci), dan sesi ditutup Tidak.
Sesi diterima, pesan selesai, lalu sesi ditutup secara eksplisit N/A (Ini adalah alur standar. Di sini, pesan dihapus dari sesi)

Pola respons permintaan

Pola balasan permintaan adalah pola integrasi yang mapan yang memungkinkan aplikasi pengirim mengirim permintaan dan menyediakan cara bagi penerima untuk mengirim respons kembali dengan benar ke aplikasi pengirim. Pola ini biasanya memerlukan antrean atau topik berumur pendek agar aplikasi dapat mengirim respons. Dalam skenario ini, sesi menyediakan solusi alternatif sederhana dengan semantik yang sebanding.

Beberapa aplikasi dapat mengirim permintaan mereka ke satu antrean permintaan, dengan parameter header tertentu diatur untuk mengidentifikasi aplikasi pengirim secara unik. Aplikasi penerima dapat memproses permintaan yang masuk dalam antrian dan mengirim balasan pada antrian yang diaktifkan oleh sesi, dengan mengatur ID sesi ke pengidentifikasi unik yang dikirim oleh pengirim pada pesan permintaan. Aplikasi yang mengirim permintaan kemudian dapat menerima pesan pada ID sesi tertentu dan memproses balasan dengan benar.

Nota

Aplikasi yang mengirim permintaan awal harus mengetahui ID sesi dan menggunakannya untuk menerima sesi sehingga sesi yang mengharapkan respons tersebut terkunci. Sebaiknya gunakan GUID yang secara unik mengidentifikasi instans aplikasi sebagai ID sesi. Tidak boleh ada pengelola sesi atau batas waktu yang ditentukan pada penerima sesi untuk antrian, agar respons dapat dikunci dan diproses oleh penerima tertentu.

Pengurutan vs. Sesi

Nomor urut sendiri menjamin urutan antrean dan urutan ekstraksi pesan, tetapi bukan urutan pemrosesan, yang memerlukan sesi.

Katakanlah, ada tiga pesan dalam antrian dan dua konsumen.

  1. Konsumen 1 mengambil pesan 1.
  2. Pesan 2 diambil oleh Konsumen 2.
  3. Konsumen 2 menyelesaikan pemrosesan pesan 2 dan mengambil pesan 3, sementara Konsumen 1 belum selesai memproses pesan 1.
  4. Konsumen 2 menyelesaikan pemrosesan pesan 3, tetapi konsumen 1 masih belum menyelesaikan pemrosesan pesan 1.
  5. Terakhir, konsumen 1 menyelesaikan pesan pemrosesan 1.

Jadi, pesan diproses dalam urutan ini: pesan 2, pesan 3, dan pesan 1. Jika Anda memerlukan pesan 1, 2, dan 3 untuk diproses secara berurutan, Anda perlu menggunakan sesi.

Jika pesan hanya perlu diambil secara berurutan, Anda tidak perlu menggunakan sesi. Jika pesan perlu diproses secara berurutan, gunakan sesi. ID sesi yang sama harus diatur pada pesan yang termasuk dalam satu kelompok, seperti pesan 1, 4, dan 8 dalam satu set, dan pesan 2, 3, dan 6 di set lainnya.

Kedaluwarsa pesan

Untuk antrean atau langganan topik yang mendukung sesi, pesan dikunci pada tingkat sesi. Jika time-to-live (TTL) untuk salah satu pesan kedaluwarsa, semua pesan yang terkait dengan sesi tersebut akan dihapus atau dimasukkan ke dalam 'dead-letter queue' berdasarkan pengaturan dead-lettering yang diaktifkan pada kedaluwarsa pesan pada entitas tersebut. Dengan kata lain, jika ada satu pesan dalam sesi yang telah melewati TTL, semua pesan dalam sesi akan kedaluwarsa. Pesan kedaluwarsa hanya jika ada pendengar aktif. Untuk informasi selengkapnya, lihat Kedaluwarsa pesan.

Contoh-contoh

Anda dapat mengaktifkan sesi pesan saat membuat antrean menggunakan portal Microsoft Azure, PowerShell, CLI, templat Resource Manager, .NET, Java, Python, dan JavaScript. Untuk informasi selengkapnya, lihat Mengaktifkan sesi pesan.

Cobalah sampel dalam bahasa pilihan Anda untuk menjelajahi fitur Azure Service Bus.

Konten terkait