Panduan dan rekomendasi untuk Reliable Collections di Azure Service Fabric

  • Artikel

Bagian ini menyediakan panduan untuk menggunakan Reliable State Manager dan Reliable Collections. Tujuannya adalah untuk membantu pengguna menghindari perangkap umum.

Guildeline Reliable Collection

Panduan tersebut disusun sebagai rekomendasi sederhana yang diawali dengan istilah Lakukan, Pertimbangkan, Hindari, dan Jangan.

  • Jangan mengubah objek jenis kustom yang dikembalikan oleh operasi baca (misalnya, TryPeekAsync atau TryGetValueAsync). Reliable Collections, sama seperti Concurrent Collections, mengembalikan referensi ke objek dan bukan salinan.
  • Lakukan salinan mendalam objek yang dikembalikan dari jenis kustom sebelum memodifikasinya. Karena struct dan jenis bawaan adalah pass-by-value, Anda tidak perlu melakukan salinan mendalam padanya kecuali berisi bidang atau properti yang diketik referensi yang ingin Anda ubah.
  • Jangan gunakan TimeSpan.MaxValue untuk waktu habis. Waktu habis harus digunakan untuk mendeteksi kebuntuan.
  • Jangan menggunakan transaksi setelah dilakukan, dibatalkan, atau dibuang.
  • Jangan gunakan enumerasi di luar cakupan transaksi tempat transaksi dibuat.
  • Jangan membuat transaksi dalam pernyataan using transaksi lain karena dapat menyebabkan kebuntuan.
  • Jangan membuat keadaan yang dapat diandalkan dengan IReliableStateManager.GetOrAddAsync dan menggunakan keadaan yang dapat diandalkan dalam transaksi yang sama. Ini menghasilkan InvalidOperationException.
  • Pastikan implementasi IComparable<TKey> Anda benar. Sistem ini mengambil ketergantungan IComparable<TKey> untuk menggabungkan titik pemeriksaan dan baris.
  • Gunakan kunci Perbarui saat membaca item dengan niat untuk memperbaruinya untuk mencegah kelas kebuntuan tertentu.
  • Pertimbangkan untuk menyimpan jumlah Reliable Collections per partisi menjadi kurang dari 1000. Lebih suka Reliable Collections dengan lebih banyak item daripada Reliable Collections dengan lebih sedikit item.
  • Pertimbangkan untuk menyimpan item Anda (misalnya, TKey + TValue untuk Reliable Dictionary) di bawah 80 KByte: lebih kecil semakin baik. Ini mengurangi jumlah penggunaan Heap Objek Besar serta persyaratan IO disk dan jaringan. Seringkali, ini mengurangi replikasi data duplikat ketika hanya satu bagian kecil dari nilai yang diperbarui. Cara umum untuk mencapainya dalam Reliable Dictionary, adalah dengan memecah baris Anda menjadi beberapa baris.
  • Pertimbangkan untuk menggunakan fungsionalitas pencadangan dan pemulihan untuk memiliki pemulihan bencana.
  • Hindari pencampuran operasi entitas tunggal dan operasi multi-entitas (misalnya GetCountAsync, CreateEnumerableAsync) dalam transaksi yang sama karena tingkat isolasi yang berbeda.
  • Tangani InvalidOperationException. Transaksi pengguna dapat dibatalkan oleh sistem karena berbagai alasan. Misalnya, ketika Reliable State Manager mengubah perannya dari Primer atau ketika transaksi yang berjalan lama memblokir pemotongan log transaksional. Dalam kasus tersebut, pengguna mungkin menerima InvalidOperationException yang menunjukkan bahwa transaksi mereka telah dihentikan. Dengan asumsi, penghentian transaksi tidak diminta oleh pengguna, cara terbaik untuk menangani pengecualian ini adalah dengan membuang transaksi, periksa apakah token pembatalan telah diberi sinyal (atau peran replika telah diubah), dan jika tidak membuat transaksi baru dan mencoba kembali.
  • Jangan menerapkan operasi paralel atau bersamaan dalam transaksi. Hanya satu operasi utas pengguna yang didukung dalam transaksi. Jika tidak, itu akan menyebabkan kebocoran memori dan masalah kunci.
  • Pertimbangkan untuk membuang transaksi sesegera mungkin setelah penerapan selesai (terutama jika menggunakan ConcurrentQueue).
  • Jangan melakukan kode pemblokiran di dalam transaksi.
  • Ketika string digunakan sebagai kunci untuk kamus yang andal, urutan pengurutan menggunakan string default comparer CurrentCulture. Perhatikan bahwa urutan pengurutan CurrentCulture berbeda dari pembanding string Ordinal.
  • Jangan buang atau batalkan transaksi yang dilakukan. Ini tidak didukung dan dapat menabrak proses host.
  • Pastikan urutan operasi kamus yang berbeda tetap sama untuk semua transaksi bersamaan saat membaca atau menulis beberapa kamus untuk menghindari kebuntuan.

Berikut beberapa hal yang perlu diperhatikan:

  • Waktu habis default adalah selama 4 detik untuk semua API Reliable Collection. Sebagian besar pengguna harus menggunakan waktu habis default.
  • Token pembatalan default adalah CancellationToken.None di semua Reliable Collections API.
  • Parameter jenis kunci (TKey) untuk Reliable Dictionary harus diimplementasikan dengan benar GetHashCode() dan Equals(). Kunci harus tidak dapat diubah.
  • Untuk mencapai ketersediaan tinggi untuk Reliable Collections, setiap layanan harus memiliki setidaknya satu target dan ukuran replika set minimal 3.
  • Operasi baca pada sekunder dapat membaca versi yang tidak dilakukan kuorum. Ini berarti bahwa versi data yang dibaca dari satu sekunder mungkin mengalami kemajuan palsu. Baca dari Primer selalu stabil: tidak pernah bisa mengalami kemajuan palsu.
  • Keamanan/Privasi data yang disimpan oleh aplikasi Anda dalam kumpulan tepercaya merupakan keputusan Anda dan tunduk pada perlindungan yang disediakan oleh manajemen penyimpanan Anda; Mis. Enkripsi disk Sistem Operasi dapat digunakan untuk melindungi data Anda ketika data tidak aktif.
  • Enumerasi ReliableDictionary menggunakan struktur data yang diurutkan menurut kunci. Untuk membuat enumerasi efisien, penerapan ditambahkan ke hashtable sementara dan kemudian dipindahkan ke titik pemeriksaan pos struktur data utama yang diurutkan. Adds/Updates/Deletes memiliki runtime kasus terbaik O(1) dan runtime kasus terburuk O(log n), dalam kasus pemeriksaan validasi pada keberadaan kunci. Gets dapat berupa O(1) atau O(log n) tergantung apakah Anda membaca dari penerapan terbaru atau dari penerapan yang lebih lama.

Panduan tambahan untuk Reliable Collections yang volatil

Saat memutuskan untuk menggunakan koleksi yang dapat diandalkan yang volatil, pertimbangkan hal berikut:

  • ReliableDictionary memang memiliki dukungan yang volatil
  • ReliableQueue memang memiliki dukungan yang volatil
  • ReliableConcurrentQueue TIDAK memiliki dukungan yang volatil
  • Layanan bertahan TIDAK DAPAT dibuat volatil. Mengubah bendera HasPersistedState ke false mengharuskan membuat ulang seluruh layanan dari awal
  • Layanan volatil TIDAK DAPAT dibuat bertahan. Mengubah bendera HasPersistedState ke true mengharuskan membuat ulang seluruh layanan dari awal
  • HasPersistedState adalah konfigurasi tingkat layanan. Ini berarti bahwa SEMUA koleksi akan bertahan atau volatil. Anda tidak dapat mencampur koleksi yang volatil dan bertahan
  • Hilangnya kuorum dari partisi volatil mengakibatkan hilangnya data lengkap
  • Pencadangan dan pemulihan TIDAK tersedia untuk layanan yang volatil

Langkah berikutnya