Bagikan melalui

Fitur dan terminologi di Azure Event Hubs

Azure Event Hubs adalah layanan pemrosesan peristiwa yang dapat diskalakan yang menyerap dan memproses peristiwa dan data dalam volume besar, dengan latensi rendah dan keandalan tinggi. Untuk gambaran umum tingkat tinggi tentang layanan, lihat Apa itu Azure Event Hubs?.

Artikel ini dibangun berdasarkan informasi dalam artikel gambaran umum, dan menyediakan detail teknis dan implementasi tentang komponen dan fitur Azure Event Hubs.

Ruang Nama

Namespace Event Hubs adalah kontainer manajemen untuk hub peristiwa (atau topik, dalam istilah Kafka). Ini menyediakan titik akhir jaringan terintegrasi DNS dan berbagai kontrol akses dan fitur manajemen integrasi jaringan seperti pemfilteran IP, titik akhir layanan jaringan virtual, dan Private Link.

Gambar yang menunjukkan namespace Event Hubs

Sekat

Azure Event Hubs mengatur urutan peristiwa yang dikirim ke event hub ke dalam satu atau beberapa partisi. Ketika peristiwa yang lebih baru tiba, peristiwa tersebut akan ditambahkan ke akhir urutan ini.

Gambar yang menunjukkan Event Hub dengan beberapa partisi.

Partisi dapat dianggap sebagai catatan komit. Partisi menyimpan data peristiwa yang berisi informasi berikut:

  • Isi peristiwa
  • Kumpulan properti yang ditentukan pengguna yang menjelaskan acara
  • Metadata seperti offsetnya dalam partisi, jumlahnya dalam urutan aliran
  • Tanda waktu sisi layanan saat diterima

Diagram yang menampilkan urutan peristiwa yang lebih lama ke yang lebih baru.

Manfaat menggunakan partisi

Azure Event Hubs dirancang untuk membantu pemrosesan acara dalam jumlah besar, dan partisi membantu dengan dua cara:

  • Meskipun Azure Event Hubs adalah layanan PaaS, ada realitas fisik di bawahnya. Memelihara log yang menjaga urutan peristiwa mensyaratkan bahwa peristiwa-peristiwa ini disimpan bersama-sama dalam penyimpanan dasar dan replikanya, yang mengakibatkan adanya batas throughput untuk log tersebut. Partisi memungkinkan penggunaan beberapa log paralel untuk hub peristiwa yang sama dan dengan demikian meningkatkan kapasitas throughput IO mentah yang tersedia.
  • Aplikasi Anda sendiri harus dapat mengikuti pemrosesan volume peristiwa yang dikirim ke hub peristiwa. Ini mungkin kompleks dan membutuhkan kapasitas pemrosesan paralel yang signifikan dan terukur. Kapasitas satu proses untuk menangani peristiwa terbatas, sehingga Anda memerlukan beberapa proses. Partisi adalah cara solusi Anda mendukung proses tersebut dan memastikan bahwa setiap kejadian memiliki pemilik pemrosesan yang jelas.

Jumlah partisi

Jumlah partisi ditentukan pada saat membuat hub peristiwa. Ini harus antara satu dan jumlah partisi maksimum yang diizinkan untuk setiap tingkat harga. Untuk batas jumlah partisi untuk setiap tingkat, lihat artikel ini.

Kami menyarankan Anda memilih setidaknya sebanyak partisi yang Anda perkirakan diperlukan selama beban puncak aplikasi Anda untuk hub peristiwa tertentu tersebut. Untuk tingkatan selain tingkat premium dan khusus, Anda tidak dapat mengubah jumlah partisi untuk pusat aktivitas setelah pembuatannya. Untuk hub peristiwa di tingkat premium atau khusus, Anda dapat meningkatkan jumlah partisi setelah pembuatannya, tetapi Anda tidak dapat menguranginya lagi. Distribusi aliran di seluruh partisi akan berubah ketika kunci partisi dipetakan ulang ke partisi. Oleh karena itu, Anda harus berusaha keras untuk menghindari perubahan tersebut jika urutan peristiwa penting bagi aplikasi Anda.

