Menskalakan aplikasi pemrosesan Anda

  • 3 menit

Untuk menskalakan aplikasi pemrosesan kejadian Anda, Anda dapat menjalankan beberapa instans aplikasi dan menyeimbangkan muatan di antara instans tersebut. Di versi yang lebih lama, EventProcessorHost memungkinkan Anda menyeimbangkan muatan antara beberapa instans program Anda dan kejadian titik pemeriksaan saat menerima. Di versi yang lebih baru (5.0 dan seterusnya), EventProcessorClient (.NET dan Java), atau EventHubConsumerClient (Python dan JavaScript) memungkinkan Anda melakukan hal yang sama.

Catatan

Kunci untuk menskalakan Azure Event Hubs adalah gagasan konsumen yang dipartisi. Berbeda dengan pola konsumen yang bersaing, pola konsumen yang dipartisi memungkinkan skala tinggi dengan menghapus penyempitan ketidakcocokan dan memfasilitasi paralelisme ujung ke ujung.

Contoh skenario

Sebagai contoh skenario, pertimbangkan perusahaan keamanan rumah yang memantau 100.000 rumah. Tiap menit, perusahaan mendapatkan data dari berbagai sensor seperti pendeteksi gerakan, sensor pintu/jendela terbuka, pendeteksi pecahan kaca, dan sebagainya, yang dipasang di tiap rumah. Perusahaan menyediakan situs web bagi penghuni untuk memantau aktivitas rumah mereka hampir secara langsung.

Tiap sensor mendorong data ke pusat aktivitas. Pusat aktivitas dikonfigurasi dengan 16 partisi. Pada sisi konsumsi, Anda memerlukan mekanisme yang dapat membaca peristiwa ini, mengonsolidasikannya, dan membuang agregat ke blob penyimpanan, yang kemudian diproyeksikan ke halaman web yang mudah digunakan.

Saat merancang konsumen di lingkungan terdistribusi, skenario harus menangani persyaratan berikut:

  • Skala: Buat beberapa konsumen, dengan tiap konsumen mengambil kepemilikan membaca dari beberapa partisi Azure Event Hubs.
  • Load balance: Tingkatkan atau kurangi konsumen secara dinamis. Misalnya, ketika jenis sensor baru (misalnya, pendeteksi karbon monoksida) ditambahkan ke tiap rumah, jumlah peristiwa meningkat. Dalam kasus ini, operator (manusia) meningkatkan jumlah instans konsumen. Kemudian, kumpulan konsumen dapat menyeimbangkan kembali jumlah partisi yang mereka miliki, untuk berbagi muatan dengan konsumen yang baru ditambahkan.
  • Melanjutkan kegagalan tanpa gangguan: Jika konsumen (konsumen A) gagal (misalnya, komputer virtual yang meng-hosting konsumen tiba-tiba crash), konsumen lain dapat mengambil partisi yang dimiliki oleh konsumen A dan melanjutkan. Selain itu, titik kelanjutan, yang disebut titik pemeriksaan atau offset, harus berada di titik yang tepat tempat konsumen A gagal, atau sedikit sebelumnya.
  • Menggunakan kejadian: Meskipun tiga poin sebelumnya menangani manajemen konsumen, harus ada kode untuk menggunakan kejadian dan melakukan sesuatu yang berguna dengan kode tersebut. Misalnya, agregasi dan unggah ke penyimpanan blob.

Prosesor aktivitas atau klien konsumen

Anda tidak perlu membangun solusi Anda sendiri untuk memenuhi persyaratan ini. SDK Azure Event Hubs menyediakan fungsionalitas ini. Di SDK .NET atau Java, Anda menggunakan klien prosesor peristiwa (EventProcessorClient), dan di SDK Python serta JavaScript, Anda menggunakan (EventHubConsumerClient).

Untuk sebagian besar skenario produksi, sebaiknya gunakan klien prosesor peristiwa untuk membaca dan memproses acara. Klien prosesor aktivitas dapat bekerja secara kooperatif dalam konteks grup konsumen untuk pusat aktivitas tertentu. Klien akan secara otomatis mengelola distribusi dan penyeimbangan pekerjaan saat instans tersedia atau tidak tersedia untuk grup.

Pelacakan kepemilikan partisi

Instans prosesor aktivitas biasanya memiliki dan memproses kejadian dari satu atau beberapa partisi. Kepemilikan partisi didistribusikan secara merata di antara semua instans prosesor aktivitas aktif yang terkait dengan pusat aktivitas dan kombinasi grup konsumen.

Tiap prosesor aktivitas diberikan pengidentifikasi unik dan mengeklaim kepemilikan partisi dengan menambahkan atau memperbarui entri di penyimpanan titik pemeriksaan. Semua instans prosesor peristiwa berkomunikasi dengan penyimpanan ini secara berkala untuk memperbarui status pemrosesannya sendiri dan untuk mempelajari tentang instans aktif lainnya. Data ini selanjutnya digunakan untuk menyeimbangkan muatan di antara prosesor aktif.

Terima pesan

Saat membuat prosesor peristiwa, Anda menentukan fungsi yang memproses peristiwa dan kesalahan. Tiap panggilan ke fungsi yang memproses kejadian memberikan satu kejadian dari partisi tertentu. Anda bertanggung jawab untuk menangani kejadian ini. Jika Anda ingin memastikan konsumen memproses tiap pesan setidaknya sekali, Anda perlu menulis kode Anda sendiri dengan logika coba lagi. Namun, berhati-hatilah dengan pesan racun.

Sebaiknya Anda melakukan hal-hal yang relatif cepat. Artinya, lakukan pemrosesan sesedikit mungkin. Jika Anda perlu menulis ke penyimpanan dan melakukan beberapa perutean, lebih baik menggunakan dua grup konsumen dan memiliki dua prosesor aktivitas.

Checkpointing

Titik pemeriksaan adalah proses untuk prosesor aktivitas menandai atau menerapkan posisi kejadian terakhir yang berhasil diproses dalam partisi. Menandai titik pemeriksaan biasanya dilakukan dalam fungsi yang memproses kejadian dan berlangsung per partisi dalam grup konsumen.

Jika koneksi prosesor aktivitas terputus dari partisi, instans lain dapat melanjutkan pemrosesan partisi di titik pemeriksaan yang sebelumnya dilakukan oleh prosesor terakhir partisi tersebut di grup konsumen tersebut. Ketika prosesor terhubung, prosesor meneruskan offset ke pusat aktivitas untuk menentukan lokasi untuk mulai membaca. Dengan cara ini, Anda dapat menggunakan titik pemeriksaan untuk menandai kejadian sebagai "selesai" oleh aplikasi hilir dan untuk memberikan ketahanan ketika prosesor aktivitas berkurang. Anda dapat kembali ke data yang lebih lama dengan menentukan offset yang lebih rendah dari proses titik pemeriksaan ini.

Keselamatan utas dan instans prosesor

Secara default, fungsi yang memproses kejadian secara berurutan dipanggil untuk partisi tertentu. Kejadian dan panggilan berikutnya ke fungsi ini dari partisi yang sama mengantre di belakang layar karena pompa kejadian terus berjalan di latar belakang pada utas lain. Kejadian dari partisi yang berbeda dapat diproses secara bersamaan dan status berbagi apa pun yang diakses di seluruh partisi harus disinkronkan.