Bagikan melalui

Azure Service Bus - Kedaluwarsa pesan (Waktu Aktif)

  • Artikel

Payload dalam pesan, atau perintah atau pertanyaan yang disampaikan pesan kepada penerima, hampir selalu tunduk pada beberapa bentuk tenggat waktu kedaluwarsa tingkat aplikasi. Setelah tenggat waktu tersebut, konten tidak lagi dikirim, atau operasi yang diminta tidak lagi dijalankan.

Untuk lingkungan pengembangan dan pengujian, di mana antrean dan topik sering digunakan dalam konteks menjalankan sebagian aplikasi atau bagian aplikasi, pesan pengujian yang terlantar juga diinginkan untuk secara otomatis dikumpulkan sampahnya sehingga pengujian selanjutnya dapat dimulai dengan bersih.

Catatan

Jika Anda belum memahami konsep Azure Service Bus, lihat konsep Azure Service Bus, dan antrean, topik, serta langganan Azure Service Bus.

Kedaluwarsa untuk setiap pesan individual dapat dikontrol dengan mengatur properti sistem time-to-live, yang menentukan durasi relatif. Kedaluwarsa menjadi instan absolut ketika pesan diantrekan ke entitas. Pada saat itu, properti expires-at-utc menggunakan nilai enqueued-time-utc + time-to-live. Pengaturan time-to-live (TTL) pada pesan yang diperantarai tidak diberlakukan ketika tidak ada klien yang aktif mendengarkan.

Setelah instan expires-at-utc, pesan menjadi tidak memenuhi syarat untuk diambil. Kedaluwarsa tidak memengaruhi pesan yang saat ini dikunci untuk pengiriman. Pesan-pesan tersebut masih ditangani secara normal. Jika kunci telah kedaluwarsa atau pesan ditinggalkan, maka kedaluwarsa akan segera berlaku. Saat pesan terkunci, aplikasi mungkin memiliki pesan yang telah kedaluwarsa. Apakah aplikasi bersedia melanjutkan pemrosesan atau memilih untuk meninggalkan pesan, itu terserah pelaksananya.

TTL yang sangat rendah dalam urutan milidetik atau detik dapat menyebabkan pesan kedaluwarsa sebelum aplikasi penerima menerimanya. Pertimbangkan TTL tertinggi yang berfungsi untuk aplikasi Anda.

Catatan

Untuk pesan terjadwal, Anda menentukan waktu antrean di mana Anda ingin pesan terwujud dalam antrean untuk pengambilan. Waktu di mana pesan dikirim ke Bus Layanan berbeda dari waktu di mana pesan diantrekan. Waktu kedaluwarsa pesan tergantung pada waktu antrean, bukan pada waktu di mana pesan dikirim ke Bus Layanan. Oleh karena itu, kedaluwarsa-pada-utc masih diantrekan waktu + time-to-live.

Misalnya, jika Anda mengatur ScheduledEnqueueTimeUtc ke 5 menit dari UtcNow, dan TimeToLive menjadi 10 menit, pesan akan kedaluwarsa setelah 5 + 10 = 15 menit dari sekarang. Pesan terwujud dalam antrean setelah 5 menit dan penghitung 10 menit dimulai dari saat itu.

Kedaluwarsa tingkat entitas

Semua pesan yang dikirim ke dalam antrean atau topik tunduk pada kedaluwarsa default yang diatur di tingkat entitas. Hal ini juga dapat diatur di portal selama pembuatan dan disesuaikan nanti. Kedaluwarsa default digunakan untuk semua pesan yang dikirim ke entitas di mana time-to-live tidak diatur secara eksplisit. Kedaluwarsa default juga berfungsi sebagai batas atas nilai time-to-live. Pesan yang memiliki time-to-live kedaluwarsa lebih lama dari nilai default secara diam-diam disesuaikan ke nilai waktu hidup pesan default sebelum diantrekan.

Catatan

  • Nilai time-to-live default untuk pesan broker adalah nilai terbesar yang mungkin untuk bilangan bulat 64-bit yang dimasukan jika tidak ditentukan sebaliknya.
  • Untuk entitas olahpesan (antrean dan topik), waktu kedaluwarsa default juga merupakan nilai terbesar yang memungkinkan untuk bilangan bulat 64-bit yang ditandatangani untuk tingkat Standar dan premium Azure Service Bus. Untuk tingkat dasar, waktu kedaluwarsa default (juga maksimum) adalah 14 hari.
  • Jika topik menentukan TTL yang lebih kecil dari langganan, topik TTL diterapkan.

Pesan yang kedaluwarsa secara opsional dapat dipindahkan ke antrean surat gagal. Anda dapat mengonfigurasi pengaturan ini secara terprogram atau menggunakan portal Azure. Jika opsi dinonaktifkan, pesan yang kedaluwarsa akan dihapus Pesan yang kedaluwarsa dipindahkan ke antrean surat gagal dapat dibedakan dari pesan surat gagal lainnya dengan mengevaluasi properti alasan surat gagal yang disimpan broker di bagian properti pengguna.