Mengatur jumlah partisi ke nilai maksimum yang diizinkan mungkin menarik, tetapi selalu ingat bahwa aliran peristiwa Anda harus terstruktur sedemikian rupa sehingga Anda memang dapat memanfaatkan banyak partisi. Jika Anda memerlukan pelestarian urutan secara mutlak untuk semua kejadian atau hanya beberapa sub-aliran, Anda mungkin tidak dapat memanfaatkan banyak partisi. Juga, partisi dalam jumlah banyak membuat sisi pemrosesan lebih kompleks.

Tidak masalah berapa banyak partisi yang ada di event hub dalam hal harga. Hal ini bergantung pada jumlah unit harga (unit throughput (TU) untuk tingkat standar, unit pemrosesan (PU) untuk tingkat premium, dan unit kapasitas (CU) untuk tingkat khusus) untuk namespace atau kluster khusus. Misalnya, pusat aktivitas tingkat standar dengan 32 partisi atau dengan satu partisi dikenakan biaya yang sama persis ketika namespace diatur ke satu kapasitas TU. Selain itu, Anda dapat menskalakan TU atau PU pada namespace atau CU kluster khusus Anda terlepas dari jumlah partisi.

Partisi adalah mekanisme organisasi data yang memungkinkan penerbitan dan konsumsi paralel. Meskipun mendukung pemrosesan dan penskalaan paralel, total kapasitas tetap dibatasi oleh alokasi penskalaan namespace. Kami menyarankan agar Anda menyeimbangkan unit penskalaan (unit throughput untuk tingkat standar, unit pemrosesan untuk tingkat premium, atau unit kapasitas untuk tingkat khusus) dan partisi untuk mencapai skala yang optimal. Secara umum, kami menyarankan throughput maksimum 1 MB per detik per partisi. Oleh karena itu, aturan praktis untuk menghitung jumlah partisi adalah membagi throughput maksimum yang diharapkan dengan 1 MB/dtk. Misalnya, jika skenario penggunaan Anda memerlukan 20 MB/dtk, kami menyarankan agar Anda memilih setidaknya 20 partisi untuk mencapai throughput yang optimal.

Namun, jika Anda memiliki model di mana aplikasi Anda memiliki afinitas ke partisi tertentu, meningkatkan jumlah partisi tidak bermanfaat. Untuk informasi selengkapnya, lihat ketersediaan dan konsistensi.

Pemetaan peristiwa ke partisi

Anda dapat menggunakan kunci partisi untuk memetakan data peristiwa yang masuk ke dalam partisi tertentu untuk tujuan organisasi data. Kunci partisi adalah nilai yang disediakan pengirim yang diteruskan ke event hub. Ini diproses melalui fungsi hashing statis, yang membuat penetapan partisi. Jika Anda tidak menentukan kunci partisi saat menerbitkan peristiwa, maka penugasan round-robin akan digunakan.

Penerbit acara hanya mengetahui kunci partisinya, bukan partisi di mana peristiwa diterbitkan. Pemisahan kunci dan partisi ini membuat pengirim tidak perlu mengetahui terlalu banyak tentang pemrosesan hilir. Identitas unik per perangkat atau pengguna membuat kunci partisi yang baik, tetapi atribut lain seperti geografi juga dapat digunakan untuk mengelompokkan peristiwa terkait ke dalam satu partisi.

Menentukan kunci partisi memungkinkan menyimpan peristiwa terkait bersama-sama di partisi yang sama dan dalam urutan yang tepat di mana mereka tiba. Kunci partisi adalah beberapa untai yang diturunkan dari konteks aplikasi Anda dan mengidentifikasi keterkaitan peristiwa. Urutan peristiwa yang diidentifikasi oleh kunci partisi adalah aliran. Partisi adalah penyimpanan log multipleks untuk banyak aliran seperti itu.

Nota

Meskipun Anda dapat mengirim acara langsung ke partisi, kami tidak merekomendasikannya, terutama jika ketersediaan tinggi penting bagi Anda. Ini mengurangi ketersediaan event hub ke tingkat partisi. Untuk informasi selengkapnya, lihat Ketersediaan dan Konsistensi.

Penerbit peristiwa

