Antrean Azure Storage dan antrean Azure Service Bus - perbandingan dan kontras
Artikel ini menganalisis perbedaan dan persamaan antara dua jenis antrean yang ditawarkan oleh Microsoft Azure: Antrean Storage dan antrean Service Bus. Dengan menggunakan informasi ini, Anda dapat membuat keputusan yang lebih matang tentang solusi yang paling sesuai dengan kebutuhan Anda.
Pendahuluan
Azure mendukung dua jenis mekanisme antrean: Antrean Storage dan antrean Service Bus.
Antrean Storage adalah bagian dari infrastruktur Azure Storage. Ini memungkinkan Anda untuk menyimpan pesan dalam jumlah besar. Anda bisa mengakses pesan dari mana saja di dunia melalui panggilan terautentikasi menggunakan HTTP atau HTTPS. Pesan antrean dapat berukuran hingga 64 KB. Antrean dapat berisi jutaan pesan, hingga mencapai batas kapasitas total dari akun penyimpanan. Antrean umumnya digunakan untuk membuat backlog pekerjaan untuk diproses secara asinkron. Untuk informasi selengkapnya, lihat Apa itu antrean Azure Storage.
Antrean Service Bus adalah bagian dari infrastruktur olah pesan Azure yang lebih luas yang mendukung antrean, publikasi/langganan, dan pola integrasi yang lebih canggih. Mereka dirancang untuk mengintegrasikan aplikasi atau komponen aplikasi yang mungkin mencakup beberapa protokol komunikasi, kontrak data, domain kepercayaan, atau lingkungan jaringan. Untuk informasi selengkapnya tentang antrean/topik/langganan Service Bus, lihat antrean, topik, dan langganan Service Bus.
Pertimbangan pemilihan teknologi
Antrean Storage dan antrean Service Bus memiliki set fitur yang sedikit berbeda. Anda dapat memilih salah satu atau keduanya, tergantung kebutuhan solusi khusus Anda.
Ketika menentukan teknologi antrean yang sesuai dengan tujuan solusi yang diberikan, arsitek dan developer solusi harus mempertimbangkan rekomendasi ini.
Pertimbangkan untuk menggunakan antrean Storage
Sebagai arsitek/developer solusi, Anda harus mempertimbangkan menggunakan antrean Storage saat:
- Aplikasi harus menyimpan lebih dari 80 gigabyte pesan dalam suatu antrean.
- Aplikasi ingin melacak kemajuan untuk memproses pesan dalam antrean. Ini berguna jika pekerja yang memproses pesan crash. Pekerja lain kemudian dapat menggunakan informasi tersebut untuk melanjutkan dari tempat terakhir yang ditangani pekerja sebelumnya.
- Anda memerlukan log sisi server dari semua transaksi yang dijalankan terhadap antrean Anda.
Pertimbangkan untuk menggunakan antrean Service Bus
Sebagai arsitek/developer solusi, Anda harus mempertimbangkan untuk menggunakan antrean Service Bus ketika:
- Solusi perlu menerima pesan tanpa harus melakukan polling pada antrean. Dengan Service Bus, Anda dapat mencapainya dengan menggunakan operasi terima polling panjang menggunakan protokol berbasis TCP yang didukung Service Bus.
- Solusi memerlukan antrean untuk menyediakan pengiriman pesanan first-in-first-out (FIFO) yang dijamin.
- Solusi perlu mendukung deteksi duplikat otomatis.
- Anda ingin aplikasi memproses pesan sebagai aliran paralel jangka panjang (pesan dikaitkan dengan aliran menggunakan properti ID sesi pada pesan). Dalam model ini, setiap node dalam aplikasi pengonsumsi bersaing untuk mendapatkan aliran, berbeda dengan pesan. Ketika aliran diberikan ke node pengonsumsi, node dapat memeriksa status aliran aplikasi menggunakan transaksi.
- Solusi memerlukan perilaku transaksional dan atomitas saat mengirim atau menerima beberapa pesan dari suatu antrean.
- Aplikasi Anda menangani pesan yang dapat melebihi 64 KB tetapi kemungkinan tidak akan mendekati batas 256 KB atau 1 MB, tergantung pada tingkat layanan yang dipilih (meskipun Bus Layanan antrean dapat menangani pesan hingga 100 MB).
- Anda menerima persyaratan untuk menyediakan model akses berbasis peran ke antrean, dan hak/izin yang berbeda untuk pengirim dan penerima. Untuk informasi selengkapnya, lihat artikel berikut ini:
- Ukuran antrean Anda tidak akan bertambah lebih dari 80 GB.
- Anda ingin menggunakan protokol olah pesan berbasis standar AMQP 1.0. Untuk informasi selengkapnya tentang AMQP, lihat Ringkasan AMQP Service Bus.
- Anda memvisualisasikan migrasi akhir dari komunikasi point-to-point berbasis antrean ke pola pesan publikasi-langganan. Pola ini memungkinkan integrasi penerima tambahan (pelanggan). Setiap penerima menerima salinan terpisah dari beberapa atau semua pesan yang dikirim ke antrean.
- Solusi olah pesan perlu mendukung jaminan pengiriman "At-Most-Once" dan "At-Least-Once" tanpa mengharuskan Anda untuk membangun komponen infrastruktur tambahan.
- Solusi perlu memublikasikan dan menggunakan batch pesan.
Membandingkan antrean Storage dan antrean Service Bus
Tabel di bagian berikut ini menyediakan pengelompokan fitur antrean yang logis. Ini memungkinkan Anda untuk membandingkan, sekilas, kemampuan yang tersedia dalam antrean Azure Storage dan antrean Service Bus.
Kemampuan dasar
Bagian ini membandingkan beberapa kemampuan antrean mendasar yang disediakan oleh antrean Storage dan antrean Service Bus.
| Kriteria Perbandingan | Antrean Storage | Antrean Microsoft Azure Service Bus |
|---|---|---|
| Jaminan pemesanan | Tanpa Untuk informasi selengkapnya, lihat catatan pertama di bagian Informasi Tambahan. |
Ya - First-in-First-Out (FIFO) (menggunakan sesi pesan) |
| Jaminan pengiriman | At-Least-Once | Setidaknya Sekali (menggunakan mode terima PeekLock. Ini adalah default) Paling Banyak Sekali (menggunakan mode terima ReceiveAndDelete) Pelajari selengkapnya tentang berbagai mode Terima |
| Dukungan operasi atomic | Tidak | Ya |
| Perilaku terima | Non-blocking (segera selesai jika tidak ada pesan baru yang ditemukan) |
Memblokir dengan atau tanpa batas waktu (menawarkan polling jangka panjang, atau "Comet technique") Non-blocking (hanya menggunakan .NET managed API) |
| Push-style API | Tidak | Ya .NET, Java, JavaScript, dan Go SDK kami menyediakan push-style API. |
| Mode Terima | Peek & Lease | Peek & Lock Receive & Delete |
| Mode akses eksklusif | Berbasis lease | Berbasis lock |
| Durasi Lease/Lock | 30 detik (default) 7 hari (maksimum) (Anda dapat memperbarui atau merilis sewa pesan menggunakan API UpdateMessage .) |
30 detik (default) Anda dapat memperbarui lock pesan untuk durasi lock yang sama setiap kali secara manual atau menggunakan fitur pembaruan lock otomatis saat klien mengelola pembaruan lock untuk Anda. |
| Presisi Lease/Lock | Tingkat pesan Setiap pesan dapat memiliki nilai batas waktu yang berbeda yang dapat Anda perbarui sesuai kebutuhan saat memproses pesan menggunakan UpdateMessage API. |
Tingkat antrean (setiap antrean memiliki presisi lock yang diterapkan ke semua pesannya, tetapi lock dapat diperbarui seperti yang dijelaskan di baris sebelumnya) |
| Batch terima | Ya (secara eksplisit menentukan jumlah pesan saat mengambil pesan, hingga maksimum 32 pesan) |
Ya (secara implisit memungkinkan properti prapengambilan atau secara eksplisit menggunakan transaksi) |
| Batch kirim | Tidak | Ya (menggunakan transaksi atau batching sisi klien) |
Informasi tambahan
- Pesan dalam antrean Storage biasanya diatur dengan mode pertama kali masuk pertama kali keluar, tetapi terkadang urutan pesan acak. Misalnya, ketika durasi batas waktu visibilitas pesan kedaluwarsa karena aplikasi klien mengalami crash saat memproses pesan. Ketika batas waktu visibilitas berakhir, pesan terlihat lagi pada antrean sehingga pekerja lain dapat membatalkan antreannya. Pada titik tersebut, pesan yang baru terlihat mungkin ditempatkan dalam antrean untuk dibatalkan lagi antreannya.
- Pola FIFO terjamin dalam antrean Service Bus membutuhkan penggunaan sesi olah pesan. Jika aplikasi mengalami crash saat memproses pesan yang diterima dalam mode Intip & Kunci , lain kali penerima antrean menerima sesi olahpesan, itu akan dimulai dengan pesan yang gagal setelah durasi kunci sesi kedaluwarsa.
- Antrean penyimpanan dirancang untuk mendukung skenario antrean standar, seperti yang berikut:
- Memisahkan komponen aplikasi untuk meningkatkan skalabilitas dan toleransi kegagalan
- Tingkatan beban
- Membangun alur kerja proses.
- Inkonsistensi mengenai penanganan pesan dalam konteks sesi Service Bus dapat dihindari dengan menggunakan status sesi untuk menyimpan status aplikasi terkait kemajuan penanganan urutan pesan sesi, dan menggunakan transaksi seputar penyelesaian pesan yang diterima dan memperbarui status sesi. Fitur konsistensi semacam ini terkadang dilabeli tepat setelah pemrosesan di produk vendor lain. Kegagalan transaksi apa pun jelas akan menyebabkan pesan dikirim ulang dan itulah sebabnya istilah ini sangat tidak memadai.
- Antrean Storage menyediakan model pemrograman yang seragam dan konsisten di seluruh antrean, tabel, dan BLOB - baik untuk developer maupun untuk tim operasi.
- Antrean Service Bus memberikan dukungan untuk transaksi lokal dalam konteks satu antrean.
- Mode Receive and Delete yang didukung oleh Service Bus menyediakan kemampuan untuk mengurangi jumlah operasi olah pesan (dan biaya terkait) sebagai ganti jaminan pengiriman yang diturunkan.
- Antrean Storage memberikan lease dengan kemampuan untuk memperpanjang lease pesan. Fitur ini memungkinkan proses pekerja untuk mempertahankan lease singkat pada pesan. Jadi, jika seorang pekerja mengalami crash, pesan dapat dengan cepat diproses lagi oleh pekerja lain. Selain itu, pekerja dapat memperpanjang lease pada pesan jika perlu memprosesnya lebih lama dari waktu lease saat ini.
- Antrean Storage menawarkan batas waktu visibilitas yang dapat diatur saat mengantre atau membatalkan antrean pesan. Selain itu, Anda dapat memperbarui pesan dengan nilai lease yang berbeda pada run-time, dan memperbarui nilai yang berbeda di seluruh pesan dalam antrean yang sama. Batas waktu lock Service Bus didefinisikan dalam metadata antrean. Namun, Anda dapat memperbarui lock pesan untuk durasi lock yang telah ditentukan secara manual atau menggunakan fitur perpanjangan lock otomatis saat klien mengelola pembaruan lock untuk Anda.
- Batas waktu maksimum untuk operasi terima pemblokiran dalam antrean Service Bus adalah 24 hari. Namun, batas waktu berbasis REST memiliki nilai maksimum 55 detik.
- Batching sisi klien yang disediakan oleh Service Bus memungkinkan klien antrean untuk mengumpulkan beberapa pesan ke dalam satu operasi pengiriman. Batching hanya tersedia untuk operasi kirim asinkron.
- Fitur seperti ceiling 200 TB antrean Storage (lebih banyak ketika Anda memvirtualisasi akun) dan antrean tidak terbatas menjadikannya platform yang ideal untuk penyedia SaaS.
- Antrean Storage menyediakan mekanisme kontrol akses delegasi yang fleksibel dan berperforma.
Kemampuan tingkat lanjut
Bagian ini membandingkan kemampuan canggih yang disediakan oleh antrean Storage dan antrean Service Bus.
| Kriteria Perbandingan | Antrean Storage | Antrean Microsoft Azure Service Bus |
|---|---|---|
| Pengiriman terjadwal | Ya | Ya |
| Dead letter otomatis | Tidak | Ya |
| Meningkatkan nilai time-to-live antrean | Ya (melalui pembaruan batas waktu visibilitas di tempat) |
Ya (disediakan melalui fungsi API khusus) |
| Dukungan pesan poison | Ya | Ya |
| Pembaruan di tempat | Ya | Ya |
| Log transaksi sisi server | Ya | Tidak |
| Metrik Storage | Ya Metrik Menit menyediakan metrik real time untuk ketersediaan, TPS, jumlah panggilan API, jumlah kesalahan, dan lainnya. Seluruhnya terjadi secara real time, dikumpulkan per menit dan dilaporkan dalam beberapa menit dari hal yang baru saja terjadi dalam produksi. Untuk informasi selengkapnya, lihat Analitik Storage. |
Ya Untuk informasi tentang metrik yang didukung oleh Azure Service Bus, lihat Metrik pesan. |
| Manajemen Status | No | Ya (Aktif, Dinonaktifkan, SendDisabled, ReceiveDisabled. Untuk detail mengenai status ini, lihat Status antrean) |
| Penerusan pesan otomatis | Tidak | Ya |
| Fungsi bersihkan antrean | Ya | Tidak |
| Grup pesan | Tidak | Ya (menggunakan sesi pesan) |
| Status aplikasi per grup pesan | Tidak | Ya |
| Deteksi duplikat | Tidak | Ya (dapat dikonfigurasi di sisi pengirim) |
| Menelusuri grup pesan | Tidak | Ya |
| Mengambil sesi pesan dengan ID | Tidak | Ya |
Informasi tambahan
- Kedua teknologi antrean memungkinkan pesan dijadwalkan untuk pengiriman di lain waktu.
- Penerusan antrean otomatis memungkinkan ribuan antrean untuk meneruskan pesan secara otomatis ke satu antrean tempat aplikasi penerima mengonsumsi pesan. Anda dapat menggunakan mekanisme ini untuk mencapai keamanan, alur kontrol, dan mengisolasi penyimpanan antar penerbit pesan.
- Antrean Storage menyediakan dukungan untuk memperbarui konten pesan. Anda dapat menggunakan fungsionalitas ini untuk informasi status persisten dan pembaruan kemajuan bertahap ke dalam pesan sehingga pesan dapat diproses dari titik pemeriksaan terakhir yang diketahui alih-alih dimulai dari awal. Dengan antrean Service Bus, Anda dapat mengaktifkan skenario yang sama menggunakan sesi pesan. Untuk informasi selengkapnya, lihat Status sesi pesan.
- Antrean Service Bus mendukung dead letter. Ini dapat berguna untuk mengisolasi pesan yang memenuhi kriteria berikut:
- Pesan tidak dapat diproses dengan sukses oleh aplikasi penerima
- Pesan tidak dapat mencapai tujuan karena properti time-to-live (TTL) kedaluwarsa. Nilai TTL menentukan durasi pesan tetap berada dalam antrean. Dengan Service Bus, pesan akan dipindahkan ke antrean khusus yang disebut $DeadLetterQueue saat periode TTL berakhir.
- Untuk menemukan pesan "poison" dalam antrean Storage, saat membatalkan antrean pesan, aplikasi tersebut memeriksa properti DequeueCount pesan. Jika DequeueCount lebih besar dari ambang batas tertentu, aplikasi tersebut memindahkan pesan ke antrean "dead letter" yang ditentukan aplikasi.
- Antrean Storage memungkinkan Anda untuk mendapatkan log terperinci dari semua transaksi yang dieksekusi terhadap antrean, dan metrik agregat. Kedua opsi ini berguna untuk debugging dan memahami cara aplikasi menggunakan antrean Storage. Ini juga berguna untuk menyelaraskan performa aplikasi dan mengurangi biaya penggunaan antrean.
- Sesi pesan yang didukung oleh Service Bus memungkinkan pesan yang termasuk dalam grup logika untuk dikaitkan dengan penerima. Ini menciptakan afinitas seperti sesi antara pesan dan penerima masing-masing. Anda dapat mengaktifkan fungsionalitas tingkat lanjut ini di Service Bus dengan mengatur properti ID sesi pada pesan. Penerima kemudian dapat mendengarkan ID sesi tertentu dan menerima pesan yang membagikan pengidentifikasi sesi yang ditentukan.
- Fitur deteksi duplikasi antrean Service Bus secara otomatis menghapus pesan duplikat yang dikirim ke antrean atau topik berdasarkan nilai properti ID pesan.
Kapasitas dan kuota
Bagian ini membandingkan antrean Penyimpanan dan antrean Bus Layanan dari perspektif kapasitas dan kuota yang mungkin berlaku.
| Kriteria Perbandingan | Antrean Storage | Antrean Microsoft Azure Service Bus |
|---|---|---|
| Ukuran antrean maksimum | 500 TB (terbatas pada satu kapasitas akun penyimpanan) |
1 GB hingga 80 TB (didefinisikan saat membuat antrean dan mengaktifkan partisi – lihat bagian "Informasi Tambahan") |
| Ukuran maksimum pesan | 64 KB (48 KB saat menggunakan pengodean Base 64) Azure mendukung pesan besar dengan menggabungkan antrean dan blob - di titik saat Anda dapat menambahkan hingga 200 GB untuk satu item ke antrean. |
256 KB atau 100 MB (termasuk header dan isi, ukuran header maksimum: 64 KB). Tergantung tingkat layanan. |
| TTL maksimum pesan | Tidak Terhingga (versi api 2017-07-27 ke atas) | TimeSpan.MaxValue |
| Jumlah antrean maksimum | Tidak Terbatas | 10,000 (per namespace layanan) |
| Jumlah maksimum klien bersamaan | Tidak Terbatas | 5\.000 |
Informasi tambahan
- Service Bus memberlakukan batas ukuran antrean. Ukuran antrean maksimum ditentukan saat membuat antrean. Ukuran berkisar antara 1 GB dan 80 GB. Jika ukuran antrean mencapai batas ini, pesan masuk tambahan akan ditolak dan pemanggil menerima pengecualian. Untuk informasi selengkapnya tentang kuota, lihat kuota Service Bus.
- Di tingkat olah pesan Standar, Anda dapat membuat antrean dan topik Service Bus dalam ukuran 1 (default), 2, 3, 4, atau 5 GB. Saat mengaktifkan partisi di tingkat Standar, Bus Layanan membuat 16 salinan (16 partisi) entitas, masing-masing dari ukuran yang sama yang ditentukan. Dengan demikian, jika Anda membuat antrean yang berukuran 5 GB, dengan 16 partisi, ukuran antrean maksimumnya adalah (5 * 16) = 80 GB. Anda dapat melihat ukuran maksimum antrean atau topik yang dipartisi di portal Microsoft Azure.
- Dengan antrean Storage, jika konten pesan tidak aman XML, pesan harus berenkode Base64. Jika Anda menerapkan enkode Base64 pada pesan, payload pengguna dapat berukuran hingga 48 KB, bukan 64 KB.
- Dengan antrean Service Bus, setiap pesan yang disimpan dalam antrean terdiri dari dua bagian: header dan isi. Ukuran total pesan tidak boleh melebihi ukuran pesan maksimum yang didukung oleh tingkat layanan.
- Ketika klien berkomunikasi dengan antrean Service Bus melalui protokol TCP, jumlah maksimum koneksi bersamaan ke satu antrean Service Bus terbatas pada 100. Angka ini dibagi antara pengirim dan penerima. Jika kuota ini tercapai, permintaan koneksi tambahan akan ditolak dan pengecualian akan diterima dengan kode panggil. Batas ini tidak dikenakan ke klien yang terhubung ke antrean menggunakan API berbasis REST.
- Jika memerlukan lebih dari 10.000 antrean dalam satu namespace Service Bus, Anda dapat menghubungi tim dukungan Azure dan meminta peningkatan. Untuk menskalakan lebih dari 10.000 antrean dengan Service Bus, Anda juga dapat membuat namespace tambahan menggunakan portal Microsoft Azure.
Manajemen dan operasi
Bagian ini membandingkan fitur manajemen yang disediakan oleh antrean Storage dan antrean Service Bus.
| Kriteria Perbandingan | Antrean Storage | Antrean Microsoft Azure Service Bus |
|---|---|---|
| Protokol manajemen | REST melalui HTTP/HTTPS | REST melalui HTTPS |
| Protokol runtime | REST melalui HTTP/HTTPS | REST melalui HTTPS AMQP 1.0 Standard (TCP dengan TLS) |
| .NET API | Ya (.NET Storage Client API) |
Ya (.NET Service Bus API) |
| Native C++ | Ya | Ya |
| Java API | Ya | Ya |
| PHP API | Ya | Ya |
| Node.js API | Ya | Ya |
| Dukungan metadata sesuai pilihan | Ya | Tidak |
| Aturan penamaan antrean | Panjang nama hingga 63 karakter (Huruf dalam nama antrean harus huruf kecil.) |
Panjang hingga 260 karakter (Jalur dan nama antrean tidak peka huruf besar/kecil.) |
| Fungsi dapatkan panjang antrean | Ya (Perkiraan nilai jika pesan kedaluwarsa di luar TTL tanpa dihapus.) |
Ya (Tepat, nilai point-in-time.) |
| Fungsi Peek | Ya | Ya |
Informasi tambahan
- Antrean Storage memberikan dukungan untuk atribut sesuai pilihan yang dapat diterapkan pada deskripsi antrean, dalam bentuk pasangan nama/nilai.
- Kedua teknologi antrean menawarkan kemampuan untuk melakukan peek pada pesan tanpa harus menguncinya, dah ini dapat berguna saat menerapkan alat penjelajah/browser antrean.
- API olah pesan broker Service Bus .NET menggunakan koneksi TCP dupleks penuh untuk peningkatan performa jika dibandingkan dengan REST melalui HTTP, dan API ini mendukung protokol standar AMQP 1.0.
- Nama antrean Storage dapat terdiri dari 3-63 karakter, dapat berisi huruf kecil, angka, dan tanda hubung. Untuk informasi selengkapnya, lihat Penamaan Antrean dan Metadata.
- Nama antrean Service Bus dapat mencapai 260 karakter dan memiliki aturan penamaan yang tidak terlalu ketat. Nama antrean Service Bus dapat berisi huruf, angka, titik, tanda hubung, dan garis bawah.
Autentikasi dan otorisasi
Bagian ini membahas fitur autentikasi dan otorisasi yang didukung oleh antrean Storage dan antrean Service Bus.
| Kriteria Perbandingan | Antrean Storage | Antrean Microsoft Azure Service Bus |
|---|---|---|
| Autentikasi | Kunci simetris dan Kontrol akses berbasis peran (RBAC) | Kunci simetris dan Kontrol akses berbasis peran (RBAC) |
| Kumpulan penyedia identitas | Ya | Ya |
Informasi tambahan
- Setiap permintaan untuk salah satu teknologi antrean harus diautentikasi. Antrean publik dengan akses anonim tidak didukung.
- Dengan menggunakan autentikasi tanda tangan akses bersama (SAS), Anda dapat membuat aturan otorisasi akses bersama pada antrean yang dapat memberi pengguna akses tulis saja, baca-saja, atau penuh. Untuk informasi selengkapnya, lihat autentikasi Azure Storage - SAS dan autentikasi Azure Service Bus - SAS.
- Kedua antrean mendukung otorisasi akses menggunakan ID Microsoft Entra. Mengotorisasi pengguna atau aplikasi menggunakan token OAuth 2.0 yang dikembalikan oleh MICROSOFT Entra ID memberikan keamanan yang unggul dan kemudahan penggunaan melalui tanda tangan akses bersama (SAS). Dengan ID Microsoft Entra, Anda tidak perlu menyimpan token dalam kode Anda dan berisiko potensi kerentanan keamanan. Untuk informasi selengkapnya, lihat Azure Storage - Autentikasi Microsoft Entra dan Azure Bus Layanan - Autentikasi Microsoft Entra.
Kesimpulan
Dengan mendapatkan pemahaman yang lebih dalam tentang dua teknologi tersebut, Anda dapat membuat keputusan yang lebih matang tentang teknologi antrean yang akan digunakan, dan waktunya. Keputusan tentang waktu untuk menggunakan antrean Storage atau antrean Service Bus jelas tergantung banyak faktor. Faktor-faktor ini sangat bergantung pada kebutuhan individu aplikasi Anda dan arsitekturnya.
Anda mungkin lebih suka memilih Antrean penyimpanan karena alasan seperti yang berikut ini:
- Jika aplikasi Anda sudah menggunakan kapabilitas inti Microsoft Azure
- Jika Anda memerlukan komunikasi dan olah pesan dasar antar layanan
- Memerlukan antrean dengan ukuran yang bisa lebih besar dari 80 GB
Antrean Service Bus menyediakan banyak fitur canggih seperti berikut ini. Jadi, aplikasi tersebut mungkin merupakan pilihan yang lebih disukai jika Anda membangun aplikasi hibrid atau jika aplikasi Anda memerlukan fitur-fitur ini.
- Sesi
- Transaksi
- Deteksi duplikat
- Dead letter otomatis
- Kemampuan publikasi dan langganan yang tahan lama
Langkah berikutnya
Artikel berikut ini merupakan panduan dan informasi selengkapnya tentang menggunakan antrean Storage atau antrean Service Bus.