Artikel ini menjelaskan berbagai jenis pesan dan entitas yang berpartisipasi dalam infrastruktur olahpesan. Berdasarkan persyaratan setiap jenis pesan, artikel merekomendasikan layanan olahpesan Azure. Opsinya mencakup Azure Service Bus, Event Grid, dan Event Hubs.
Pada tingkat arsitektur, pesan adalah datagram yang dibuat oleh entitas (produsen), untuk mendistribusikan informasi sehingga entitas lain (konsumen) dapat mengetahui dan bertindak sesuai dengan itu. Produsen dan konsumen dapat berkomunikasi secara langsung atau opsional melalui entitas perantara (perantara pesan). Artikel ini berfokus pada pesan asinkron menggunakan perantara pesan.
Pesan dapat diklasifikasikan menjadi dua kategori utama. Jika produsen mengharapkan tindakan dari konsumen, pesan itu adalah perintah. Jika pesan tersebut memberi tahu konsumen bahwa suatu tindakan telah terjadi, maka pesan tersebut adalah peristiwa.
Perintah
Produsen mengirimkan perintah dengan niat bahwa konsumen akan melakukan operasi dalam cakupan transaksi bisnis.
Perintah adalah pesan bernilai tinggi dan harus disampaikan setidaknya sekali. Jika perintah hilang, seluruh transaksi bisnis mungkin gagal. Selain itu, perintah tidak boleh diproses lebih dari sekali. Melakukan hal tersebut dapat menyebabkan transaksi yang salah. Pelanggan mungkin mendapatkan pesanan duplikat atau ditagih dua kali.
Perintah sering digunakan untuk mengelola alur kerja transaksi bisnis multilangkah. Tergantung logika bisnis, produsen mungkin mengharapkan konsumen untuk mengakui pesan dan melaporkan hasil operasi. Berdasarkan hasil tersebut, produsen dapat memilih tindakan yang tepat.
Acara
Peristiwa adalah jenis pesan yang diangkat oleh produsen untuk mengumumkan fakta.
Produsen (dikenal sebagai penerbit dalam konteks ini) tidak berharap bahwa peristiwa tersebut akan menghasilkan tindakan apa pun.
Konsumen yang tertarik dapat berlangganan, mendengarkan peristiwa, dan mengambil tindakan tergantung skenario konsumsi mereka. Peristiwa dapat memiliki banyak pelanggan atau tidak memiliki pelanggan sama sekali. Dua pelanggan yang berbeda dapat bereaksi terhadap suatu peristiwa dengan tindakan yang berbeda dan tidak menyadari satu sama lain.
Produsen dan konsumen secara longgar digabungkan dan dikelola secara independen. Konsumen tidak diharapkan untuk mengakui peristiwa tersebut kembali ke produsen. Konsumen yang tidak lagi tertarik dengan peristiwa tersebut, dapat berhenti berlangganan. Konsumen dihapus dari alur tanpa memengaruhi produsen atau fungsionalitas sistem secara keseluruhan.
Ada dua kategori peristiwa:
Produsen memunculkan peristiwa untuk mengumumkan fakta terpisah. Kasus penggunaan umum adalah notifikasi kejadian. Misalnya, Azure Resource Manager memunculkan peristiwa saat membuat, mengubah, atau menghapus sumber daya. Pelanggan dari peristiwa tersebut bisa menjadi Logic App yang mengirimkan email peringatan.
Produsen memunculkan peristiwa terkait dalam urutan, atau aliran peristiwa, selama periode waktu tertentu. Biasanya, aliran digunakan untuk evaluasi statistik. Evaluasi dapat dilakukan dalam jendela temporal atau saat peristiwa tiba. Telemetri adalah kasus penggunaan umum, misalnya, pemantauan kesehatan dan beban suatu sistem. Kasus lainnya adalah streaming peristiwa dari perangkat IoT.
Pola umum untuk menerapkan pesan peristiwa adalah pola Penerbit-Pelanggan.
Perantara dan manfaat perantara pesan
Perantara pesan perantara menyediakan fungsionalitas untuk memindahkan pesan dari produsen ke konsumen dan dapat menawarkan manfaat tambahan.
Pemisahan
Perantara pesan memisahkan produsen dari konsumen dalam logika yang menghasilkan dan menggunakan pesan, masing-masing. Dalam alur kerja yang kompleks, perantara dapat mendorong operasi bisnis untuk dipisahkan dan membantu mengoordinasikan alur kerja.
Misalnya, satu transaksi bisnis memerlukan operasi berbeda yang dilakukan dalam urutan logika bisnis. Produsen mengeluarkan perintah yang memberi sinyal kepada konsumen untuk memulai operasi. Konsumen mengakui pesan dalam antrean terpisah yang disediakan untuk mengantre tanggapan untuk produsen. Hanya setelah menerima respons, produser mengirim pesan baru untuk memulai operasi berikutnya dalam urutan. Konsumen yang berbeda memproses pesan itu dan mengirimkan pesan penyelesaian ke antrean respons. Menggunakan olahpesan, layanan mengoordinasikan alur kerja transaksi di antara mereka sendiri.
Perantara pesan menyediakan pemisahan sementara. Produsen dan konsumen tidak harus berjalan secara bersamaan. Produsen dapat mengirim pesan ke perantara pesan terlepas dari ketersediaan konsumen. Sebaliknya, konsumen tidak dibatasi oleh ketersediaan produsen.
Misalnya, antarmuka pengguna aplikasi web menghasilkan pesan dan menggunakan antrean sebagai perantara pesan. Saat siap, konsumen dapat mengambil pesan dari antrean dan melakukan pekerjaan. Pemisahan sementara membantu antarmuka pengguna untuk tetap responsif. Ini tidak diblokir saat pesan ditangani secara asinkron.
Operasi tertentu bisa memakan waktu lama untuk diselesaikan. Setelah mengeluarkan perintah, produsen tidak perlu menunggu sampai konsumen menyelesaikannya. Perantara pesan membantu pemrosesan pesan asinkron.
Penyeimbangan beban
Produsen dapat memposting sejumlah besar pesan yang dilayani oleh banyak konsumen. Gunakan perantara pesan untuk mendistribusikan pemrosesan di seluruh server dan meningkatkan throughput. Konsumen dapat berjalan di server yang berbeda untuk menyebarkan beban. Konsumen dapat ditambahkan secara dinamis untuk meluaskan skala sistem saat dibutuhkan atau dihapus jika tidak.
Pola Konsumen yang Bersaing menjelaskan cara memproses beberapa pesan secara bersamaan untuk mengoptimalkan throughput, meningkatkan skalabilitas dan ketersediaan, serta menyeimbangkan beban kerja.
Tingkatan beban
Volume pesan yang dihasilkan oleh produsen atau sekelompok produsen dapat bervariasi. Terkadang mungkin ada volume besar yang menyebabkan lonjakan pesan. Daripada menambahkan konsumen untuk menangani pekerjaan ini, perantara pesan dapat bertindak sebagai buffer, dan konsumen secara bertahap mengalirkan pesan dengan kecepatan mereka sendiri tanpa membebani sistem.
Pola Perataan Beban Berbasis Antrean memberikan informasi lebih lanjut.
Olahpesan yang andal
Perantara pesan membantu memastikan bahwa pesan tidak hilang bahkan jika komunikasi gagal antara produsen dan konsumen. Produsen dapat mengirimkan pesan ke perantara pesan dan konsumen dapat mengambilnya kembali saat komunikasi terjalin kembali. Produsen tidak diblokir kecuali kehilangan konektivitas dengan perantara pesan.
Pesan tangguh
Perantara pesan dapat menambahkan ketahanan kepada konsumen di sistem Anda. Jika konsumen gagal saat memproses pesan, contoh lain dari konsumen dapat memproses pesan itu. Pemrosesan ulang dapat dilakukan karena pesan tetap ada di perantara.
Pilihan teknologi untuk perantara pesan
Azure menyediakan beberapa layanan perantara pesan, masing-masing dengan berbagai fitur. Sebelum memilih layanan, tentukan niat dan persyaratan pesan.
Azure Service Bus
Antrean Azure Service Bus sangat cocok untuk mentransfer perintah dari produsen ke konsumen. Berikut adalah beberapa pertimbangan.
Model penarikan
Seorang konsumen antrean Azure Service Bus terus-menerus melakukan polling Azure Service Bus untuk memeriksa apakah pesan baru tersedia. SDK klien dan Pemicu Azure Functions untuk Azure Service Bus mengabstraksi model tersebut. Ketika pesan baru tersedia, panggilan balik konsumen dipanggil, dan pesan dikirim ke konsumen.
Pengiriman terjamin
Azure Service Bus memungkinkan konsumen untuk mengintip antrean dan mengunci pesan dari konsumen lain.
Merupakan tanggung jawab konsumen untuk melaporkan status pemrosesan pesan. Hanya ketika konsumen menandai pesan sebagai digunakan, Azure Service Bus menghapus pesan dari antrean. Jika terjadi kegagalan, waktu habis, atau crash, Azure Service Bus membuka pesan sehingga konsumen lain dapat mengambilnya. Dengan cara ini pesan tidak hilang dalam transfer.
Seorang produsen mungkin secara tidak sengaja mengirim pesan yang sama dua kali. Misalnya, instans produsen gagal setelah mengirim pesan. Produsen lain mengganti instans asli dan mengirim pesan lagi. Antrean Azure Service Bus menyediakan kemampuan de-duping bawaan yang mendeteksi dan menghapus pesan duplikat. Masih ada kemungkinan pesan terkirim dua kali. Misalnya, jika konsumen gagal saat memproses, pesan dikembalikan ke antrean dan diambil oleh konsumen yang sama atau konsumen yang lain. Logika pemrosesan pesan di konsumen harus idempoten sehingga bahkan jika pekerjaan diulang, status sistem tidak berubah.
Pemesanan pesan
Jika Anda ingin konsumen mendapatkan pesan sesuai urutan pengirimannya, antrean Azure Service Bus menjamin pengiriman pesanan first-in-first-out (FIFO) dengan menggunakan sesi. Sesi dapat memiliki satu atau beberapa pesan. Pesan tersebut berkorelasi dengan properti SessionId. Pesan yang merupakan bagian dari sesi, tidak pernah kedaluwarsa. Sesi dapat dikunci ke konsumen untuk mencegah pesannya ditangani oleh konsumen yang berbeda.
Untuk informasi selengkapnya, lihat Sesi Pesan.
Persistensi pesan
Antrean Service bus mendukung pemisahan temporal. Bahkan saat konsumen tidak tersedia atau tidak dapat memproses pesan, pesan tetap berada dalam antrean.
Titik pemeriksaan transaksi jangka panjang
Transaksi bisnis dapat berjalan dalam waktu yang lama. Setiap operasi dalam transaksi dapat memiliki beberapa pesan. Gunakan titik pemeriksaan untuk mengoordinasikan alur kerja dan memberikan ketahanan jika transaksi gagal.
Antrean Azure Service Bus memungkinkan pemeriksaan melalui kemampuan status sesi. Informasi status direkam secara bertahap dalam antrean (SetState) untuk pesan yang termasuk dalam suatu sesi. Misalnya, konsumen dapat melacak kemajuan dengan memeriksa status (GetState) sesekali. Jika konsumen gagal, konsumen lain dapat menggunakan informasi status untuk menentukan titik pemeriksaan terakhir yang diketahui untuk melanjutkan sesi.
Antrean surat gagal (DLQ)
Antrean Azure Service Bus memiliki subantrean default, yang disebut antrean surat gagal (DLQ) untuk menampung pesan yang tidak dapat dikirim atau diproses. Azure Service Bus atau logika pemrosesan pesan di konsumen dapat menambahkan pesan ke DLQ. DLQ menyimpan pesan sampai diambil dari antrean.
Berikut adalah contoh ketika sebuah pesan bisa berakhir di DLQ:
Pesan racun adalah pesan yang tidak dapat ditangani karena formatnya salah atau berisi informasi yang tidak diharapkan. Dalam antrean Azure Service Bus, Anda dapat mendeteksi pesan racun dengan mengatur properti MaxDeliveryCount dari antrean. Jika berapa kali pesan yang sama diterima melebihi nilai properti tersebut, Azure Service Bus akan memindahkan pesan ke DLQ.
Sebuah pesan mungkin tidak lagi relevan jika tidak diproses dalam suatu periode. Antrean Azure Service Bus memungkinkan produsen untuk mengirim pesan dengan atribut time-to-live. Jika periode ini berakhir sebelum pesan diterima, pesan ditempatkan di DLQ.
Periksa pesan di DLQ untuk menentukan alasan kegagalan.
Solusi hibrida
Azure Service Bus menjembatani sistem lokal dan solusi cloud. Sistem lokal seringkali sulit dijangkau karena pembatasan firewall. Baik produsen maupun konsumen (bisa di lingkungan lokal atau di cloud) dapat menggunakan titik akhir antrean Azure Service Bus sebagai lokasi pengambilan dan pengantaran pesan.
Topik dan langganan
Azure Service Bus mendukung pola Penerbit-Pelanggan melalui topik dan langganan Azure Service Bus.
Fitur ini menyediakan cara bagi produsen untuk menyiarkan pesan ke banyak konsumen. Ketika sebuah topik menerima pesan, pesan itu diteruskan ke semua konsumen yang berlangganan. Sebagai opsi, langganan dapat memiliki kriteria filter yang memungkinkan konsumen mendapatkan subset pesan. Setiap konsumen mengambil pesan dari langganan dengan cara yang mirip dengan antrean.
Untuk informasi selengkapnya, lihat topik Azure Service Bus.
Azure Event Grid
Azure Event Grid direkomendasikan untuk peristiwa terpisah. Event Grid mengikuti pola Penerbit-Pelanggan. Saat sumber peristiwa memicu peristiwa, sumber tersebut diterbitkan ke Topik Event grid. Konsumen peristiwa tersebut membuat langganan Event Grid dengan menentukan jenis peristiwa dan penanganan aktivitas yang akan memproses peristiwa tersebut. Jika tidak ada pelanggan, peristiwa akan dibuang. Setiap peristiwa dapat memiliki beberapa langganan.
Model Push
Event Grid menyebarkan pesan ke pelanggan dalam model push. Misalkan Anda memiliki langganan kisi peristiwa dengan webhook. Saat peristiwa baru tiba, Event Grid memposting peristiwa ke titik akhir webhook.
Terintegrasi dengan Azure
Pilih Event Grid jika Anda ingin mendapatkan pemberitahuan tentang sumber daya Azure. Banyak layanan Azure bertindak sebagai sumber peristiwa yang memiliki topik Event Grid bawaan. Event Grid juga mendukung berbagai layanan Azure yang dapat dikonfigurasi sebagai penanganan aktivitas. Sangat mudah untuk berlangganan topik tersebut untuk mengarahkan peristiwa ke penanganan aktivitas pilihan Anda. Misalnya, Anda dapat menggunakan Event Grid untuk menjalankan Azure Function saat penyimpanan blob dibuat atau dihapus.
Topik kustom
Buat topik Event Grid kustom, jika Anda ingin mengirim peristiwa dari aplikasi Anda atau layanan Azure yang tidak terintegrasi dengan Event Grid.
Misalnya, untuk melihat kemajuan dari seluruh transaksi bisnis, Anda ingin layanan yang berpartisipasi untuk meningkatkan peristiwa saat mereka memproses operasi bisnis masing-masing. Aplikasi web menampilkan peristiwa tersebut. Salah satu caranya adalah dengan membuat topik kustom dan menambahkan langganan dengan aplikasi web Anda yang terdaftar melalui HTTP WebHook. Saat layanan bisnis mengirim peristiwa ke topik kustom, Event Grid mendorongnya ke aplikasi web Anda.
Peristiwa yang difilter
Anda dapat menentukan filter dalam langganan untuk menginstruksikan Event Grid agar hanya merutekan sebagian peristiwa ke penanganan aktivitas tertentu. Filter ditentukan dalam skema langganan. Setiap peristiwa yang dikirim ke topik dengan nilai yang cocok dengan filter akan otomatis diteruskan ke langganan tersebut.
Misalnya, konten dalam berbagai format diunggah ke Blob Storage. Setiap kali sebuah file ditambahkan, sebuah peristiwa dimunculkan dan dipublikasikan ke Event Grid. Langganan acara mungkin memiliki filter yang hanya mengirim peristiwa untuk gambar sehingga penanganan aktivitas dapat membuat gambar mini.
Untuk informasi selengkapnya tentang pemfilteran, lihat Memfilter peristiwa untuk Event Grid.
Throughput tinggi
Event Grid dapat merutekan 10.000.000 peristiwa per detik per wilayah. 100.000 operasi pertama per bulan gratis. Untuk pertimbangan biaya, lihat Berapa biaya Event Grid?
Pengiriman tangguh
Meskipun pengiriman yang sukses untuk peristiwa tidak sepenting perintah, Anda mungkin masih menginginkan beberapa jaminan tergantung jenis peristiwa. Event Grid menawarkan fitur yang dapat Anda aktifkan dan sesuaikan, seperti kebijakan coba lagi, waktu kedaluwarsa, dan surat gagal. Untuk informasi selengkapnya, lihat Pengiriman dan coba lagi.
Proses coba lagi Event Grid dapat membantu ketahanan tetapi tidak gagal-aman. Dalam proses coba lagi, Event Grid mungkin mengirimkan pesan lebih dari sekali, melewati, atau menunda beberapa percobaan ulang jika titik akhir tidak merespons untuk waktu yang lama. Untuk informasi selengkapnya, lihat Mencoba lagi jadwal dan durasi.
Anda dapat mempertahankan peristiwa yang tidak terkirim ke akun penyimpanan blob dengan mengaktifkan surat gagal. Ada penundaan dalam pengiriman pesan ke titik akhir penyimpanan blob dan jika titik akhir itu tidak responsif, Event Grid akan membuang peristiwa tersebut. Untuk informasi selengkapnya, lihat Surat gagal dan kebijakan coba lagi.
Azure Event Hubs
Saat bekerja dengan aliran peristiwa, Azure Event Hubs adalah perantara pesan yang direkomendasikan. Pada dasarnya, ini adalah buffer besar yang mampu menerima data dalam jumlah besar dengan latensi rendah. Data yang diterima dapat dibaca dengan cepat melalui operasi bersamaan. Anda dapat mengubah data yang diterima dengan menggunakan penyedia analitik real time. Azure Event Hubs juga menyediakan kemampuan untuk menyimpan peristiwa di akun penyimpanan.
Penyerapan cepat
Azure Event Hubs mampu menyerap jutaan peristiwa per detik. Peristiwa hanya ditambahkan ke aliran dan diurutkan berdasarkan waktu.
Model penarikan
Seperti Azure Event Grid, Azure Event Hubs juga menawarkan kemampuan Penerbit-Pelanggan. Perbedaan utama antara Azure Event Grid dan Azure Event Hubs adalah cara data peristiwa tersedia bagi pelanggan. Event Grid mendorong data yang diserap ke pelanggan sedangkan Event Hub membuat data tersedia dalam model tarik. Saat peristiwa diterima, Azure Event Hubs menambahkannya ke aliran. Pelanggan mengelola kursornya dan dapat bergerak maju dan mundur dalam aliran, memilih waktu yang diimbangi, dan memutar ulang urutan sesuai kecepatannya.
Pemroses aliran adalah pelanggan yang menarik data dari Azure Event Hubs untuk tujuan transformasi dan analisis statistik. Gunakan Azure Stream Analytics dan Apache Spark untuk pemrosesan kompleks seperti agregasi dari rentang waktu atau deteksi anomali.
Jika Anda ingin bertindak pada setiap peristiwa per partisi, Anda dapat menarik data menggunakan Host Pemrosesan Peristiwa atau dengan menggunakan konektor bawaan seperti Logic Apps untuk menyediakan logika transformasi. Opsi lain adalah menggunakan Azure Functions.
Partisi
Partisi adalah bagian dari aliran peristiwa. Peristiwa dibagi menggunakan kunci partisi. Misalnya, beberapa perangkat IoT mengirim data perangkat ke hub peristiwa. Kunci partisi adalah pengidentifikasi perangkat. Saat peristiwa diserap, Azure Event Hubs memindahkannya ke partisi yang terpisah. Dalam setiap partisi, semua acara diurutkan berdasarkan waktu.
Konsumen adalah instans kode yang memproses data peristiwa. Azure Event Hubs mengikuti pola konsumen yang dipartisi. Setiap konsumen hanya membaca partisi tertentu. Memiliki banyak partisi menghasilkan pemrosesan yang lebih cepat karena aliran dapat dibaca secara bersamaan oleh banyak konsumen.
Instans konsumen yang sama membentuk satu grup konsumen. Beberapa grup konsumen dapat membaca aliran yang sama dengan niat yang berbeda. Misalkan aliran peristiwa memiliki data dari sensor suhu. Satu grup konsumen dapat membaca aliran untuk mendeteksi anomali seperti lonjakan suhu. Konsumen lain dapat membaca aliran yang sama untuk menghitung suhu rata-rata bergulir di jendela temporal.
Azure Event Hubs mendukung pola Penerbit-Pelanggan dengan mengizinkan beberapa grup konsumen. Setiap grup konsumen adalah pelanggan.
Untuk informasi selengkapnya tentang partisi Event Hub, lihat Partisi.
Pengambilan Azure Event Hubs
Fitur Pengambilan memungkinkan Anda menyimpan aliran peristiwa ke penyimpanan Azure Blob atau Data Lake Storage. Cara menyimpan peristiwa ini dapat diandalkan karena meskipun akun penyimpanan tidak tersedia, Pengambilan menyimpan data Anda selama beberapa waktu, lalu menulis ke penyimpanan setelah tersedia.
Layanan Storage juga dapat menawarkan fitur tambahan untuk menganalisis peristiwa. Misalnya, dengan memanfaatkan tingkat akses dari akun penyimpanan blob, Anda dapat menyimpan peristiwa di tingkat yang lebih tinggi untuk data yang membutuhkan akses yang sering. Anda dapat menggunakan data tersebut untuk visualisasi. Sebagai alternatif, Anda dapat menyimpan data di tingkat arsip dan mengambilnya sesekali untuk tujuan audit.
Pengambilan menyimpan semua peristiwa yang diserap oleh Azure Event Hubs dan berguna untuk pemrosesan batch. Anda dapat membuat laporan tentang data menggunakan fungsi MapReduce. Data yang diambil juga dapat berfungsi sebagai sumber kebenaran. Jika fakta tertentu terlewatkan saat menggabungkan data, Anda dapat merujuk ke data yang diambil.
Untuk detail tentang fitur ini, lihat Mengambil peristiwa melalui Azure Event Hubs di Azure Blob Storage atau Azure Data Lake Storage.
Dukungan untuk klien Apache Kafka
Azure Event Hubs menyediakan titik akhir untuk klien Apache Kafka. Klien yang sudah ada dapat memperbarui konfigurasi mereka untuk menunjuk ke titik akhir dan mulai mengirim peristiwa ke Azure Event Hubs. Tidak ada perubahan kode yang diperlukan.
Untuk informasi selengkapnya, lihat Azure Event Hubs for Apache Kafka.
Skenario crossover
Dalam beberapa kasus, menggabungkan dua layanan olahpesan merupakan hal yang menguntungkan.
Menggabungkan layanan tersebut dapat meningkatkan efisiensi sistem olahpesan Anda. Misalnya, dalam transaksi bisnis Anda, Anda menggunakan antrean Azure Service Bus untuk menangani pesan. Antrean yang sebagian besar siaga dan menerima pesan kadang-kadang tidak efisien karena konsumen terus-menerus mengumpulkan antrean untuk pesan baru. Anda dapat menyiapkan langganan Event Grid dengan Azure Function sebagai penanganan aktivitas. Setiap kali antrean menerima pesan dan tidak ada konsumen yang mendengarkan, Event Grid mengirimkan pemberitahuan, yang memanggil Azure Function yang mengalirkan antrean.
Untuk detail tentang menyambungkan Azure Service Bus ke Event Grid, lihat Ringkasan integrasi Azure Service Bus ke Event Grid.
Arsitektur referensi Integrasi perusahaan di Azure menggunakan antrean pesan dan peristiwa menunjukkan penerapan integrasi Azure Service Bus ke Event Grid.
Berikut adalah contoh lain. Event Grid menerima set peristiwa di mana beberapa peristiwa memerlukan alur kerja sementara peristiwa yang lain untuk pemberitahuan. Metadata pesan menunjukkan jenis peristiwa. Salah satu caranya adalah dengan memeriksa metadata menggunakan fitur pemfilteran di langganan peristiwa. Jika memerlukan alur kerja, Event Grid mengirimkannya ke antrean Azure Service Bus. Penerima antrean itu dapat mengambil tindakan yang diperlukan. Peristiwa pemberitahuan dikirim ke Logic Apps untuk mengirim email peringatan.
Pola terkait
Pertimbangkan pola berikut saat menerapkan pesan asinkron:
- Pola Konsumen yang Bersaing. Beberapa konsumen mungkin perlu bersaing untuk membaca pesan dari antrean. Pola ini menjelaskan cara memproses beberapa pesan secara bersamaan untuk mengoptimalkan throughput, meningkatkan skalabilitas dan ketersediaan, serta menyeimbangkan beban kerja.
- Pola Antrean Prioritas. Untuk kasus di mana logika bisnis mengharuskan beberapa pesan diproses sebelum yang lain, pola ini menjelaskan bagaimana pesan yang diposting oleh produsen yang memiliki prioritas lebih tinggi dapat diterima dan diproses lebih cepat oleh konsumen daripada pesan dengan prioritas lebih rendah.
- Pola Perataan Beban Berbasis Antrean. Pola ini menggunakan perantara pesan untuk bertindak sebagai buffer antara produsen dan konsumen untuk membantu meminimalkan dampak pada ketersediaan dan responsivitas beban berat yang terputus-putus untuk kedua entitas tersebut.
- Pola Coba Lagi. Produsen atau konsumen mungkin tidak dapat terhubung ke antrean, tetapi alasan kegagalan ini mungkin bersifat sementara dan cepat berlalu. Pola ini menjelaskan cara menangani situasi ini untuk menambahkan ketahanan ke aplikasi.
- Pola Scheduler Agent Supervisor. Olahpesan sering digunakan sebagai bagian dari penerapan alur kerja. Pola ini menunjukkan bagaimana pesan dapat mengoordinasikan serangkaian tindakan di seluruh rangkaian layanan terdistribusi dan sumber daya jarak jauh lainnya, dan memungkinkan sistem untuk memulihkan dan mencoba kembali tindakan yang gagal.
- Pola koreografi. Pola ini menunjukkan bagaimana layanan dapat menggunakan olahpesan untuk mengontrol alur kerja transaksi bisnis.
- Pola Pemeriksaan-Klaim. Pola ini menunjukkan cara membagi pesan besar menjadi pemeriksaan klaim dan payload.
Sumber daya komunitas
Postingan blog Jonathon Oliver: Idempotensi
Postingan blog Martin Fowler: Apa yang Anda maksud dengan "Berbasis Peristiwa"?