Bagikan melalui

Aplikasi tepi yang sangat tersedia untuk Operasi Azure IoT

Membuat aplikasi yang sangat tersedia menggunakan broker MQTT melibatkan pertimbangan yang cermat tentang jenis sesi, kualitas layanan (QoS), pengakuan pesan, pemrosesan pesan paralel, retensi pesan, dan langganan bersama. Broker MQTT memiliki broker dan penyimpanan pesan dalam memori terdistribusi yang menyediakan retensi pesan dan manajemen status bawaan dengan semantik MQTT.

Bagian berikut menjelaskan pengaturan dan fitur yang berkontribusi pada kehilangan pesan yang kuat, nol, dan aplikasi terdistribusi.

Kualitas layanan (QoS)

Penerbit dan pelanggan harus menggunakan QoS-1 untuk menjamin pengiriman pesan setidaknya sekali. Broker MQTT menyimpan dan mengirimkan ulang pesan sampai menerima pengakuan (ACK) dari penerima, memastikan tidak ada pesan yang hilang selama transmisi.

Jenis sesi dan bendera Bersih-Sesi

Untuk memastikan tidak ada pesan yang hilang, atur bendera clean-start ke false saat menyambungkan ke broker MQTT. Pengaturan ini memberi tahu broker untuk mempertahankan status sesi untuk klien, mempertahankan langganan, dan pesan yang tidak diakui antar koneksi. Jika klien terputus dan kemudian terhubung kembali, klien melanjutkan dari tempat yang ditinggalkannya, menerima pesan QoS-1 yang tidak diakui melalui coba lagi pengiriman pesan. Jika dikonfigurasi, broker MQTT kedaluwarsa sesi klien jika klien tidak terhubung kembali dalam Interval Kedaluwarsa Sesi Defaultnya adalah satu hari.

Receive-Max dalam aplikasi multithreaded

Aplikasi multithreaded harus menggunakan receive-max (65.535 maks) untuk memproses pesan secara paralel dan menerapkan kontrol alur. Pengaturan ini mengoptimalkan pemrosesan pesan dengan memungkinkan beberapa utas bekerja pada pesan secara bersamaan dan tanpa broker membebani aplikasi dengan tingkat pesan tinggi di atas kapasitas aplikasi. Setiap utas dapat memproses pesan secara independen dan mengirim pengakuannya setelah selesai. Praktik umumnya adalah mengonfigurasi penerimaan maks secara proporsional dengan jumlah utas yang digunakan aplikasi.

Mengakui pesan

Ketika aplikasi pelanggan mengirimkan pengakuan untuk pesan QoS-1, aplikasi tersebut mengambil kepemilikan pesan. Setelah menerima pengakuan untuk pesan QoS-1, broker MQTT berhenti melacak pesan untuk aplikasi dan topik tersebut. Transfer kepemilikan yang tepat memastikan pelestarian pesan jika terjadi masalah pemrosesan atau crash aplikasi. Jika aplikasi ingin melindunginya dari crash aplikasi, aplikasi tidak boleh mengambil kepemilikan sebelum berhasil menyelesaikan pemrosesannya pada pesan tersebut. Aplikasi yang berlangganan broker MQTT harus menunda pengakuan pesan hingga pemrosesan selesai hingga nilai maksimal penerimaan dengan maksimum 65.535. Ini mungkin termasuk menyampaikan pesan, atau turunan pesan, ke broker MQTT untuk pengiriman lebih lanjut.

Retensi pesan dan perilaku broker

Broker mempertahankan pesan sampai menerima pengakuan dari pelanggan, memastikan tidak ada pesan yang hilang. Perilaku ini menjamin bahwa bahkan jika aplikasi pelanggan mengalami crash atau kehilangan konektivitas untuk sementara, pesan tidak hilang dan dapat diproses setelah aplikasi tersambung kembali. Pesan broker MQTT mungkin kedaluwarsa jika dikonfigurasi oleh Message-Expiry-Interval dan pelanggan tidak menggunakan pesan.

Pesan yang dipertahankan

Pesan yang dipertahankan mempertahankan status aplikasi sementara, seperti status atau nilai terbaru untuk topik tertentu. Ketika klien baru berlangganan topik, klien baru menerima pesan terakhir yang dipertahankan, memastikannya memiliki informasi terbaru.

Tetap Hidup