Entitas apa pun yang mengirim data ke pusat aktivitas adalah penerbit peristiwa (secara identik digunakan dengan produsen peristiwa). Penerbit peristiwa dapat menerbitkan peristiwa menggunakan HTTPS atau AMQP 1.0 atau protokol Kafka. Penerbit peristiwa menggunakan otorisasi berbasis ID Microsoft Entra dengan JWT yang dikeluarkan OAuth2 atau token Tanda Tangan Akses Bersama khusus Event Hub (SAS) untuk mendapatkan akses penerbitan.

Anda dapat menerbitkan peristiwa melalui AMQP 1.0, protokol Kafka, atau HTTPS. Layanan Azure Event Hubs menyediakan pustaka klien REST API dan .NET, Java, Python, JavaScript, dan Go untuk menerbitkan peristiwa ke pusat aktivitas. Untuk runtime dan platform lainnya, Anda dapat menggunakan klien AMQP 1.0 apa pun, seperti Apache Qpid.

Pilihan untuk menggunakan AMQP atau HTTPS khusus untuk skenario penggunaan. AMQP memerlukan pembentukan soket dua arah persisten selain keamanan tingkat transportasi (TLS) atau SSL/TLS. AMQP memiliki biaya jaringan yang lebih tinggi saat menginisialisasi sesi, namun HTTPS memerlukan overhead TLS tambahan untuk setiap permintaan. AMQP memiliki performa yang lebih tinggi untuk penerbit yang sering dan dapat mencapai latensi yang jauh lebih rendah ketika digunakan dengan kode penerbitan asinkron.

Anda dapat menerbitkan peristiwa satu per satu atau dalam batch. Satu publikasi memiliki batas 1 MB, terlepas dari apakah itu satu peristiwa atau batch. Penayangan peristiwa yang melebihi ambang batas ini akan ditolak.

Throughput pada Azure Event Hubs diperluas dengan menggunakan partisi dan alokasi unit throughput. Ini adalah praktik terbaik bagi penerbit untuk tetap tidak menyadari model partisi tertentu yang dipilih untuk pusat aktivitas dan hanya menentukan kunci partisi yang digunakan untuk menetapkan peristiwa terkait secara konsisten ke partisi yang sama.

Diagram yang menunjukkan bagaimana kunci partisi dipetakan ke partisi dalam event hub.

Azure Event Hubs memastikan bahwa semua peristiwa yang berbagi nilai kunci partisi disimpan bersama-sama dan dikirimkan dalam urutan kedatangan. Jika kunci partisi digunakan dengan kebijakan penerbit, identitas penerbit dan nilai kunci partisi harus cocok. Jika tidak, kesalahan terjadi.

Retensi Peristiwa

Peristiwa yang diterbitkan dihapus dari pusat aktivitas berdasarkan kebijakan penyimpanan berbasis waktu yang dapat dikonfigurasi. Berikut adalah beberapa poin penting:

  • Nilai default dan periode retensi sesingkat mungkin adalah 1 jam.
  • Untuk Event Hubs Standard, periode retensi maksimum adalah 7 hari.
  • Untuk Event Hubs Premium dan Dedicated, periode retensi maksimum adalah 90 hari.
  • Jika Anda mengubah periode retensi, periode tersebut berlaku untuk semua peristiwa termasuk peristiwa yang sudah ada di hub peristiwa.

Azure Event Hubs mempertahankan peristiwa untuk jangka waktu retensi yang telah dikonfigurasi dan berlaku untuk semua partisi. Peristiwa secara otomatis dihapus ketika periode retensi telah tercapai. Jika Anda menentukan periode retensi satu hari (24 jam), peristiwa menjadi tidak tersedia tepat 24 jam setelah diterima. Anda tidak dapat menghapus peristiwa secara eksplisit.

Jika Anda perlu mengarsipkan peristiwa di luar periode retensi yang diizinkan, Anda dapat menyimpannya secara otomatis di Azure Storage atau Azure Data Lake dengan mengaktifkan fitur Pengambilan Azure Event Hubs. Jika Anda perlu mencari atau menganalisis arsip mendalam tersebut, Anda dapat dengan mudah mengimpornya ke Azure Synapse atau platform penyimpanan dan analitik serupa lainnya.

