Ketahanan koneksi

Coba lagi perintah

Konfigurasikan sambungan klien Anda untuk mencoba kembali perintah dengan backoff eksponensial. Untuk informasi selengkapnya, lihat coba lagi panduan.

Uji ketahanan

Uji ketahanan sistem Anda terhadap pemutusan sambungan menggunakan mulai ulang untuk mensimulasikan patch. Untuk informasi selengkapnya tentang menguji performa Anda, lihat Pengujian performa.

Pengaturan TCP untuk aplikasi klien yang dihosting Linux

Pengaturan TCP default di beberapa versi Linux dapat menyebabkan koneksi server Redis gagal selama 13 menit atau lebih. Pengaturan default dapat mencegah aplikasi klien mendeteksi koneksi tertutup dan memulihkannya secara otomatis jika koneksi tidak ditutup dengan baik.

Kegagalan untuk membangun kembali koneksi dapat terjadi dalam situasi di mana koneksi jaringan terganggu atau server Redis offline untuk pemeliharaan yang tidak diencana.

Kami merekomendasikan pengaturan TCP berikut:

Pengaturan Nilai
net.ipv4.tcp_retries2 5

Untuk informasi selengkapnya tentang skenario, lihat Koneksi tidak terbentuk kembali selama 15 menit saat berjalan di Linux. Sementara diskusi ini adalah tentang pustaka StackExchange.Redis, pustaka klien lain yang berjalan di Linux juga terpengaruh. Penjelasannya masih berguna dan Anda dapat menggeneralisasi ke pustaka lain.

Menggunakan ForceReconnect dengan StackExchange.Redis

Dalam kasus yang jarang terjadi, StackExchange.Redis gagal untuk menyambung kembali setelah koneksi dijatuhkan. Dalam kasus ini, memulai ulang klien atau membuat ConnectionMultiplexer baru akan memperbaiki masalah. Sebaiknya gunakan pola ConnectionMultiplexer database tunggal sambil memungkinkan aplikasi untuk memaksa koneksi ulang secara berkala. Lihatlah proyek sampel mulai cepat yang paling sesuai dengan kerangka kerja dan platform yang digunakan aplikasi Anda. Anda dapat melihat contoh pola kode ini di mulai cepat kami.

Pengguna ConnectionMultiplexer harus menangani kesalahan ObjectDisposedException yang mungkin terjadi sebagai akibat dari membuang yang lama.

Panggilan ForceReconnectAsync() untuk RedisConnectionExceptions dan RedisSocketExceptions. Anda juga dapat memanggil ForceReconnectAsync() untuk RedisTimeoutExceptions, tetapi hanya jika Anda menggunakan ReconnectMinInterval dan ReconnectErrorThreshold yang banyak. Jika tidak, membuat koneksi baru dapat menyebabkan kegagalan kaskade pada server yang waktunya habis karena sudah kelebihan beban.

Konfigurasikan batas waktu yang sesuai

Dua nilai batas waktu penting untuk dipertimbangkan dalam ketahanan koneksi: batas waktu koneksi dan batas waktu perintah.

Batas waktu koneksi

connect timeout adalah waktu klien Anda menunggu untuk membuat koneksi dengan server Redis. Konfigurasikan pustaka klien Anda untuk menggunakan connect timeoutlima detik, memberikan waktu yang cukup kepada sistem untuk terhubung bahkan dalam kondisi CPU yang lebih tinggi.

Nilai connection timeout kecil tidak menjamin koneksi dibuat dalam kerangka waktu tersebut. Jika ada yang tidak beres (CPU klien tinggi, CPU server tinggi, dan sebagainya), maka nilai connection timeout pendek menyebabkan koneksi gagal. Perilaku ini sering membuat situasi yang buruk semakin buruk. Alih-alih membantu, batas waktu yang lebih singkat memperburuk masalah dengan memaksa sistem untuk memulai kembali proses mencoba terhubung kembali, yang dapat menyebabkan perulangan koneksi -> gagal -> coba lagi.

Batas Waktu Perintah

Sebagian besar pustaka klien memiliki konfigurasi timeout lain untuk command timeouts, yang merupakan waktu klien menunggu respons dari server Redis. Meskipun kami merekomendasikan pengaturan awal kurang dari lima detik, pertimbangkan untuk mengatur command timeout lebih tinggi atau lebih rendah tergantung pada skenario Anda dan ukuran nilai yang disimpan dalam cache Anda.

Jika command timeout terlalu kecil, koneksi bisa terlihat tidak stabil. Namun, jika command timeout terlalu besar, aplikasi Anda mungkin harus menunggu lama untuk mengetahui apakah perintah akan mengalami waktu habis atau tidak.

Hindari lonjakan sambungan klien

Hindari membuat banyak sambungan sekaligus saat menyambungkan kembali setelah sambungan terputus. Mirip dengan cara batas waktu sambungan singkat dapat mengakibatkan pemadaman yang lebih lama, memulai banyak upaya penyambungan ulang pada saat yang sama juga dapat meningkatkan beban server dan memperpanjang waktu yang dibutuhkan semua klien untuk berhasil menyambung kembali.

Jika Anda menghubungkan kembali banyak instans klien, pertimbangkan untuk mengejutkan sambungan baru untuk menghindari lonjakan tajam dalam jumlah klien yang terhubung.

Catatan

Saat Anda menggunakan pustaka klien StackExchange.Redis, atur abortConnect ke false di string koneksi Anda. Sebaiknya biarkan ConnectionMultiplexer menangani sambungan ulang. Untuk informasi selengkapnya, lihat praktik terbaik StackExchange.Redis.

Hindari sambungan sisa

Cache memiliki batasan jumlah sambungan klien per tingkat cache. Pastikan bahwa ketika aplikasi klien Anda membuat ulang sambungan, aplikasi itu menutup dan menghapus sambungan lama.

Pemberitahuan pemeliharaan tingkat lanjut

Gunakan pemberitahuan untuk mempelajari pemeliharaan yang akan datang. Untuk informasi selengkapnya, lihat Dapatkah saya diberi tahu terlebih dahulu tentang pemeliharaan terencana.

Menjadwalkan jendela pemeliharaan

Sesuaikan pengaturan cache Anda untuk mengakomodasi pemeliharaan. Untuk informasi selengkapnya tentang membuat jendela pemeliharaan untuk mengurangi efek negatif pada cache Anda, lihat Memperbarui saluran dan Menjadwalkan pembaruan.

Lebih banyak pola desain untuk ketahanan

Terapkan pola desain untuk ketahanan. Untuk informasi selengkapnya, lihat Cara membuat aplikasi saya tangguh.

Batas waktu jeda

Azure Cache for Redis memiliki batas waktu 10 menit untuk koneksi diam. Batas waktu 10 menit memungkinkan server untuk secara otomatis membersihkan koneksi bocor atau koneksi yang tidak memiliki sumber oleh aplikasi klien. Sebagian besar pustaka klien Redis memiliki kemampuan bawaan untuk mengirim heartbeat atau keepalive memerintahkan secara berkala untuk mencegah koneksi ditutup meskipun tidak ada permintaan dari aplikasi klien.

Jika ada risiko koneksi Anda menganggur selama 10 menit, konfigurasikan keepalive interval ke nilai kurang dari 10 menit. Jika aplikasi Anda menggunakan pustaka klien yang tidak memiliki dukungan asli untuk keepalive fungsionalitas, Anda dapat menerapkannya di aplikasi Anda dengan mengirim PING perintah secara berkala.