Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Penanganan Pengecualian dan Mencoba Lagi
Membangun aplikasi yang kuat di Neptunus sering berarti mempersiapkan hal yang tidak terduga, terutama ketika menyangkut penanganan kesalahan yang dikembalikan oleh database. Salah satu tanggapan paling umum terhadap pengecualian sisi server adalah mencoba lagi operasi yang gagal. Meskipun logika coba ulang sangat penting untuk sistem yang tangguh, Anda perlu menyadari bahwa tidak semua kesalahan harus diperlakukan dengan cara yang sama. Alih-alih mengandalkan perilaku coba ulang umum, pendekatan yang bijaksana dapat membantu Anda membangun aplikasi yang lebih andal dan efisien.
Mengapa logika coba lagi penting
Logika coba ulang adalah komponen penting dari setiap aplikasi terdistribusi. Masalah sementara seperti ketidakstabilan jaringan, kendala sumber daya sementara, atau konflik modifikasi bersamaan dapat menyebabkan operasi gagal. Dalam banyak kasus, kegagalan ini tidak menunjukkan masalah permanen dan dapat diselesaikan dengan menunggu dan mencoba lagi. Menerapkan strategi percobaan ulang yang solid mengakui realitas lingkungan yang tidak sempurna dalam sistem terdistribusi, memastikan keandalan dan kontinuitas yang lebih kuat dengan sedikit kebutuhan untuk intervensi manual.
Risiko percobaan ulang tanpa pandang bulu
Mencoba ulang setiap kesalahan secara default dapat menyebabkan beberapa konsekuensi yang tidak diinginkan:
-
Peningkatan perti kaian — Ketika operasi yang gagal karena konkurensi tinggi dicoba ulang berulang kali, perselisihan keseluruhan bisa menjadi lebih buruk. Hal ini dapat mengakibatkan siklus transaksi yang gagal dan kinerja yang menurun.
-
Kehabisan sumber daya — Percobaan ulang tanpa pandang bulu dapat menghabiskan sumber daya sistem tambahan, baik di sisi klien maupun server. Hal ini berpotensi menyebabkan pelambatan atau bahkan degradasi layanan.
-
Peningkatan latensi untuk klien — Percobaan ulang yang berlebihan dapat menyebabkan penundaan yang signifikan untuk aplikasi klien, terutama jika setiap percobaan ulang melibatkan periode tunggu. Hal ini dapat berdampak negatif pada pengalaman pengguna dan proses hilir.
Mengembangkan strategi percobaan ulang yang praktis
Untuk membangun aplikasi yang tangguh dan efisien, kembangkan strategi coba ulang yang disesuaikan dengan kondisi kesalahan spesifik yang mungkin dihadapi aplikasi Anda. Berikut adalah beberapa pertimbangan untuk memandu pendekatan Anda:
-
Identifikasi kesalahan yang dapat dicoba ulang — Tidak semua pengecualian harus dicoba ulang. Misalnya, kesalahan sintaks, kegagalan otentikasi, atau kueri tidak valid seharusnya tidak memicu percobaan ulang. Neptunus menyediakan kode kesalahan dan rekomendasi umum kesalahan mana yang aman untuk dicoba lagi, tetapi Anda perlu menerapkan logika yang sesuai dengan kasus penggunaan Anda.
-
Terapkan mundur eksponensial — Untuk kesalahan sementara, gunakan strategi backoff eksponensial untuk secara progresif meningkatkan waktu tunggu di antara percobaan ulang. Ini membantu mengurangi perselisihan dan mengurangi risiko kegagalan bertingkat.
-
Pertimbangkan panjang jeda awal — Melakukan percobaan ulang pertama terlalu cepat mungkin berakhir dengan kesalahan yang sama jika server belum diberi cukup waktu untuk melepaskan sumber daya yang dibutuhkan kueri agar berhasil. Jeda yang lebih lama dalam situasi yang tepat dapat mengurangi permintaan yang terbuang dan tekanan server.
-
Tambahkan jitter ke backoff — Meskipun backoff eksponensial efektif, itu masih dapat menyebabkan badai coba ulang yang disinkronkan jika banyak klien gagal pada saat yang sama dan kemudian mencoba lagi bersama. Menambahkan jitter, variasi acak kecil pada penundaan mundur, membantu menyebarkan upaya percobaan ulang sehingga mengurangi kemungkinan semua klien mencoba lagi secara bersamaan dan menyebabkan lonjakan beban lainnya.
-
Batasi upaya coba ulang — Tetapkan jumlah percobaan ulang maksimum yang wajar untuk mencegah loop tak terbatas dan kehabisan sumber daya.
-
Pantau dan sesu aikan — Terus pantau tingkat kesalahan aplikasi Anda dan sesuaikan strategi coba ulang sesuai kebutuhan. Jika Anda melihat jumlah percobaan ulang yang tinggi untuk operasi tertentu, pertimbangkan apakah operasi dapat dioptimalkan atau diserialkan.
Untuk diskusi yang lebih dalam tentang backoff eksponensial dan jitter sebagai pola desain cloud umum, lihat Coba Ulang dengan bac koff di Panduan Prescriptive. AWS
Contoh alur perencanaan
Strategi coba ulang yang tepat tergantung pada sifat kegagalan, beban kerja, dan pola kesalahan yang Anda amati. Tabel berikut merangkum beberapa skenario kegagalan umum dan bagaimana pertimbangan strategi coba ulang berlaku untuk masing-masing. Paragraf penjelasan berikut untuk konteks tambahan.
|
Skenario |
Dicoba ulang? |
Backoff & Jitter |
Jeda Awal |
Batas Coba Lagi |
Pantau & Sesuaikan |
|---|---|---|---|---|---|
|
CME Sesekali pada Kueri Pendek |
Ya |
Backoff singkat, tambahkan jitter |
Pendek (misalnya, 100ms) |
Tinggi |
Perhatikan kenaikan Tarif CME |
|
CME yang sering dilakukan pada kueri Longer-Running |
Ya |
Backoff lebih lama, tambahkan jitter |
Lebih lama (misalnya, 2s) |
Sedang |
Selidiki dan kurangi perselisihan |
|
Batasan Memori pada Kueri Mahal |
Ya |
Mundur panjang |
Panjang (misalnya, 5-10s) |
Rendah |
Optimalkan kueri, waspadai jika persisten |
|
Batas waktu pada Kueri Moderat |
Mungkin |
Backoff moderat, tambahkan jitter |
Sedang (misalnya, 1s) |
Rendah hingga Sedang |
Menilai beban server dan desain kueri |
Skenario 1: CME sesekali pada kueri pendek
Untuk beban kerja yang jarang ConcurrentModificationException muncul selama pembaruan singkat dan sederhana, kesalahan ini biasanya bersifat sementara dan aman untuk dicoba lagi. Gunakan jeda awal singkat (misalnya, 100 milidetik) sebelum percobaan ulang pertama. Kali ini memungkinkan kunci singkat untuk dihapus. Gabungkan ini dengan backoff eksponensial pendek dan jitter untuk menghindari percobaan ulang yang disinkronkan. Karena biaya percobaan ulang rendah, batas percobaan ulang yang lebih tinggi masuk akal. Namun, pantau tingkat CME untuk menangkap tren apa pun menuju peningkatan pertikaian dalam data Anda.
Skenario 2: CME yang sering terjadi pada kueri yang berjalan lama
Jika aplikasi Anda sering melihat CME pada kueri yang berjalan lama, ini menunjukkan perselisihan yang lebih parah. Dalam hal ini, mulailah dengan jeda awal yang lebih lama (misalnya, 2 detik), untuk memberikan kueri saat ini yang menahan kunci cukup waktu untuk menyelesaikannya. Gunakan backoff eksponensial yang lebih panjang dan tambahkan jitter. Batasi jumlah percobaan ulang untuk menghindari penundaan yang berlebihan dan penggunaan sumber daya. Jika perselisihan berlanjut, tinjau beban kerja Anda untuk mengetahui pola dan pertimbangkan untuk membuat pembaruan serial atau mengurangi konkurensi untuk mengatasi akar penyebabnya.
Skenario 3: Batasan memori pada kueri mahal
Ketika kesalahan berbasis memori terjadi selama kueri intensif sumber daya yang diketahui, percobaan ulang dapat masuk akal, tetapi hanya setelah jeda awal yang lama (misalnya, 5 hingga 10 detik atau lebih) untuk memungkinkan server melepaskan sumber daya. Gunakan strategi mundur panjang dan tetapkan batas percobaan ulang yang rendah, karena kegagalan berulang tidak mungkin diselesaikan tanpa perubahan pada kueri atau beban kerja. Kesalahan persisten harus memicu peringatan dan meminta tinjauan kompleksitas kueri dan penggunaan sumber daya.
Skenario 4: Batas waktu pada kueri moderat
Waktu tunggu pada kueri yang cukup mahal adalah kasus yang lebih ambigu. Terkadang, percobaan ulang mungkin berhasil jika batas waktu disebabkan oleh lonjakan sementara dalam beban server atau kondisi jaringan. Mulailah dengan jeda awal moderat (misalnya, 1 detik) untuk memberi sistem kesempatan untuk pulih. Terapkan mundur moderat dan tambahkan jitter untuk menghindari percobaan ulang yang disinkronkan. Pertahankan batas coba ulang rendah hingga sedang, karena batas waktu berulang mungkin mengindikasikan masalah yang lebih dalam dengan kueri atau kapasitas server. Pantau pola: jika batas waktu menjadi sering, nilai apakah kueri perlu dioptimalkan atau apakah cluster Neptunus kurang disediakan.
Pemantauan dan observabilitas
Pemantauan adalah bagian penting dari strategi percobaan ulang apa pun. Pengamatan yang efektif membantu Anda memahami seberapa baik logika coba ulang Anda bekerja dan memberikan sinyal awal ketika sesuatu dalam konfigurasi beban kerja atau cluster Anda membutuhkan perhatian.
MainRequestQueuePendingRequests
CloudWatch Metrik ini melacak jumlah permintaan yang menunggu dalam antrian input Neptunus. Nilai yang meningkat menunjukkan bahwa kueri sedang dicadangkan, yang dapat menjadi tanda perselisihan yang berlebihan, sumber daya yang kurang disediakan, atau badai coba lagi. Memantau metrik ini membantu Anda mengetahui kapan strategi coba ulang menyebabkan atau memperparah masalah antrian, dan dapat meminta Anda untuk menyesuaikan pendekatan Anda sebelum kegagalan meningkat.
CloudWatch Metrik lainnya
Metrik Neptunus lainnya seperti CPUUtilizationTotalRequestsPerSecond,, dan latensi kueri memberikan konteks tambahan. Misalnya, CPU tinggi dan I/O dikombinasikan dengan panjang antrian yang bertambah mungkin menunjukkan bahwa cluster Anda kelebihan beban atau kueri terlalu besar atau terlalu sering. CloudWatch alarm dapat diatur pada metrik ini untuk mengingatkan Anda tentang perilaku abnormal dan membantu Anda menghubungkan lonjakan kesalahan atau percobaan ulang dengan kendala sumber daya yang mendasarinya.
Status Neptunus dan API Kueri
API Status Neptune untuk Gremlin dan API analognya untuk OpenCypher dan SPARQL memberikan tampilan real-time dari kueri yang diterima dan berjalan di cluster yang berguna untuk mendiagnosis hambatan atau memahami dampak logika coba ulang secara real time.
Dengan menggabungkan alat pemantauan ini, Anda dapat:
-
Mendeteksi kapan percobaan ulang berkontribusi terhadap antrian dan penurunan kinerja.
-
Identifikasi kapan harus menskalakan cluster Neptunus Anda atau mengoptimalkan kueri.
-
Validasikan bahwa strategi coba ulang Anda menyelesaikan kegagalan sementara tanpa menutupi masalah yang lebih dalam.
-
Terima peringatan dini tentang pertikaian yang muncul atau kelelahan sumber daya.
Pemantauan dan peringatan proaktif sangat penting untuk menjaga penyebaran Neptunus yang sehat, terutama saat konkurensi dan kompleksitas aplikasi Anda tumbuh.