Alasan batas Event Hubs pada retensi data berdasarkan waktu adalah untuk mencegah volume besar data sejarah pelanggan terjebak di penyimpanan mendalam yang hanya diindeks berdasarkan tanda waktu dan hanya memungkinkan akses secara berurutan. Filosofi arsitektur di sini adalah bahwa data historis membutuhkan pengindeksan yang lebih kaya dan akses yang lebih langsung daripada antarmuka peristiwa real-time yang disediakan Azure Event Hubs atau Kafka. Mesin streaming peristiwa tidak cocok untuk memainkan peran data lake atau arsip jangka panjang untuk sumber peristiwa.

Nota

Azure Event Hubs adalah mesin aliran peristiwa waktu nyata dan tidak dirancang untuk digunakan sebagai pengganti database dan/atau sebagai penyimpanan permanen untuk menyimpan aliran peristiwa tanpa batas waktu.

Semakin dalam riwayat aliran peristiwa, semakin banyak Anda memerlukan indeks tambahan untuk menemukan irisan historis tertentu dari aliran tertentu. Inspeksi payload peristiwa dan pengindeksan tidak berada dalam cakupan fitur Event Hubs (atau Apache Kafka). Database dan penyimpanan dan mesin analitik khusus seperti Azure Data Lake Store, Azure Data Lake Analytics, dan Azure Synapse oleh karena itu jauh lebih cocok untuk menyimpan peristiwa bersejarah.

Azure Event Hubs Capture terintegrasi langsung dengan Azure Blob Storage dan Azure Data Lake Storage dan, melalui integrasi tersebut, juga memungkinkan peristiwa yang mengalir langsung ke Azure Synapse.

Kebijakan penerbit

Azure Event Hubs memungkinkan kontrol terperinci atas penerbit peristiwa melalui kebijakan penerbit. Kebijakan penerbit acara adalah fitur operasional yang dirancang untuk memfasilitasi dalam jumlah besar penerbit acara yang independen. Dengan kebijakan penerbitan, setiap penerbit menggunakan identifier uniknya sendiri saat menerbitkan peristiwa ke hub acara, menggunakan mekanisme berikut:

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

Anda tidak perlu membuat nama penerbit sebelumnya, tetapi harus cocok dengan token SAS yang digunakan saat menerbitkan peristiwa, untuk memastikan identitas penerbit independen. Saat Anda menggunakan kebijakan penerbit, nilai PartitionKey perlu diatur ke nama penerbit. Agar berfungsi dengan baik, nilai-nilai ini harus cocok.

Menangkap

Azure Event Hubs Capture memungkinkan Anda mengambil data streaming secara otomatis di Azure Event Hubs dan menyimpannya ke akun penyimpanan Blob pilihan Anda, atau akun Azure Data Lake Storage. Anda dapat mengaktifkan pengambilan dari portal Microsoft Azure, dan menentukan ukuran minimum dan jendela waktu untuk melakukan pengambilan. Dengan menggunakan Azure Event Hubs Capture, Anda menentukan akun dan kontainer Azure Blob Storage Anda sendiri, atau akun Azure Data Lake Storage, salah satunya digunakan untuk menyimpan data yang diambil. Data yang diambil ditulis dalam format Apache Avro.

Diagram yang memperlihatkan pengambilan data Azure Event Hubs ke Azure Storage atau Azure Data Lake Storage.

File yang dihasilkan oleh Azure Event Hubs Capture memiliki skema Avro berikut:

Diagram memperlihatkan struktur data Avro yang diambil.

Nota

Saat Anda tidak menggunakan editor kode di portal Azure, Anda dapat merekam data streaming di Event Hubs di akun Azure Data Lake Storage Gen2 dalam format Parket. Untuk informasi selengkapnya, lihat Cara: mengambil data dari Event Hubs dalam format Parket dan Tutorial: mengambil data Event Hubs dalam format Parket dan menganalisis dengan Azure Synapse Analytics.

Token SAS

Azure Event Hubs menggunakan Tanda Tangan Akses Bersama, yang tersedia di tingkat namespace layanan dan hub peristiwa. Token SAS dihasilkan dari kunci SAS dan merupakan hash SHA dari URL, dikodekan dalam format tertentu. Azure Event Hubs dapat meregenerasi hash dengan menggunakan nama kunci (kebijakan) dan token dan dengan demikian mengautentikasi pengirim. Biasanya, token SAS untuk penerbit acara dibuat hanya dengan izin pengiriman pada hub acara tertentu. Mekanisme URL token SAS ini adalah dasar untuk identifikasi penerbit yang diperkenalkan dalam kebijakan penerbit. Untuk informasi selengkapnya tentang bekerja dengan SAS, lihat Autentikasi Tanda Tangan Akses Bersama dengan Azure Service Bus.

