Menyeimbangkan beban partisi di beberapa instans aplikasi Anda
Untuk menskalakan aplikasi pemrosesan peristiwa, Anda dapat menjalankan beberapa instans aplikasi dan memiliki beban yang seimbang di antara mereka sendiri. Dalam versi yang lebih lama dan tidak digunakan lagi, EventProcessorHost memungkinkan Anda menyeimbangkan beban antara beberapa instans program Anda dan peristiwa titik pemeriksaan saat menerima peristiwa. Di versi yang lebih baru (5.0 dan seterusnya), EventProcessorClient (.NET dan Java), atau EventHubConsumerClient (Python dan JavaScript) memungkinkan Anda melakukan hal yang sama. Model pengembangan dibuat lebih sederhana dengan menggunakan kejadian. Anda dapat berlangganan peristiwa yang Anda minati dengan mendaftarkan penanganan aktivitas. Jika Anda menggunakan versi lama pustaka klien, lihat panduan migrasi berikut: .NET, Java, Python, dan JavaScript.
Artikel ini menjelaskan skenario sampel untuk menggunakan beberapa instans aplikasi klien untuk membaca peristiwa dari pusat aktivitas. Ini juga memberi Anda detail tentang fitur klien prosesor peristiwa, yang memungkinkan Anda menerima peristiwa dari beberapa partisi sekaligus dan menyeimbangkan beban dengan konsumen lain yang menggunakan hub peristiwa dan grup konsumen 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 akhir konsumsi, Anda memerlukan mekanisme yang dapat membaca kejadian ini, mengonsolidasikannya (filter, agregat, dan sebagainya), dan menyimpan agregat ke blob penyimpanan, yang selanjutnya diproyeksikan ke halaman web yang mudah digunakan.
Aplikasi konsumen
Saat Anda 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.
- Mengonsumsi peristiwa: Meskipun tiga poin sebelumnya menangani manajemen konsumen, harus ada kode untuk mengonsumsi peristiwa dan melakukan sesuatu yang berguna dengannya. 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). Dalam versi lama SDK, host prosesor peristiwa (EventProcessorHost)lah yang mendukung fitur-fitur ini.
Untuk sebagian besar skenario produksi, sebaiknya gunakan klien prosesor peristiwa untuk membaca dan memproses acara. Klien prosesor dimaksudkan untuk memberikan pengalaman yang kuat untuk memproses kejadian di semua partisi pusat aktivitas dengan cara yang sesuai dan toleran terhadap kesalahan sambil menyediakan sarana untuk memantau kemajuannya. 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.
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. Instans baru dapat bergabung dengan kumpulan pemrosesan untuk meningkatkan skala. Ketika instans berkurang, baik karena kegagalan maupun untuk mengurangi skala, kepemilikan partisi ditransfer dengan lancar ke prosesor aktif lainnya.
Rekaman kepemilikan partisi di penyimpanan titik pemeriksaan terus melacak namespace layanan Azure Event Hubs, nama pusat aktivitas, grup konsumen, pengidentifikasi prosesor aktivitas (juga dikenal sebagai pemilik), ID partisi, dan waktu terakhir diubah.
| Ruang nama Azure Event Hubs | Nama pusat aktivitas | Grup konsumen | Pemilik | ID partisi | Waktu terakhir diubah |
|---|---|---|---|---|---|
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 3be3f9d3-9d9e-4c50-9491-85ece8334ff6 | 0 | 2020-01-15T01:22:15 |
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | f5cc5176-ce96-4bb4-bbaa-a0e3a9054ecf | 1 | 2020-01-15T01:22:17 |
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 72b980e9-2efc-4ca7-ab1b-ffd7bece8472 | 2 | 2020-01-15T01:22:10 |
| : | |||||
| : | |||||
| mynamespace.servicebus.windows.net | myeventhub | myconsumergroup | 844bd8fb-1f3a-4580-984d-6324f9e208af | 15 | 2020-01-15T01:22:00 |
Tiap instans prosesor aktivitas memperoleh kepemilikan partisi dan mulai memproses partisi dari titik pemeriksaan yang terakhir diketahui. Jika prosesor gagal (VM mati), instans lain mendeteksinya dengan melihat waktu terakhir diubah. Instans lain mencoba mendapatkan kepemilikan partisi yang sebelumnya dimiliki oleh instans yang tidak aktif. Penyimpanan titik pemeriksaan menjamin bahwa hanya salah satu instans yang berhasil mengklaim kepemilikan partisi. Jadi, pada titik waktu tertentu, paling banyak ada satu prosesor yang menerima kejadian dari partisi.
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.
Pos pemeriksaan
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.
Saat titik pemeriksaan dijalankan untuk menandai kejadian sebagai diproses, entri di penyimpanan titik pemeriksaan ditambahkan atau diperbarui dengan offset dan nomor urutan kejadian. Pengguna harus memutuskan frekuensi untuk memperbarui titik pemeriksaan. Memperbarui setelah setiap kejadian yang berhasil diproses dapat memiliki implikasi performa dan biaya karena memicu operasi tulis ke penyimpanan titik pemeriksaan yang mendasarinya. Selain itu, titik pemeriksaan tiap satu kejadian menunjukkan antrean pola pesan untuk antrean Azure Service Bus yang mungkin merupakan opsi yang lebih baik dibanding pusat aktivitas. Ide di balik Event Hubs adalah Anda mendapatkan pengiriman "setidaknya sekali" dalam skala besar. Dengan membuat sistem hilir Anda idempoten, mudah untuk memulihkan dari kegagalan atau menghidupkan ulang hasil tersebut dalam kejadian yang sama yang diterima beberapa kali.
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
Keselamatan utas dan instans prosesor
Secara default, fungsi yang memproses peristiwa dipanggil secara berurutan 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.
Langkah berikutnya
Lihat mulai cepat berikut ini: