Fitur dan terminologi di Azure Event Hubs

  • Artikel
  • 15 menit untuk membaca

Azure Event Hubs adalah layanan pemrosesan peristiwa terskala yang menyerap dan memproses peristiwa dan data dalam volume besar, dengan latensi rendah dan keandalan tinggi. Lihat Apa itu Pusat Aktivitas? untuk gambaran umum lengkap.

Artikel ini menyusun informasi dalam artikel gambaran umum, dan memberikan detail teknis serta implementasi tentang komponen dan fitur Pusat Aktivitas.

Tip

Dukungan protokol untuk klien Apache Kafka (versi >=1.0) menyediakan titik akhir jaringan yang memungkinkan aplikasi yang dibuat untuk menggunakan Apache Kafka dengan klien apa pun untuk menggunakan Azure Event Hubs. Sebagian besar aplikasi Kafka yang ada hanya dapat dikonfigurasi ulang untuk menunjuk ke namespace layanan Pusat Aktivitas alih-alih server bootstrap kluster Kafka.

Dari perspektif biaya, upaya operasional, dan keandalan, Azure Event Hubs adalah alternatif yang bagus untuk menyebarkan dan mengoperasikan kluster Kafka dan Zookeeper Anda sendiri serta untuk penawaran Kafka-sebagai-layanan yang tidak berasal dari Azure.

Selain mendapatkan fungsi inti yang sama dengan broker Apache Kafka, Anda juga mendapatkan akses ke fitur Azure Event Hub seperti batching dan pengarsipan otomatis melalui Pengambilan Event Hubs, 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-atas-WebSockets yang ramah firewall.

Ruang nama

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

Gambar yang menunjukkan namespace layanan Azure Event Hubs

Penerbit aktivitas

Setiap entitas yang mengirim data ke suatu hub kejadian adalah penerbit kejadian (digunakan juga dengan produser kejadian). Penerbit peristiwa dapat menerbitkan peristiwa menggunakan HTTPS atau AMQP 1.0 atau Apache Kafka. Penerbit peristiwa menggunakan otorisasi berbasis Azure Active Directory dengan token JWT yang dikeluarkan OAuth2 atau akses penerbitan token Tandatangan Akses Bersama (SAS) khusus Pusat Aktivitas.

Menerbitkan peristiwa