Pengguna acara

Entitas apa pun yang membaca data peristiwa dari pusat aktivitas adalah konsumen peristiwa. Konsumen atau penerima menggunakan AMQP atau Apache Kafka untuk menerima peristiwa dari pusat aktivitas. Azure Event Hubs hanya mendukung model penarikan (pull model) bagi konsumen untuk menerima event dari layanan tersebut. Bahkan ketika Anda menggunakan penanganan aktivitas untuk menangani peristiwa dari pusat aktivitas, prosesor peristiwa secara internal menggunakan model penarikan untuk menerima peristiwa dari pusat aktivitas.

Grup konsumen

Mekanisme publikasi/berlangganan Azure Event Hubs diaktifkan melalui grup konsumen. Grup konsumen adalah pengelompokan logis konsumen yang membaca data dari pusat aktivitas atau topik Kafka. Ini memungkinkan beberapa aplikasi yang mengonsumsi untuk membaca data streaming yang sama dalam hub peristiwa secara mandiri sesuai dengan kecepatan dan offset masing-masing. Ini memungkinkan Anda untuk menyejajarkan konsumsi pesan dan mendistribusikan beban kerja di antara beberapa konsumen sambil mempertahankan urutan pesan dalam setiap partisi.

Kami menyarankan agar hanya ada satu penerima aktif pada partisi dalam grup konsumen. Namun, dalam skenario tertentu, Anda dapat menggunakan hingga lima konsumen atau penerima per partisi di mana semua penerima mendapatkan semua peristiwa partisi. Jika Anda memiliki beberapa pembaca pada partisi yang sama, maka Anda memproses peristiwa duplikat. Anda perlu menanganinya dalam kode Anda, yang tidak sepele. Namun, ini adalah pendekatan yang valid dalam beberapa skenario.

Dalam arsitektur pemrosesan aliran, setiap aplikasi hilir sama dengan grup konsumen. Jika Anda ingin menulis data peristiwa ke penyimpanan jangka panjang, maka aplikasi penulis penyimpanan tersebut adalah grup konsumen. Pemrosesan peristiwa yang kompleks kemudian dapat dilakukan oleh grup konsumen lain yang terpisah. Anda hanya dapat mengakses partisi melalui grup konsumen. Selalu ada grup konsumen default di pusat aktivitas, dan Anda dapat membuat hingga jumlah maksimum grup konsumen untuk tingkat harga yang sesuai.

Beberapa klien yang ditawarkan oleh Azure SDK adalah agen konsumen cerdas yang secara otomatis mengelola detail untuk memastikan bahwa setiap partisi memiliki satu pembaca dan bahwa semua partisi untuk pusat aktivitas sedang dibaca. Ini memungkinkan kode Anda untuk fokus pada pemrosesan peristiwa yang dibaca dari hub peristiwa sehingga dapat mengabaikan banyak detail partisi. Untuk informasi selengkapnya, lihat Menyambungkan ke partisi.

Contoh berikut menunjukkan konvensi URI grup konsumen:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

Gambar berikut menunjukkan arsitektur pemrosesan aliran Azure Event Hubs:

Diagram yang memperlihatkan arsitektur pemrosesan aliran Azure Event Hubs.

Offset aliran

Offset adalah posisi peristiwa dalam partisi. Anda dapat menganggap offset sebagai kursor pada sisi klien. Offset adalah penomoran byte dari peristiwa. Offset ini memungkinkan konsumen peristiwa (pembaca) untuk menentukan titik dalam aliran peristiwa tempat mereka ingin mulai membaca peristiwa. Anda dapat menentukan offset sebagai tanda waktu atau sebagai nilai offset. Konsumen bertanggung jawab untuk menyimpan nilai offset mereka sendiri di luar layanan Azure Event Hubs. Dalam partisi, setiap peristiwa menyertakan offset.

Diagram yang memperlihatkan partisi dengan offset.

Titik Pemeriksaan

