Sesi pesan
Sesi Azure Service Bus memungkinkan penanganan bersama dan terpesan dari urutan pesan terkait yang tidak terbatas. Sesi dapat digunakan pada first in, first out (FIFO) dan pola respons permintaan. Artikel ini memperlihatkan cara menggunakan sesi untuk menerapkan pola ini saat menggunakan Service Bus.
Catatan
Tingkat dasar Service Bus tidak mendukung sesi. Tingkatan standar dan premium mendukung sesi. Untuk perbedaan antara tingkatan ini, lihat Harga Service Bus.
Pola first-in, first out (FIFO)
Untuk mewujudkan jaminan FIFO dalam memproses pesan dalam antrean atau langganan Bus Layanan, gunakan sesi. Microsoft Azure Service Bus tidak reseptif tentang sifat hubungan antara pesan, dan juga tidak menentukan model tertentu untuk menentukan di mana urutan pesan dimulai atau berakhir.
Setiap pengirim dapat membuat sesi saat mengirimkan pesan ke dalam topik atau antrean dengan mengatur properti ID sesi ke beberapa pengidentifikasi yang ditentukan aplikasi yang unik untuk sesi tersebut. Pada tingkat protokol AMQP 1.0, nilai ini memetakan properti d grup.
Pada antrean atau langganan yang diketahui sesi, sesi muncul ketika setidaknya ada satu pesan dengan ID sesi. Setelah sesi ada, tidak ada waktu atau API yang ditentukan saat sesi berakhir atau menghilang. Secara teoritis, pesan dapat diterima untuk sesi hari ini, pesan berikutnya dalam waktu setahun, dan jika ID sesi cocok, sesi ini sama dari perspektif Service Bus.
Namun, biasanya, aplikasi memiliki gagasan yang jelas tentang di mana sekumpulan pesan terkait dimulai dan berakhir. Service Bus tidak menetapkan aturan khusus. Misalnya, aplikasi Anda dapat mengatur properti Label untuk pesan pertama yang dimulai, untuk pesan perantara ke konten, dan untuk pesan terakhir berakhir. Posisi relatif pesan konten dapat dihitung sebagai pesan saat ini SequenceNumber delta dari pesan awalSequenceNumber.
Penting
Jika sesi diaktifkan pada antrean atau langganan, aplikasi klien tidak dapat lagi mengirim/menerima pesan biasa. Semua pesan harus dikirim sebagai bagian dari sesi (dengan mengatur id sesi) dan diterima dengan menerima sesi. Klien mungkin masih mengintip antrean atau langganan yang mengaktifkan sesi. Lihat Penjelajahan pesan.
API untuk sesi ada pada klien antrean dan langganan. Ada model penting yang mengontrol kapan sesi dan pesan diterima, dan model berbasis handler yang menyembunyikan kompleksitas mengelola loop yang diterima.
Untuk sampel, gunakan tautan di bagian Langkah berikutnya.
Fitur sesi
Sesi menyediakan demultiplexing bersamaan dari aliran pesan yang saling terkait sambil mempertahankan dan menjamin pengiriman yang dipesan.
Penerima sesi dibuat oleh klien yang menerima sesi. Ketika sesi diterima dan dipegang oleh klien, klien memegang kunci eksklusif pada semua pesan dengan ID sesi tersebut dalam antrean atau langganan. Ini menyimpan kunci eksklusif pada semua pesan dengan ID sesi yang tiba nanti.
Kunci dilepaskan ketika Anda memanggil metode terkait dekat pada penerima atau ketika kunci kedaluwarsa. Ada metode pada penerima untuk memperbarui kunci juga. Sebagai gantinya, Anda dapat menggunakan fitur perpanjangan kunci otomatis di mana Anda inginkan agar durasi kunci tetap diperpanjang. 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 saling terkait dalam satu antrean atau langganan didemultiplexed dengan bersih ke penerima yang berbeda dan penerima tersebut juga dapat hidup di komputer klien yang berbeda, karena manajemen kunci terjadi sisi layanan, di dalam Bus Layanan.
Ilustrasi sebelumnya menunjukkan tiga penerima sesi bersamaan. Satu Sesi dengan SessionId = 4 tidak memiliki klien aktif dan memiliki, yang berarti bahwa tidak ada pesan yang dikirim dari sesi tertentu ini. Sesi bertindak dalam banyak hal seperti sub antrean.
Kunci sesi yang dipegang oleh penerima sesi adalah payung untuk kunci pesan yang digunakan oleh mode penyelesaian peek-lock. Hanya satu penerima yang dapat mengunci sesi. Penerima mungkin memiliki banyak pesan dalam penerbangan, tetapi pesan diterima secara berurutan. Meninggalkan pesan menyebabkan pesan yang sama dilayani lagi dengan operasi penerima berikutnya.
Status sesi pesan
Ketika alur kerja diproses dalam sistem cloud berskala tinggi dan berpotensi tinggi, handler 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 menjadi langsung tersedia ketika sesi diperoleh oleh prosesor baru.
Dari perspektif Azure Service Bus, status sesi pesan adalah objek biner buram yang dapat menyimpan data berukuran satu pesan, yaitu 256 KB untuk Azure Service Bus Standard, dan 100 MB untuk Azure Service Bus Premium. Status pemrosesan relatif terhadap sesi dapat diadakan 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 dibersihkan dengan meneruskan null ke SetState metode pada penerima.
Status sesi tetap selama tidak dibersihkan (mengembalikan null), meskipun semua pesan dalam sesi digunakan.
Status sesi yang diadakan dalam antrean atau dalam langganan diperhitungkan dalam kuota penyimpanan entitas tersebut. Ketika aplikasi selesai dengan sesi, oleh karena itu disarankan bagi aplikasi untuk membersihkan status yang dipertahankan untuk menghindari biaya manajemen eksternal.
Dampak jumlah pengiriman
Definisi jumlah pengiriman per pesan dalam konteks sesi sedikit berbeda dari definisi tanpa adanya sesi. Berikut adalah tabel yang meringkas saat jumlah pengiriman bertambah.
| Skenario | Apakah jumlah pengiriman pesan bertahap |
|---|---|
| Sesi diterima, tetapi kunci sesi kedaluwarsa (karena waktu habis) | Ya |
| Sesi diterima, pesan dalam sesi tidak selesai (meskipun dikunci), dan sesi ditutup | No |
| 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 permintaan balasan adalah pola integrasi yang mapan yang memungkinkan aplikasi pengirim mengirim permintaan dan menyediakan cara bagi penerima untuk mengirim respons kembali ke aplikasi pengirim dengan benar. Pola ini biasanya membutuhkan antrean atau topik berumur pendek bagi aplikasi untuk mengirim tanggapan. Dalam skenario ini, sesi memberikan 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 datang dalam antrean dan mengirim balasan pada sesi yang diaktifkan antrean, mengatur ID sesi ke pengidentifikasi unik yang dikirim pengirim pada pesan permintaan. Aplikasi yang mengirim permintaan kemudian dapat menerima pesan pada ID sesi tertentu dan memproses balasan dengan benar.
Catatan
Aplikasi yang mengirim permintaan awal harus tahu tentang ID sesi dan menggunakannya untuk menerima sesi sehingga sesi di mana ia mengharapkan respons dikunci. Ada baiknya menggunakan GUID yang secara unik mengidentifikasi contoh aplikasi sebagai id sesi. Seharusnya tidak ada handler sesi atau batas waktu yang ditentukan pada penerima sesi untuk antrean untuk memastikan bahwa respons tersedia untuk dikunci dan diproses oleh penerima tertentu.
Mengurutkan vs. sesi
Nomor urut sendiri menjamin urutan antrean dan urutan ekstraksi pesan, tetapi bukan urutan pemrosesan, yang memerlukan sesi.
Katakanlah, ada tiga pesan dalam antrean dan dua konsumen.
- Konsumen 1 mengambil pesan 1.
- Konsumen 2 mengambil pesan 2.
- Konsumen 2 menyelesaikan pemrosesan pesan 2 dan mengambil pesan 3, sementara Konsumen 1 belum selesai memproses pesan 1.
- Konsumen 2 menyelesaikan pemrosesan pesan 3, tetapi konsumen 1 masih belum dilakukan dengan pesan pemrosesan 1.
- 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 dimiliki bersama-sama, yang dapat berupa pesan 1, 4, dan 8 dalam satu set, dan 2, 3, dan 6 di set lain.
Kedaluwarsa pesan
Untuk antrean yang diaktifkan sesi atau langganan topik, pesan dikunci di tingkat sesi. Jika time-to-live (TTL) untuk salah satu pesan kedaluwarsa, semua pesan yang terkait dengan sesi tersebut dihilangkan atau dimatikan berdasarkan dead-lettering yang diaktifkan pada pengaturan kedaluwarsa olahpesan pada entitas. 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.
Langkah berikutnya
Anda dapat mengaktifkan sesi pesan saat membuat antrean menggunakan portal Microsoft Azure, PowerShell, CLI, template 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.
- .BERSIH
- Java
- Python
- JavaScript