Anda dapat menerbitkan peristiwa melalui AMQP 1.0, protokol Kafka, atau HTTPS. Layanan Event Hubs menyediakan REST API dan pustaka klien .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 transpor (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 jauh lebih tinggi bagi yang sering menerbit 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 sebesar 1 MB, terlepas dari apakah itu kejadian tunggal atau batch. Peristiwa penerbitan yang lebih besar dari ambang batas ini akan ditolak.

Throughput Pusat Aktivitas diskalakan dengan menggunakan partisi dan alokasi unit throughput (lihat di bawah). Tindakan ini adalah praktik terbaik bagi penerbit agar tetap tidak menyadari model pemartisian tertentu yang dipilih untuk suatu hub kejadian dan hanya untuk menentukan kunci partisi yang digunakan untuk menetapkan kejadian terkait secara konsisten ke partisi yang sama.

Kunci partisi

Pusat Aktivitas memastikan bahwa semua peristiwa yang berbagi nilai kunci partisi disimpan bersama dan dikirimkan dalam urutan kedatangan. Jika kunci partisi digunakan dengan kebijakan penerbit, maka identitas penerbit dan nilai kunci partisi harus cocok. Jika tidak, akan terjadi kesalahan.

Retensi kejadian

Kejadian yang diterbitkan akan dihapus dari hub kejadian berdasarkan kebijakan penyimpanan berbasis waktu yang dapat dikonfigurasi. Berikut adalah beberapa poin penting:

  • Nilai default dan periode retensi sesingkat mungkin adalah 1 hari (24 jam) .
  • Untuk Pusat Aktivitas Standar, periode retensi maksimum adalah 7 hari.
  • Untuk Azure Event HubsPremium dan Khusus, periode retensi maksimum adalah selama 90 hari.
  • Jika Anda mengubah periode retensi, itu berlaku untuk semua kejadian yang sudah ada di hub kejadian.

Pusat Aktivitas mempertahankan peristiwa untuk waktu penyimpanan yang dikonfigurasi yang berlaku di semua partisi. Peristiwa dihapus secara otomatis saat periode penyimpanan telah tercapai. Jika Anda menentukan periode retensi menjadi satu hari, peristiwa akan menjadi tidak tersedia tepat 24 jam setelah diterima. Anda tidak dapat menghapus peristiwa secara eksplisit.

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

Alasan batas Pusat Aktivitas pada retensi data berdasarkan waktu adalah untuk mencegah data pelanggan bersejarah dalam volume besar terjebak di penyimpanan dalam yang hanya diindeks oleh cap waktu dan hanya memungkinkan akses berurutan. Filosofi arsitektur di sini adalah bahwa data historis membutuhkan pengindeksan yang lebih kaya dan akses yang lebih langsung daripada antarmuka kejadian real-time yang disediakan oleh Azure Event Hubs atau Kafka. Mesin aliran kejadian tidak cocok untuk memainkan peran data lake atau arsip jangka panjang untuk sumber kejadian.

Catatan

Pusat Aktivitas adalah mesin pengalir peristiwa real-time dan tidak dirancang untuk digunakan alih-alih database dan/atau sebagai penyimpanan permanen untuk pengaliran peristiwa yang diadakan tanpa batas.

Semakin dalam sejarah aliran peristiwa, semakin Anda akan membutuhkan indeks tambahan untuk menemukan potongan historis tertentu dari aliran tertentu. Inspeksi payload kejadian dan pengindeksan tidak berada dalam cakupan fitur Azure Event Hubs (atau Apache Kafka). Database dan penyimpanan analitik serta mesin khusus seperti Azure Data Lake Storage, Azure Data Lake Analytics, dan Azure Synapse jauh lebih cocok untuk menyimpan peristiwa bersejarah.

Pengambilan Pusat Aktivitas terintegrasi langsung dengan Azure Blob Storage dan Azure Data Lake Storage dan, melalui integrasi itu, juga memungkinkan peristiwa yang mengalir langsung ke Azure Synapse.

Kebijakan penerbit

Pusat Aktivitas memungkinkan kontrol terperinci atas penerbit peristiwa melalui kebijakan penerbit. Kebijakan penerbit adalah fitur run-time yang dirancang untuk memfasilitasi sejumlah besar penerbit peristiwa mandiri. Dengan kebijakan penerbit, setiap penerbit menggunakan pengidentifikasi uniknya sendiri saat menerbitkan peristiwa ke pusat aktivitas, menggunakan mekanisme berikut:

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

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

Ambil

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

Gambar yang menangkap pengambilan data Event Hubs ke Azure Storage atau Azure Data Lake Storage

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

Gambar yang menunjukkan struktur data yang diambil

Catatan

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.

Partisi

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.

Event Hubs

Sebuah partisi dapat dianggap sebagai "log penerapan". Partisi menyimpan data peristiwa yang berisi isi peristiwa, tas properti yang ditentukan pengguna yang menjelaskan peristiwa, metadata seperti offsetnya di partisi, nomornya dalam urutan aliran, dan tanda waktu sisi layanan yang menerimanya.

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, dan mempertahankan log yang mempertahankan urutan peristiwa mengharuskan peristiwa ini disimpan bersama di penyimpanan yang mendasarinya serta replikanya, dan menghasilkan batas throughput untuk log. Partisi memungkinkan beberapa log paralel digunakan untuk event hub yang sama, dan oleh karena itu mengalikan kapasitas throughput IO mentah yang tersedia.
  • Aplikasi Anda sendiri harus dapat mengikuti pemrosesan volume peristiwa yang dikirim ke hub peristiwa. Proses ini mungkin rumit dan membutuhkan kapasitas pemrosesan paralel yang substansial, berskala. Kapasitas satu proses untuk menangani peristiwa terbatas, sehingga Anda memerlukan beberapa proses. Partisi adalah cara solusi Anda memberi makan proses tersebut dan memastikan bahwa setiap peristiwa memiliki pemilik pemrosesan yang jelas.

Jumlah partisi

Jumlah partisi ditentukan pada saat membuat hub peristiwa. Partisi harus antara 1 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 partisi sebanyak yang Anda harapkan yang diperlukan selama beban puncak aplikasi Anda untuk hub peristiwa tertentu. Anda tidak dapat mengubah jumlah partisi untuk hub kejadian setelah pembuatannya kecuali untuk hub kejadian di kluster khusus dan tingkat premium. Jumlah partisi untuk hub peristiwa di kluster Azure Event Hubs khusus dapat ditingkatkan setelah hub peristiwa dibuat, tetapi distribusi aliran di seluruh partisi akan berubah saat selesai sebagai pemetaan kunci partisi ke perubahan partisi, jadi Anda harus berusaha keras untuk menghindari perubahan tersebut jika urutan relatif peristiwa penting dalam 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 preservasi pesanan mutlak di semua peristiwa atau hanya beberapa sub-aliran, Anda mungkin tidak dapat memanfaatkan partisi dalam jumlah banyak. Juga, partisi dalam jumlah banyak membuat sisi pemrosesan lebih kompleks.

Tidak masalah berapa banyak partisi yang ada di hub peristiwa 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, hub peristiwa tingkat standar dengan 32 partisi atau dengan 1 partisi dikenakan biaya yang sama persis ketika namespace diatur ke kapasitas 1 TU. Selain itu, Anda dapat menskalakan TU atau PU pada namespace atau CU kluster khusus Anda terlepas dari jumlah partisi.

Karena partisi adalah mekanisme organisasi data yang memungkinkan Anda menerbitkan dan mengonsumsi data secara paralel, sebaiknya seimbangkan unit penskalaan (TU, PU, atau CU) dan partisi untuk mencapai skala yang optimal. Secara umum, kami menyarankan pengguna untuk mempertahankan throughput maksimum 1 MB/dtk per partisi dan memilih jumlah partisi agar sesuai dengan throughput maksimum yang ingin Anda tangani. Misalnya, jika kasus penggunaan Anda memerlukan 20 MB/dtk, disarankan untuk memilih setidaknya 20 partisi untuk mencapai throughput yang optimal.

Namun, jika Anda memiliki model di mana aplikasi memiliki afinitas ke partisi tertentu, meningkatkan jumlah partisi mungkin 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 algoritme hash, yang membuat penetapan partisi. Jika Anda tidak menentukan kunci partisi saat menerbitkan peristiwa, maka penetapan 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.

Catatan

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

Token SAS

Pusat Aktivitas menggunakan Tanda Tangan Akses Bersama, yang tersedia di tingkat namespace layanan dan pusat aktivitas. Token SAS dihasilkan dari kunci SAS dan merupakan hash SHA dari URL, dikodekan dalam format tertentu. Event Hubs dapat membuat ulang hash dengan menggunakan nama kunci (kebijakan) dan token dan dengan demikian mengautentikasi pengirim. Biasanya, token SAS untuk penerbit peristiwa dibuat hanya dengan hanya mengirim hak istimewa di pusat aktivitas 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 Bus Layanan.

Konsumen peristiwa

Setiap entitas yang membaca data peristiwa pusat kejadian konsumer peristiwa. Semua konsumen Pusat Aktivitas terhubung melalui sesi AMQP 1.0 dan peristiwa dikirimkan melalui sesi saat tersedia. Klien tidak perlu melakukan polling untuk ketersediaan data.

Grup konsumen

Mekanisme publikasi/berlangganan Pusat Aktivitas diaktifkan melalui grup konsumen. Grup konsumen adalah tampilan (status, posisi, atau offset) dari seluruh pusat aktivitas. Grup konsumen memungkinkan beberapa aplikasi yang mengonsumsi untuk memiliki tampilan terpisah dari aliran peristiwa, dan untuk membaca aliran secara mandiri dengan kecepatan mereka sendiri dengan offset mereka sendiri.

Dalam arsitektur pemrosesan aliran, setiap aplikasi hilir setara dengan grup konsumen. Jika Anda ingin menulis data peristiwa ke penyimpanan jangka panjang, maka aplikasi penulis penyimpanan adalah grup konsumen. Pemrosesan peristiwa yang kompleks kemudian dapat dilakukan oleh kelompok konsumen lain yang terpisah. Anda hanya dapat mengakses partisi melalui grup konsumen. Grup konsumen default di hub kejadian selalu tersedia, dan Anda dapat membuat hingga jumlah maksimal grup konsumen untuk tingkat harga yang sesuai.

Ada maksimal 5 pembaca yang aktif bersamaan pada suatu partisi untuk satu grup konsumen; namun disarankan bahwa hanya ada satu penerima aktif pada satu partisi per grup konsumen. Dalam satu partisi, setiap pembaca menerima semua kejadian. Jika Anda memiliki beberapa pembaca pada partisi yang sama, maka Anda memproses kejadian duplikat. Anda perlu menangani ini dalam kode Anda, yang mungkin tidak mudah. Namun, ini adalah pendekatan yang valid dalam beberapa skenario.

Beberapa klien yang ditawarkan oleh Azure SDK adalah agen konsumen cerdas yang secara otomatis mengelola detail memastikan bahwa setiap partisi memiliki pembaca tunggal dan bahwa semua partisi untuk pusat aktivitas sedang dibaca. Ini memungkinkan kode Anda untuk fokus pada pemrosesan peristiwa yang dibaca dari pusat aktivitas 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 pengaliran Azure Event Hubs:

Arsitektur Pusat Aktivitas

Offset aliran

Offset adalah posisi peristiwa dalam partisi. Anda dapat menganggap offset sebagai kursor sisi klien. Offset adalah numbering byte dari peristiwa tersebut. Offset ini memungkinkan konsumen peristiwa (pembaca) untuk menentukan titik dalam aliran peristiwa dari mana mereka ingin mulai membaca peristiwa. Anda dapat menentukan offset sebagai cap waktu atau sebagai nilai pengimbangan. Konsumen bertanggung jawab untuk menyimpan nilai offset mereka sendiri di luar layanan Pusat Aktivitas. Dalam partisi, setiap peristiwa menyertakan offset.

Offset partisi

Titik pemeriksaan

Titik pemeriksaan adalah proses di mana pembaca menandai atau melakukan posisi mereka dalam urutan peristiwa partisi. Titik pemeriksaan adalah tanggung jawab konsumen dan terjadi berbasis partisi dalam kelompok konsumen. Tanggung jawab ini berarti bahwa untuk setiap kelompok konsumen, setiap pembaca partisi harus melacak posisinya saat ini di aliran peristiwa, dan dapat menginformasikan layanan ketika menganggap aliran data selesai.

Jika pembaca memutuskan sambungan dari partisi, ketika menghubungkannya kembali, ia mulai membaca di titik pemeriksaan yang sebelumnya dikirimkan oleh pembaca terakhir partisi dalam kelompok konsumen itu. Ketika pembaca terhubung, itu menyalurkan offset ke pusat aktivitas untuk menentukan lokasi untuk mulai membaca. Dengan cara ini, Anda dapat menggunakan titik pemeriksaan untuk menandai peristiwa sebagai "lengkap" oleh aplikasi hilir, dan untuk memberikan ketahanan jika kegagalan dengan pembaca yang menjalankan komputer yang berbeda terjadi. Anda dapat kembali ke data yang lebih lama dengan menentukan offset yang lebih rendah dari proses titik pemeriksaan ini. Melalui mekanisme ini, titik pemeriksaan memungkinkan ketahanan kegagalan dan pemutaran ulang aliran peristiwa.

Penting

Offset disediakan oleh layanan Pusat Aktivitas. Titik pemeriksaan saat kejadian diproses adalah tanggung jawab konsumen.

Catatan

Jika Anda menggunakan Azure Blob Storage sebagai penyimpanan titik pemeriksaan di lingkungan yang mendukung versi SDK Storage Blob yang berbeda dari yang biasanya tersedia di Azure, Anda harus menggunakan kode untuk mengubah versi API layanan Storage ke versi tertentu yang didukung oleh lingkungan tersebut. Misalnya, jika Anda menjalankan Azure Event Hubs di Azure Stack Hub versi 2002, versi tertinggi yang tersedia untuk layanan Storage adalah versi 2017-11-09. Dalam hal ini, Anda perlu menggunakan kode untuk menargetkan versi API layanan Storage ke 2017-11-09. Untuk contoh tentang cara menargetkan versi API Storage tertentu, lihat sampel di GitHub ini:

Tugas umum konsumen

Semua konsumen Pusat Aktivitas terhubung melalui sesi AMQP 1.0, saluran komunikasi dua arah yang menyadari status. Setiap partisi memiliki sesi AMQP 1.0 yang memfasilitasi pengangkutan peristiwa yang dipisahkan oleh partisi.

Menyambung ke partisi

Saat menghubung ke partisi, praktik umumnya untuk menggunakan mekanisme penyewaan untuk mengoordinasi koneksi pembaca ke partisi tertentu. Dengan cara ini, memungkinkan bagi setiap partisi dalam kelompok konsumen untuk hanya memiliki satu pembaca aktif. Titik pemeriksaan, menyewa, dan mengelola pembaca disederhanakan dengan menggunakan klien dalam SDK Pusat Aktivitas, yang bertindak sebagai agen konsumen cerdas. Ini adalah:

Membaca peristiwa

Setelah sesi AMQP 1.0 dan tautan dibuka untuk partisi tertentu, peristiwa dikirimkan ke klien AMQP 1.0 oleh layanan Pusat Aktivitas. 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 kejadian:

  • Offset
  • Nomor urut
  • Isi
  • Properti pengguna
  • Properti sistem

Anda bertanggung jawab untuk mengelola offset.

Grup aplikasi

Grup aplikasi adalah set aplikasi klien yang terhubung ke namespace layanan Azure Event Hubs yang berbagi kondisi identifikasi unik seperti konteks keamanan - kebijakan akses bersama atau ID aplikasi Azure Active Directory (Azure AD).

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.

Langkah berikutnya

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