Titik pemeriksaan adalah proses di mana pembaca menandai atau menerapkan posisi mereka dalam urutan peristiwa partisi. Titik pemeriksaan adalah tanggung jawab konsumen dan terjadi berdasarkan per partisi dalam grup konsumen. Tanggung jawab ini berarti bahwa untuk setiap grup konsumen, setiap pembaca partisi harus melacak posisinya saat ini dalam aliran peristiwa, dan dapat memberi tahu layanan ketika menganggap aliran data selesai.

Jika pembaca terputus dari partisi, ketika terhubung kembali, pembaca mulai membaca di titik pemeriksaan yang sebelumnya dikirimkan oleh pembaca terakhir partisi tersebut di grup konsumen tersebut. Saat pembaca terhubung, pembaca mengirimkan offset ke Event Hub untuk menentukan lokasi mulai membaca. Dengan cara ini, Anda dapat menggunakan titik pemeriksaan untuk menandai peristiwa sebagai "selesai" oleh aplikasi hilir, dan untuk memberikan ketahanan jika kegagalan antara pembaca yang berjalan di komputer yang berbeda terjadi. Dimungkinkan untuk kembali ke data yang lebih lama dengan menentukan offset yang lebih rendah dari proses titik pemeriksaan ini. Melalui mekanisme ini, titik pemeriksaan memungkinkan ketahanan failover dan pemutaran ulang aliran peristiwa.

Penting

Offset disediakan oleh layanan Event Hubs. Tanggung jawab konsumen adalah untuk memeriksa saat peristiwa diproses.

Ikuti rekomendasi ini saat Anda menggunakan Azure Blob Storage sebagai penyimpanan titik pemeriksaan:

  • Gunakan kontainer terpisah untuk setiap grup konsumen. Anda dapat menggunakan akun penyimpanan yang sama, tetapi menggunakan satu kontainer per setiap grup.
  • Jangan gunakan akun penyimpanan untuk hal lain.
  • Jangan gunakan kontainer untuk hal lain.
  • Buat akun penyimpanan di wilayah yang sama dengan aplikasi yang disebarkan. Jika aplikasi lokal, coba pilih wilayah terdekat yang mungkin.

Pada halaman Akun penyimpanan di portal Azure, di bagian Blob service, pastikan bahwa pengaturan berikut dinonaktifkan.

  • Namespace hierarkis
  • Penghapusan sementara blob
  • Pembuatan Versi

Pemadatan log

Azure Event Hubs mendukung log peristiwa yang disederhanakan untuk mempertahankan peristiwa terbaru dari setiap kunci peristiwa tertentu. Dengan topik event hubs/Kafka yang dikompilasi, Anda dapat menggunakan retensi berbasis kunci daripada menggunakan retensi berbasis waktu kasar.

Untuk informasi selengkapnya tentang pemadatan log, lihat Log compaction.

Tugas konsumen umum

Semua konsumen Azure Event Hubs terhubung melalui sesi AMQP 1.0, saluran komunikasi dua arah yang sadar status. Setiap partisi memiliki sesi AMQP 1.0 yang memfasilitasi pengangkutan peristiwa yang dipisahkan oleh partisi.

Menyambungkan ke partisi

Saat menyambungkan ke partisi, adalah praktik umum untuk menggunakan mekanisme penyewaan untuk mengoordinasikan koneksi pembaca ke partisi tertentu. Dengan cara ini, dimungkinkan bagi setiap partisi dalam grup konsumen untuk hanya memiliki satu pembaca aktif. Titik pemeriksaan, penyewaan, dan pengelolaan pembaca disederhanakan dengan menggunakan klien dalam SDK Azure Event Hubs, yang bertindak sebagai agen konsumen cerdas. Mereka adalah:

Membaca peristiwa

Setelah sesi AMQP 1.0 dan tautan dibuka untuk partisi tertentu, peristiwa dikirimkan ke klien AMQP 1.0 oleh layanan Azure Event Hubs. Mekanisme pengiriman ini memungkinkan throughput yang lebih tinggi dan latensi yang lebih rendah daripada mekanisme berbasis penarikan seperti HTTP GET. Saat peristiwa dikirim ke klien, setiap instans data peristiwa berisi metadata penting seperti offset dan nomor urut yang digunakan untuk memfasilitasi titik pemeriksaan pada urutan peristiwa.

Data peristiwa:

  • Offset
  • Nomor urut
  • Tubuh
  • Properti pengguna
  • Properti sistem

Anda bertanggung jawab untuk mengelola offset.

Grup aplikasi

Grup aplikasi adalah kumpulan aplikasi klien yang terhubung ke namespace Layanan Pusat Aktivitas yang berbagi kondisi identifikasi unik seperti konteks keamanan - kebijakan akses bersama atau ID aplikasi Microsoft Entra.

Azure Event Hubs memungkinkan Anda menentukan kebijakan akses sumber daya seperti kebijakan pembatasan untuk grup aplikasi tertentu dan mengontrol streaming peristiwa (penerbitan atau penggunaan) antara aplikasi klien dan Azure Event Hubs.

Untuk informasi selengkapnya, lihat Tata kelola sumber daya untuk aplikasi klien dengan grup aplikasi.

Dukungan Apache Kafka

Dukungan protokol untuk klien Apache Kafka (versi >=1.0) menyediakan titik akhir yang memungkinkan aplikasi Kafka yang ada untuk menggunakan Azure Event Hubs. Sebagian besar aplikasi Kafka yang ada dapat dikonfigurasi ulang untuk menunjuk ke namespace tertentu daripada server bootstrap kluster Kafka.

Dari perspektif biaya, upaya operasional, dan keandalan, Azure Event Hubs adalah alternatif yang bagus untuk menerapkan dan mengoperasikan kluster Kafka dan Zookeeper Anda sendiri serta penawaran Kafka-as-a-Service yang tidak asli dari Azure.

Selain mendapatkan fungsionalitas inti yang sama dengan broker Apache Kafka, Anda juga mendapatkan akses ke fitur Azure Event Hubs seperti batching dan pengarsipan otomatis melalui Event Hubs Capture, penskalaan dan penyeimbangan otomatis, pemulihan bencana, dukungan zona ketersediaan yang netral biaya, integrasi jaringan yang fleksibel dan aman, dan dukungan multi-protokol termasuk protokol AMQP-over-WebSockets yang ramah firewall.

Protokol

Produsen atau pengirim dapat menggunakan protokol Advanced Messaging Queuing Protocol (AMQP), Kafka, atau HTTPS untuk mengirim peristiwa ke pusat aktivitas.

Konsumen atau penerima menggunakan AMQP atau Kafka untuk menerima peristiwa dari pusat aktivitas. Azure Event Hubs hanya mendukung model penarikan (pull model) bagi konsumen untuk menerima event dari layanan tersebut. Bahkan ketika Anda menggunakan penanganan aktivitas untuk menangani peristiwa dari pusat aktivitas, prosesor peristiwa secara internal menggunakan model penarikan untuk menerima peristiwa dari pusat aktivitas.

AMQP

Anda dapat menggunakan protokol AMQP 1.0 untuk mengirim peristiwa ke dan menerima peristiwa dari Azure Event Hubs. AMQP menyediakan komunikasi yang andal, berkinerja, dan aman untuk mengirim dan menerima peristiwa. Anda dapat menggunakannya untuk streaming performa tinggi dan real-time dan didukung oleh sebagian besar SDK Azure Event Hubs.

HTTPS/REST API

Anda hanya dapat mengirim peristiwa ke Azure Event Hubs menggunakan permintaan HTTP POST. Azure Event Hubs tidak mendukung penerimaan peristiwa melalui HTTPS. Ini cocok untuk klien ringan di mana koneksi TCP langsung tidak memungkinkan.

Apache Kafka

Azure Event Hubs memiliki titik akhir Kafka bawaan yang mendukung produsen dan konsumen Kafka. Aplikasi yang dibangun menggunakan Kafka dapat menggunakan protokol Kafka (versi 1.0 atau yang lebih baru) untuk mengirim dan menerima peristiwa dari Azure Event Hubs tanpa perubahan kode apa pun.

Azure SDK mengabstraksi protokol komunikasi yang mendasar dan menyediakan cara yang disederhanakan untuk mengirim dan menerima peristiwa dari Azure Event Hubs menggunakan bahasa seperti C#, Java, Python, JavaScript, dll.

Langkah selanjutnya

Untuk informasi selengkapnya tentang Azure Event Hubs, kunjungi tautan berikut: