Bagikan melalui

Fitur dan terminologi di Azure Event Hubs

  • Artikel

Azure Event Hubs adalah layanan pemrosesan peristiwa terskala 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 menyusun informasi dalam artikel gambaran umum, dan memberikan detail teknis serta implementasi tentang komponen dan fitur Pusat Aktivitas.

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 menampilkan namespace layanan Azure Event Hubs

Partitions

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 memperlihatkan hub peristiwa dengan beberapa partisi.

Partisi dapat dianggap sebagai log penerapan. Partisi menyimpan data peristiwa yang berisi informasi berikut:

  • Isi peristiwa
  • Tas properti yang ditentukan pengguna yang menjelaskan peristiwa
  • Metadata seperti offsetnya dalam partisi, jumlahnya dalam urutan aliran
  • Tanda waktu sisi layanan tempat tanda waktu 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. Mempertahankan log yang mempertahankan urutan peristiwa mengharuskan peristiwa ini disimpan bersama-sama dalam penyimpanan yang mendasarinya dan replikanya dan itu menghasilkan langit-langit throughput untuk log tersebut. Pemartisian memungkinkan beberapa log paralel digunakan untuk hub peristiwa yang sama dan karenanya mengalikan kapasitas throughput input-output (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 substansial, diskalakan. 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. 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 partisi sebanyak yang Anda harapkan yang diperlukan selama beban puncak aplikasi Anda untuk hub peristiwa tertentu. 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. Distribusi aliran di seluruh partisi akan berubah ketika dilakukan 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 pelestarian pesanan absolut di semua peristiwa 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 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, 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.

Karena partisi adalah mekanisme organisasi data yang memungkinkan Anda menerbitkan dan mengonsumsi data secara paralel. 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 merekomendasikan throughput maksimum 1 MB/dtk per partisi. Oleh karena itu, aturan praktis untuk menghitung jumlah partisi adalah membagi throughput maksimum yang diharapkan dengan 1 MB/dtk. Misalnya, jika kasus penggunaan Anda memerlukan 20 MB/dtk, kami sarankan Anda memilih setidaknya 20 partisi untuk mencapai throughput 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 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.

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 ID Microsoft Entra dengan token JWT yang dikeluarkan OAuth2 atau token Tanda Tangan Akses Bersama (SAS) khusus Pusat Aktivitas untuk mendapatkan akses penerbitan.

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 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 sebesar 1 MB, terlepas dari apakah itu kejadian tunggal atau batch. Peristiwa penerbitan yang lebih besar dari ambang batas ini ditolak.

Throughput Azure Event Hubs diskalakan dengan menggunakan partisi dan alokasi unit throughput. 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.

Diagram yang memperlihatkan bagaimana kunci partisi dipetakan ke partisi di hub peristiwa.

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 Peristiwa

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 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 satu hari (24 jam), peristiwa 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 streaming peristiwa tidak cocok untuk memainkan peran data lake atau arsip jangka panjang untuk sumber peristiwa.

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.

Tangkap

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.

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

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

Diagram memperlihatkan struktur data Avro 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.

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. Konsumen atau penerima menggunakan AMQP atau Apache Kafka untuk menerima peristiwa dari pusat aktivitas. Azure Event Hubs hanya mendukung model penarikan bagi konsumen untuk menerima peristiwa darinya. 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 Pusat Aktivitas diaktifkan melalui grup konsumen. Grup konsumen adalah pengelompokan logis konsumen yang membaca data dari pusat aktivitas atau topik Kafka. Ini memungkinkan beberapa aplikasi yang menggunakan untuk membaca data streaming yang sama di hub peristiwa secara independen dengan kecepatan mereka sendiri dengan offset mereka. 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 kejadian 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 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.

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 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 pengaliran 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 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.

Diagram yang memperlihatkan partisi dengan offset.

Checkpointing

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.

Ikuti rekomendasi ini saat 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 kontainer untuk hal lain, dan jangan gunakan akun penyimpanan untuk hal lain.
  • Akun penyimpanan harus berada di wilayah yang sama dengan aplikasi yang disebarkan berada. 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
  • Penerapan versi

Pemadatan log

Azure Event Hubs mendukung log peristiwa yang memadatkan untuk mempertahankan peristiwa terbaru dari 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 Pemadatan log.

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. Yaitu:

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 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 layanan 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 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 bagi konsumen untuk menerima peristiwa darinya. 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 layak.

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 berikutnya

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