Jika pesan dilindungi dari kedaluwarsa saat terkunci dan jika bendera diatur pada entitas, pesan akan dipindahkan ke antrean surat gagal saat kunci tidak digunakan atau kedaluwarsa. Namun, tidak dipindahkan jika pesan berhasil diselesaikan, yang kemudian mengasumsikan bahwa aplikasi telah berhasil menanganinya, terlepas dari kedaluwarsa nominal. Untuk informasi selengkapnya tentang penguncian dan penyelesaian pesan, lihat Transfer, penguncian, dan penyelesaian pesan.

Kombinasi surat gagal time-to-live dan otomatis (dan transaksional) pada kedaluwarsa adalah alat yang berharga untuk membangun kepercayaan diri apakah pekerjaan yang diberikan kepada penangan atau sekelompok penangan di bawah tenggat waktu diambil untuk diproses saat tenggat waktu tercapai.

Misalnya, pertimbangkan situs web yang perlu menjalankan pekerjaan dengan andal pada backend dengan skala terbatas, dan yang terkadang mengalami lonjakan lalu lintas atau ingin diisolasi dari episode ketersediaan backend tersebut. Dalam kasus reguler, penangan sisi server untuk data pengguna yang dikirimkan mendorong informasi ke dalam antrean dan kemudian menerima balasan yang mengonfirmasi penanganan transaksi yang berhasil ke dalam antrian balasan. Jika ada lonjakan lalu lintas dan handler backend tidak dapat memproses item backlog-nya tepat waktu, pekerjaan yang kedaluwarsa dikembalikan pada antrean dead-letter. Pengguna interaktif dapat diberi tahu bahwa operasi yang diminta membutuhkan waktu sedikit lebih lama dari biasanya, dan permintaan kemudian dapat diletakkan pada antrean yang berbeda untuk jalur pemrosesan di mana hasil pemrosesan akhirnya dikirim ke pengguna melalui email.

Kedaluwarsa untuk entitas yang mendukung sesi

Untuk antrean yang diaktifkan sesi atau langganan topik, pesan dikunci di tingkat sesi. Jika TTL untuk salah satu pesan kedaluwarsa, semua pesan yang terkait dengan sesi tersebut dihilangkan atau di-dead-letter 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.

Entitas sementara

Antrean Service Bus, topik, dan langganan dapat dibuat sebagai entitas sementara, yang secara otomatis dihapus ketika mereka tidak digunakan untuk jangka waktu tertentu.

Pembersihan otomatis berguna dalam skenario pengembangan dan pengujian di mana entitas dibuat secara dinamis dan tidak dibersihkan setelah digunakan, karena beberapa gangguan pada pengujian atau eksekusi debugging. Hal ini juga berguna saat aplikasi membuat entitas dinamis, seperti antrean balasan, untuk menerima respons kembali ke proses server web, atau ke objek lain yang relatif berumur pendek yang sulit untuk membersihkan entitas tersebut secara andal saat instans objek menghilang.

Fitur ini diaktifkan menggunakan properti hapus otomatis saat menganggur di namespace. Properti ini diatur ke durasi saat entitas harus diam (tidak digunakan) sebelum dihapus secara otomatis. Nilai minimum untuk properti ini adalah 5 menit.

Penting

Mengatur tingkat kunci Azure Resource Manager ke CanNotDelete, di namespace, atau di tingkat yang lebih tinggi tidak mencegah entitas dengan AutoDeleteOnIdle dihapus. Jika Anda tidak ingin entitas dihapus, atur properti AutoDeleteOnIdle ke DataTime.MaxValue.

Menganggur

Inilah yang dianggap sebagai entitas menganggur (antrean, topik, dan langganan):

Entitas Apa yang dianggap diam
Antrean
  • Tidak ada pengiriman
  • Tidak ada penerimaan
  • Tidak ada pembaruan pada antrean
  • Tidak ada pesan terjadwal
  • Tidak ada penelusuran/mengintip
Topik
  • Tidak ada pengiriman
  • Tidak ada pembaruan untuk topik
  • Tidak ada pesan terjadwal
  • Tidak ada operasi pada langganan topik (lihat baris berikutnya)
Langganan
  • Tidak ada penerimaan
  • Tidak ada pembaruan untuk langganan
  • Tidak ada aturan baru yang ditambahkan ke langganan
  • Tidak ada penelusuran/mengintip

Penting

Jika Anda memiliki penyiapan penerusan otomatis pada antrean atau langganan, yang setara dengan menerima peform penerima pada antrean atau langganan dan tidak akan menganggur.

SDK

Langkah berikutnya

Untuk mempelajari selengkapnya tentang olahpesan Service Bus, lihat topik berikut ini: