Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Jika Anda memiliki satu replika baca atau lebih klaster Anda, itu ide yang baik untuk menyeimbangkan permintaan baca di seluruh replika ini. Salah satu pilihan adalah dengan menggunakan reader endpoint. Reader Endpoint menyeimbangkan koneksi di seluruh replika bahkan jika topologi klaster berubah ketika Anda menambahkan atau menghapus replika, atau mempromosikan replika untuk menjadi instans primer baru.
Namun, menggunakan Reader Endpoint dapat mengakibatkan penggunaan sumber daya klaster yang tidak merata dalam beberapa keadaan. Reader Endpoint bekerja dengan mengubah host yang ditunjuk entri DNS secara berkala. Jika klien membuka banyak koneksi sebelum perubahan entri DNS, semua permintaan koneksi dikirim ke instans Neptune tunggal. Hal ini dapat menjadi kasus dengan skenario Lambda throughput tinggi di mana sejumlah besar permintaan bersamaan untuk fungsi Lambda Anda menyebabkan beberapa konteks eksekusi akan dibuat, masing-masing dengan koneksinya sendiri. Jika koneksi tersebut semuanya dibuat hampir bersamaan, koneksi cenderung ke semua titik pada replika yang sama dalam klaster, dan untuk tetap menunjuk ke replika itu sampai konteks eksekusi didaur ulang.
Salah satu cara Anda dapat mendistribusikan permintaan di seluruh instans adalah untuk mengkonfigurasi fungsi Lambda Anda agar terhubung ke titik akhir instans, dipilih secara acak dari daftar titik akhir instans replika, bukan Reader Endpoint. Kelemahan dari pendekatan ini adalah bahwa pendekatan ini memerlukan kode Lambda untuk menangani perubahan dalam topologi klaster dengan memantau klaster dan memperbarui daftar titik akhir setiap kali keanggotaan klaster berubah.
Jika Anda menulis fungsi Lambda Java yang perlu menyeimbangkan permintaan baca di seluruh instans di klaster Anda, Anda dapat menggunakan Klien Gremlin untuk Amazon Neptune