Untuk memastikan ketersediaan tinggi jika terjadi kesalahan atau penurunan koneksi, atur interval tetap aktif yang sesuai untuk komunikasi server klien. Selama periode diam, klien mengirim PINGREQ, menunggu PINGRESP. Jika tidak ada respons, terapkan logika sambungkan ulang otomatis di klien untuk membuat ulang koneksi. Sebagian besar klien seperti Paho memiliki logika coba lagi bawaan. Karena broker MQTT toleran terhadap kesalahan, koneksi ulang berhasil jika setidaknya ada dua instans broker sehat frontend dan backend.

Konsistensi akhir dengan langganan QoS-1

Langganan MQTT dengan QoS-1 memastikan konsistensi akhir di seluruh instans aplikasi yang identik dengan berlangganan topik bersama. Saat pesan diterbitkan, instans menerima dan mereplikasi data dengan pengiriman setidaknya sekali. Instans harus menangani duplikat dan mentolerir inkonsistensi sementara hingga data disinkronkan.

Langganan bersama

Langganan bersama memungkinkan penyeimbangan beban di beberapa instans aplikasi yang sangat tersedia. Alih-alih setiap pelanggan menerima salinan setiap pesan, pesan didistribusikan secara merata di antara pelanggan. Broker MQTT saat ini hanya mendukung algoritma round robin untuk mendistribusikan pesan yang memungkinkan aplikasi untuk meluaskan skala. Kasus penggunaan umum adalah menyebarkan beberapa pod menggunakan Kubernetes ReplicaSet yang semuanya berlangganan broker MQTT menggunakan filter topik yang sama dalam langganan bersama.

Penyimpanan status

Penyimpanan status adalah HashMap dalam memori yang direplikasi untuk mengelola status pemrosesan aplikasi. Tidak seperti etcd, misalnya, penyimpanan status memprioritaskan throughput kecepatan tinggi, penskalaan horizontal, dan latensi rendah melalui struktur data dalam memori, partisi, dan replikasi rantai. Ini memungkinkan aplikasi untuk menggunakan penyimpanan status yang terdistribusi sifat dan toleransi kesalahan sambil mengakses status yang konsisten dengan cepat di seluruh instans. Untuk menggunakan penyimpanan kunci-nilai yang terintegrasi, yang disediakan oleh broker terdistribusi:

  • Terapkan operasi penyimpanan dan pengambilan sementara menggunakan API penyimpanan nilai kunci broker, memastikan penanganan kesalahan dan konsistensi data yang tepat. Status sementara adalah penyimpanan data berumur pendek yang digunakan dalam pemrosesan stateful untuk akses cepat ke hasil perantara atau metadata selama komputasi real-time. Dalam konteks aplikasi HA, status sementara membantu memulihkan status aplikasi di antara crash. Ini dapat ditulis ke disk tetapi tetap bersifat sementara, dibandingkan dengan penyimpanan dingin yang dirancang untuk penyimpanan jangka panjang dari data yang jarang diakses.

  • Gunakan penyimpanan status untuk berbagi status, penembolokan, konfigurasi, atau data penting lainnya di antara beberapa instans aplikasi, memungkinkan mereka untuk menjaga tampilan data yang konsisten.

Daftar periksa untuk mengembangkan aplikasi yang sangat tersedia

  • Pilih pustaka klien MQTT yang sesuai untuk bahasa pemrograman Anda. Klien harus mendukung MQTT v5. Gunakan pustaka berbasis C atau Rust jika aplikasi Anda sensitif terhadap latensi.
  • Konfigurasikan pustaka klien untuk terhubung ke broker MQTT dengan bendera sesi bersih diatur ke false dan tingkat QoS yang diinginkan (QoS-1).
  • Tentukan nilai yang sesuai untuk kedaluwarsa sesi, kedaluwarsa pesan, dan interval tetap hidup.
  • Terapkan logika pemrosesan pesan untuk aplikasi pelanggan, termasuk mengirim pengakuan ketika pesan berhasil dikirim atau diproses.
  • Untuk aplikasi multithreaded, konfigurasikan parameter penerimaan maks untuk mengaktifkan pemrosesan pesan paralel.
  • Gunakan pesan yang dipertahankan untuk menjaga status aplikasi sementara.
  • Gunakan penyimpanan status terdistribusi untuk mengelola status aplikasi sementara.
  • Terapkan langganan bersama untuk mendistribusikan pesan secara merata di antara beberapa instans aplikasi, memungkinkan penskalaan yang efisien.

Konten terkait

  • Last updated on