Praktik Terbaik untuk Komunikasi dalam Antrean

Artikel
03/30/2023

Topik ini menyediakan praktik yang direkomendasikan untuk komunikasi dalam antrean di Windows Communication Foundation (WCF). Bagian berikut membahas praktik yang direkomendasikan dari perspektif skenario.

Upaya Cepat dan Terbaik untuk Pesan dalam Antrean

Untuk skenario yang memerlukan pemisahan yang disediakan pesan dalam antrean dan pesan berperforma tinggi yang cepat dengan jaminan upaya terbaik, gunakan antrean non-transaksional dan atur properti ExactlyOnce ke false.

Selain itu, Anda dapat memilih untuk tidak dikenakan biaya penulisan disk dengan mengatur properti Durable ke false.

Keamanan memiliki implikasi pada performa. Untuk informasi selengkapnya, lihat Pertimbangan Performa.

Pesan dalam Antrean yang Andal dan Menyeluruh

Bagian berikut menjelaskan praktik yang direkomendasikan untuk skenario yang memerlukan pesan yang andal dan menyeluruh.

Transfer Andal Dasar

Untuk keandalan menyeluruh, atur properti ExactlyOnce ke true untuk memastikan transfer. Properti Durable dapat diatur ke true atau false bergantung pada kebutuhan Anda (defaultnya adalah true). Umumnya, properti Durable diatur ke true sebagai bagian dari keandalan menyeluruh. Kekurangannya adalah biaya performa, tetapi akan membuat pesan tahan lama sehingga pesan tidak hilang jika pengelola antrean crash.

Penggunaan Transaksi

Anda harus menggunakan transaksi untuk memastikan keandalan menyeluruh. Jaminan ExactlyOnce hanya memastikan bahwa pesan dikirimkan ke antrean target. Untuk memastikan bahwa pesan diterima, gunakan transaksi. Tanpa transaksi, jika layanan crash, Anda akan kehilangan pesan yang sedang dirikim tetapi sebenarnya dikirimkan ke aplikasi.

Penggunaan Antrean yang Dihentikan Pengirimannya

Antrean yang dihentikan pengirimannya memastikan bahwa Anda diberi tahu jika pesan gagal dikirim ke antrean target. Anda dapat menggunakan antrean yang dihentikan pengirimannya yang disediakan sistem atau antrean kustom yang dihentikan pengirimannya. Secara umum, menggunakan antrean kustom yang dihentikan pengirimannya adalah yang terbaik karena memungkinkan Anda mengirim pesan yang dihentikan pengirimannya dari satu aplikasi ke dalam antrean tunggal yang dihentikan pengirimannya. Jika tidak, semua pesan yang dihentikan pengirimannya yang terjadi untuk semua aplikasi yang berjalan pada sistem dikirim ke satu antrean. Setiap aplikasi kemudian harus mencari melalui antrean yang dihentikan pengirimannya untuk menemukan pesan yang dihentikan pengirimannya yang relevan dengan aplikasi itu. Terkadang, menggunakan antrean kustom yang dihentikan pengirimannya tidak layak, seperti saat menggunakan MSMQ 3.0.

Menonaktifkan antrean yang dihentikan pengirimannya untuk komunikasi andal menyeluruh tidak disarankan.

Untuk informasi selengkapnya, lihat Menggunakan Antrean yang Dihentikan Pengirimannya untuk Menangani Kegagalan Transfer Pesan.

Penggunaan Penanganan Pesan Racun

Penanganan pesan racun memberikan kemampuan untuk pulih dari kegagalan untuk memproses pesan.

Saat menggunakan fitur penanganan pesan racun, pastikan bahwa properti ReceiveErrorHandling diatur ke nilai yang sesuai. Mengaturnya ke Drop berarti data akan hilang. Di sisi lain, mengaturnya ke Fault akan menimbulkan kesalahan pada host layanan ketika mendeteksi pesan racun. Menggunakan MSMQ 3.0, Fault adalah opsi terbaik untuk menghindari kehilangan data dan mencegah adanya pesan racun. Menggunakan MSMQ 4.0, Move adalah pendekatan yang direkomendasikan. Move memindahkan pesan racun dari antrean sehingga layanan dapat terus memproses pesan baru. Layanan pesan racun kemudian dapat memproses pesan racun secara terpisah.

Untuk informasi selengkapnya, lihat Penanganan Pesan Racun.

Mencapai Throughput Tinggi

Untuk mencapai throughput tinggi pada satu titik akhir, gunakan hal berikut:

Pembuatan batch yang ditransaksikan. Pembuatan batch yang ditransaksikan memastikan bahwa banyak pesan dapat dibaca dalam satu transaksi. Hal ini mengoptimalkan penerapan transaksi, meningkatkan performa secara keseluruhan. Biaya pembuatan batch adalah bahwa jika kegagalan terjadi dalam satu pesan dalam satu batch, maka seluruh batch digulung balik dan pesan harus diproses satu per satu sampai aman untuk pembuatan batch lagi. Dalam banyak kasus, pesan racun jarang terjadi, jadi pembuatan batch adalah cara yang lebih dipilih untuk meningkatkan performa sistem, terutama saat Anda memiliki pengelola sumber daya lain yang berpartisipasi dalam transaksi. Untuk informasi selengkapnya tentang pembuatan batch, lihat Pembuatan Batch Pesan dalam Transaksi.
Konkurensi. Konkurensi meningkatkan throughput, tetapi konkurensi juga memengaruhi pertentangan terhadap sumber daya bersama. Untuk informasi selengkapnya, lihat Konkurensi.
Pembatasan. Untuk performa optimal, batasi jumlah pesan dalam alur dispatcher. Untuk contoh cara melakukannya, lihat Pembatasan.

Saat menggunakan pembuatan batch, ketahuilah bahwa konkurensi dan pembatasan akan menghasilkan batch bersamaan.

Untuk mencapai throughput dan ketersediaan yang lebih tinggi, gunakan farm layanan WCF yang membaca dari antrean. Hal ini mengharuskan semua layanan tersebut mengekspos kontrak yang sama pada titik akhir yang sama. Pendekatan farm berfungsi paling baik untuk aplikasi yang memiliki tingkat produksi pesan yang tinggi karena memungkinkan sejumlah layanan untuk semua pembacaan dari antrean yang sama.

Saat menggunakan farm, ketahuilah bahwa MSMQ 3.0 tidak mendukung pembacaan yang ditransaksikan dari jarak jauh. MSMQ 4.0 mendukung pembacaan yang ditransaksikan dari jarak jauh.

Untuk informasi selengkapnya tentang pembuatan batch, lihat Pembuatan Batch Pesan dalam Transaksi.

Mengantre dengan Unit Semantik Kerja

Dalam beberapa skenario, sekelompok pesan dalam antrean mungkin terkait dan, oleh karena itu, pengurutan pesan ini menjadi signifikan. Dalam skenario seperti itu, proses sekelompok pesan terkait bersama-sama sebagai satu unit: baik semua pesan diproses dengan sukses atau tidak sama sekali. Untuk menerapkan perilaku tersebut, gunakan sesi dengan antrean.

Untuk informasi selengkapnya, lihat Mengelompokkan Pesan dalam Antrean di Sesi.

Menghubungkan Pesan Permintaan-Balasan

Meskipun antrean biasanya satu arah, dalam beberapa skenario Anda mungkin ingin mengorelasikan balasan yang diterima dengan permintaan yang dikirim sebelumnya. Jika memerlukan korelasi seperti itu, sebaiknya Anda menerapkan header pesan SOAP milik sendiri yang berisi informasi korelasi dengan pesan. Biasanya, pengirim melampirkan header ini dengan pesan, dan penerima, setelah memproses pesan dan membalas kembali dengan pesan baru pada antrean balasan, melampirkan header pesan pengirim yang berisi informasi korelasi sehingga pengirim dapat mengidentifikasi pesan balasan dengan pesan permintaan.

Integrasi dengan Aplikasi Non-WCF

Gunakan MsmqIntegrationBinding saat mengintegrasikan layanan atau klien WCF dengan layanan atau klien non-WCF. Aplikasi non-WCF dapat menjadi aplikasi MSMQ yang ditulis menggunakan System.Messaging, COM +, Visual Basic, atau C++.

Saat menggunakan MsmqIntegrationBinding, perhatikan hal berikut:

Isi pesan WCF tidak sama dengan isi pesan MSMQ. Saat mengirim pesan WCF menggunakan pengikatan dalam antrean, isi pesan WCF ditempatkan di dalam pesan MSMQ. Infrastruktur MSMQ tidak menyadari informasi tambahan ini; dan hanya melihat pesan MSMQ.
MsmqIntegrationBinding mendukung jenis serialisasi populer. Berdasarkan jenis serialisasi, jenis isi pesan generik, MsmqMessage<T>, akan menggunakan parameter jenis yang berbeda. Misalnya, ByteArray memerlukan MsmqMessage\<byte[]> dan Stream memerlukan MsmqMessage<Stream>.
Dengan serialisasi XML, Anda dapat menentukan jenis yang diketahui menggunakan atribut KnownTypes pada elemen <perilaku> yang kemudian digunakan untuk menentukan cara melakukan deserialisasi pesan XML.

Share via