Bagikan melalui


Penskalaan dengan Event Hubs

Ada dua faktor yang memengaruhi penskalakan dengan Azure Event Hubs.

  • Unit throughput (tingkat standar) atau unit pemrosesan (tingkat premium)
  • Partisi

Unit throughput

Kapasitas throughput pusat aktivitas dikendalikan oleh unit throughput. Unit throughput adalah unit kapasitas yang telah dibeli sebelumnya. Satu unit throughput memungkinkan Anda:

  • Ingress: Hingga 1 MB per detik atau 1.000 peristiwa per detik (mana yang lebih dulu).
  • Egress: Hingga 2 MB per detik atau 4.096 peristiwa per detik.

Di luar kapasitas unit throughput yang dibeli, ingress dibatasi dan Azure Event Hubs melempar ServerBusyException. Egress tidak menghasilkan pengecualian pembatasan, tetapi masih terbatas pada kapasitas unit throughput yang dibeli. Jika Anda menerima pengecualian tingkat penerbitan atau mengharapkan untuk melihat proses keluar yang lebih tinggi, pastikan untuk memeriksa berapa banyak unit throughput yang telah Anda beli untuk namespace layanan. Anda dapat mengelola unit throughput pada halaman Skala namespace layanan di portal Azure. Anda juga dapat mengelola unit throughput secara terprogram menggunakan API Event Hubs.

Unit throughput telah dibeli sebelumnya dan ditagih per jam. Setelah dibeli, unit throughput ditagih selama minimal satu jam. Hingga 40 unit throughput dapat dibeli untuk namespace layanan Event Hubs dan dibagikan di semua event hubs di namespace tersebut.

FitureInflate Otomatis Azure Event Hubs akan secara otomatis meningkatkan skala dengan menaikkan jumlah unit throughput untuk memenuhi kebutuhan penggunaan. Meningkatkan unit throughput mencegah skenario pembatasan, di mana:

  • Tingkat masuk data melebihi unit throughput yang ditetapkan.
  • Tingkat permintaan keluar data melebihi unit throughput yang ditetapkan.

Layanan Event Hubs meningkatkan throughput saat beban meningkat melampaui ambang minimum, tanpa permintaan yang gagal dengan kesalahan ServerBusy.

Untuk informasi selengkapnya tentang fitur autoinflate, lihat Menskalakan unit throughput secara otomatis.

Unit pemrosesan

Azure Event Hubs Premium memberikan performa yang unggul dan isolasi yang lebih baik dalam lingkungan PaaS multipenyewa terkelola. Sumber daya dalam tingkat Premium diisolasi di tingkat CPU dan memori sehingga setiap beban kerja penyewa berjalan dalam isolasi. Kontainer sumber daya ini disebut Unit Pemrosesan (PU). Anda dapat membeli 1, 2, 4, 8 atau 16 unit pemrosesan untuk setiap namespace layanan Azure Event Hubs Premium.

Seberapa banyak Anda dapat menelan dan mengalirkan dengan unit pemrosesan tergantung pada berbagai faktor seperti produsen Anda, konsumen, tingkat kemampuan Anda untuk menelan dan memproses, dan banyak lagi faktor lainnya.

Misalnya, namespace Layanan Premium Azure Event Hubs dengan satu PU dan satu hub peristiwa (100 partisi) dapat kira-kira menawarkan kapasitas inti ingress ~5-10 MB/dtk dan egress 10-20 MB/dtk untuk beban kerja AMQP atau Kafka.

Untuk mempelajari tentang mengonfigurasi PU untuk namespace layanan tingkat premium, lihat Mengonfigurasi unit pemrosesan.

Catatan

Untuk mempelajari selengkapnya tentang kuota dan batasan, lihat Azure Event Hubs - kuota dan batasan.

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.

Image that shows an event hub with a few partitions.

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 that displays the older to newer sequence of events.

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.

Langkah berikutnya

Anda dapat mempelajari selengkapnya tentang Azure Event Hubs dengan mengunjungi tautan berikut: