Tair (Redis® OSS-Compatible)：Dampak kegagalan shard data pada laju keberhasilan permintaan

Misalkan jumlah shard data dalam sebuah instance kluster adalah N. Jika salah satu shard data mengalami kegagalan, failover master-replika diinisiasi untuk shard data tersebut. Proses ini memerlukan waktu mulai dari beberapa detik hingga puluhan detik. Selama proses ini berlangsung, semua permintaan yang dikirim ke shard data tersebut gagal. Jika permintaan didistribusikan secara merata di seluruh shard data, secara teoretis instance memiliki laju kegagalan permintaan sebesar 1/N.

Namun, jumlah permintaan yang gagal mungkin lebih tinggi daripada nilai teoretis karena alasan berikut. Contoh ini menggunakan instance kluster dengan dua shard data yang berjalan dalam mode proxy.

• Penggunaan perintah yang melibatkan beberapa key

  • Mode proxy: Server proxy membagi perintah multi-key menjadi beberapa subperintah dan mengarahkannya ke shard data yang sesuai berdasarkan tabel rute.

  • Mode koneksi langsung: Klien mengirimkan setiap subperintah ke shard data yang sesuai.

  Ketika perintah multi-key melibatkan shard data yang mengalami kegagalan, seluruh permintaan cenderung gagal, seperti ditunjukkan pada gambar berikut.

  Solusi optimalisasi: Kurangi jumlah key dalam satu perintah untuk menurunkan kemungkinan kegagalan perintah multi-key ketika sebuah shard data gagal.

• Klien menggunakan satu koneksi

  Beberapa klien seperti Lettuce mengirimkan permintaan secara asinkron melalui satu koneksi. Sebagai contoh, dalam skenario di mana dua permintaan GET dikirim secara berurutan ke server proxy melalui satu koneksi, Redis Serialization Protocol (RESP) mengharuskan respons dikembalikan dalam urutan yang sama dengan pengiriman permintaan. Jika permintaan GET key2 gagal karena kegagalan node, klien tidak dapat menerima respons dari permintaan yang mengikuti GET key2, meskipun permintaan tersebut berhasil dieksekusi.

  Solusi optimalisasi: Gunakan klien seperti Jedis yang mendukung model kolam koneksi.

• Sumber daya kolam koneksi di sisi klien habis

  Untuk klien yang menggunakan model kolam koneksi, jumlah maksimum koneksi yang diizinkan dapat dikonfigurasi. Ketika jumlah koneksi mencapai batas maksimum dan tidak ada koneksi idle yang tersedia, permintaan baru gagal atau diblokir.

  Pada gambar berikut, klien Jedis digunakan. Jika maxTotal disetel ke 3, timeout disetel ke 2000, dan tiga permintaan GET key2 dilakukan dalam waktu 2 detik, kolam koneksi mencapai kapasitas maksimumnya dengan semua koneksi sedang digunakan setelah 2 detik. Jika salah satu node gagal merespons, permintaan baru akan gagal atau diblokir berdasarkan konfigurasi blockWhenExhausted, menyebabkan permintaan di sisi klien gagal atau waktu habis.

  Solusi optimalisasi: Konfigurasikan ukuran kolam sumber daya JedisPool dengan tepat dan atur parameter timeout ke nilai yang lebih rendah, seperti 200 hingga 300 milidetik (bukan default 2.000 milidetik). Penyesuaian ini membantu mencapai respons kegagalan yang lebih cepat dan mencegah sejumlah besar koneksi terblokir ketika terjadi kegagalan.