Gambaran umum pemrosesan transaksi Service Bus
Artikel ini membahas kemampuan transaksi Microsoft Azure Service Bus. Sebagian besar diskusi diilustrasikan oleh sampel Transaksi. Artikel ini terbatas pada ikhtisar pemrosesan transaksi dan fitur kirim melalui di Service Bus, sementara sampel Atomic Transactions memiliki lingkup yang lebih luas dan lebih kompleks.
Catatan
- Tingkat dasar Service Bus tidak mendukung transaksi. Tingkatan standar dan premium mendukung transaksi. Untuk perbedaan antara tingkatan ini, lihat Harga Service Bus.
- Pencampuran manajemen dan operasi olahpesan dalam transaksi tidak didukung.
- JavaScript SDK tidak mendukung transaksi.
Transaksi dalam Service Bus
Transaksi menyatukan dua operasi atau lebih ke dalam cakupan eksekusi. Secara alami, transaksi semacam itu harus memastikan bahwa semua operasi milik kelompok operasi tertentu berhasil atau gagal bersama. Dalam hal ini transaksi bertindak sebagai satu unit, yang sering disebut sebagai atomitas.
Service Bus adalah broker pesan transaksional dan memastikan integritas transaksional untuk semua operasi internal terhadap penyimpanan pesannya. Semua transfer pesan di dalam Azure Service Bus, seperti memindahkan pesan ke antrean dead-letter atau penerusan otomatis pesan antar entitas, adalah transaksional. Dengan demikian, jika Service Bus menerima pesan, bus tersebut telah disimpan dan diberi label dengan nomor urut. Sejak saat itu, setiap transfer pesan dalam Service Bus adalah operasi terkoordinasi di seluruh entitas, dan tidak akan menyebabkan kehilangan (sumber berhasil dan target gagal) atau duplikasi (sumber gagal dan target berhasil) pesan.
Service Bus mendukung operasi pengelompokan terhadap satu entitas pesan (antrean, topik, langganan) dalam lingkup transaksi. Misalnya, Anda dapat mengirim beberapa pesan ke satu antrean dari dalam lingkup transaksi, dan pesan hanya akan berkomitmen pada log antrean ketika transaksi berhasil diselesaikan.
Operasi dalam lingkup transaksi
Operasi yang dapat dilakukan dalam lingkup transaksi adalah sebagai berikut:
- Kirim
- Selesai
- Tinggalkan
- DeadLetter
- Menunda
- Memperbarui kunci
Operasi terima tidak disertakan, karena diasumsikan bahwa aplikasi memperoleh pesan menggunakan mode ReceiveMode.PeekLock, di dalam beberapa loop terima atau dengan callback OnMessage, dan baru kemudian membuka cakupan transaksi untuk memproses pesan.
Disposisi pesan (lengkap, tinggalkan, dead-letter, tunda) kemudian terjadi dalam lingkup, dan tergantung pada, hasil keseluruhan transaksi.
Penting
Azure Service Bus tidak mencoba kembali operasi jika ada pengecualian saat operasi berada dalam cakupan transaksi.
Operasi yang tidak mendaftar dalam cakupan transaksi
Ketahuilah bahwa kode pemrosesan pesan yang memanggil ke database dan layanan lain seperti Cosmos DB tidak secara otomatis mendaftarkan sumber daya hilir tersebut ke dalam cakupan transaksional yang sama. Untuk informasi selengkapnya tentang cara menangani skenario ini, lihat panduan tentang pemrosesan pesan idempogen.
Transfer dan "kirim melalui"
Untuk memungkinkan penyerahan data transaksional dari antrean atau topik ke prosesor, lalu ke antrian atau topik lain, Service Bus mendukung transfer. Dalam operasi transfer, pengirim terlebih dahulu mengirim pesan ke antrean atau topik transfer, dan antrean atau topik transfer segera memindahkan pesan ke antrean atau topik tujuan yang dimaksudkan menggunakan implementasi transfer kuat yang sama dengan yang diandalkan oleh kemampuan autoforward. Pesan tidak pernah berkomitmen pada antrean transfer atau log topik singgah sehingga menjadi terlihat untuk antrean transfer atau konsumen topik.
Kekuatan kemampuan transaksional ini menjadi jelas ketika antrean transfer atau topik itu sendiri adalah sumber pesan input pengirim. Dengan kata lain, Service Bus dapat mentransfer pesan ke antrean tujuan atau topik "melalui" antrean atau topik transfer, sambil melakukan operasi lengkap (atau menunda, atau dead-letter) pada pesan input, semuanya dalam satu operasi atom.
Jika Anda perlu menerima dari langganan topik, lalu mengirim ke antrean atau topik dalam transaksi yang sama, entitas transfer harus menjadi topik. Dalam skenario ini, mulai lingkup transaksi tentang topik, terima dari langganan dengan dalam lingkup transaksi, dan kirim melalui topik transfer ke antrean atau tujuan topik.
Catatan
Jika pesan dikirim melalui antrean transfer dalam cakupan transaksi, TransactionPartitionKey secara fungsional setara dengan PartitionKey. Ini memastikan bahwa pesan disimpan bersama-sama dan agar dapat ditransfer.
Melihatnya dalam kode
Untuk menyiapkan transfer tersebut, Anda membuat pengirim pesan yang menargetkan antrean tujuan melalui antrean transfer. Anda juga memiliki penerima yang menarik pesan dari antrean yang sama. Contohnya:
Transaksi sederhana kemudian menggunakan elemen-elemen ini, seperti dalam contoh berikut. Untuk merujuk contoh lengkap, lihat kode sumber di GitHub:
var options = new ServiceBusClientOptions { EnableCrossEntityTransactions = true };
await using var client = new ServiceBusClient(connectionString, options);
ServiceBusReceiver receiverA = client.CreateReceiver("queueA");
ServiceBusSender senderB = client.CreateSender("queueB");
ServiceBusReceivedMessage receivedMessage = await receiverA.ReceiveMessageAsync();
using (var ts = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
await receiverA.CompleteMessageAsync(receivedMessage);
await senderB.SendMessageAsync(new ServiceBusMessage());
ts.Complete();
}
Untuk mempelajari selengkapnya tentang properti EnableCrossEntityTransactions, lihat referensi berikut ServiceBusClientBuilder.enableCrossEntityTransactions Method.
Waktu habis
Transaksi habis setelah 2 menit. Timer transaksi dimulai ketika operasi pertama dalam transaksi dimulai.
Langkah berikutnya
Lihat artikel berikut ini untuk informasi selengkapnya tentang antrean Azure Service Bus: