Tair (Redis® OSS-Compatible)：Praktik terbaik untuk fitur connection pool dalam mode proxy kluster

Skenario

Dalam mode proxy pada instans kluster cloud native, perintah standar diteruskan melalui koneksi bersama. Peningkatan jumlah koneksi klien tidak memengaruhi jumlah koneksi DB backend. Namun, ketika logika bisnis Anda mencakup perintah stateful tertentu, koneksi antara proxy dan node data beralih dari mode bersama ke mode eksklusif.

Dalam mode eksklusif, setiap koneksi klien membuat koneksi eksklusif yang sesuai pada node data. Dalam skenario konkurensi tinggi, ini menyebabkan jumlah koneksi pada node data bertambah secara linear dengan jumlah koneksi klien. Hal ini dapat memicu kesalahan jumlah maksimum klien tercapai dan menyebabkan gangguan layanan.

Ketika Anda menggunakan watch atau permintaan pemblokiran, penskalaan dengan menambah jumlah shard tidak menyelesaikan masalah terlalu banyak koneksi pada satu shard.

Perintah yang memicu mode eksklusif meliputi:

• Perintah transaksi: MULTI/EXEC (setelah WATCH)

• Perintah pemblokiran: BLPOP, BRPOP, BRPOPLPUSH, XREAD ... BLOCK ...

Fitur kolam koneksi mengumpulkan dan menggunakan kembali koneksi eksklusif dari proxy ke node data. Ini mengurangi jumlah koneksi pada node data dan mencegah kegagalan permintaan yang disebabkan oleh melebihi batas koneksi.

Arsitektur

Fitur connection pool berjalan secara independen pada setiap instans anak proxy. Setiap proxy memelihara connection pool khusus untuk koneksi ke masing-masing node data.

Contoh:

Tanpa connection pool, setiap koneksi antara klien dan proxy membuat koneksi terpisah ke setiap shard data backend yang diaksesnya. Misalnya, jika 10 koneksi klien mengakses 5 shard, total koneksi yang dibuat adalah 10 × 5 = 50.

Ketika Anda mengaktifkan kolam koneksi, proxy mempertahankan kolam koneksi terbatas untuk setiap shard data. Permintaan klien kemudian menggunakan kembali koneksi dalam kolam ini. Ini secara signifikan mengurangi jumlah koneksi database yang sebenarnya dibuat. Sebagai contoh, untuk 10 koneksi klien yang sama, setiap shard mungkin hanya perlu mempertahankan 2 koneksi dalam kolamnya, menghasilkan total hanya 2 × 5 = 10 koneksi.

Alur kerja:

1. Ketika koneksi klien (Client Conn) memulai permintaan dalam mode eksklusif, node proxy mengambil koneksi idle dari kolam koneksi shard data yang sesuai.

2. Hits kolam: Jika koneksi idle tersedia dalam kolam, proxy segera menyambungkan koneksi ke koneksi klien untuk meneruskan permintaan. Setelah permintaan selesai, koneksi dilepaskan dan dikembalikan ke kolam koneksi untuk digunakan kembali oleh klien lain.

3. Miss kolam: Jika tidak ada koneksi idle yang tersedia dalam kolam, proxy membuat koneksi baru. Setelah permintaan selesai:

   1. Jika jumlah total koneksi dalam kolam belum mencapai batas atas (private_conn_pool_max_idle_per_db), koneksi ditambahkan ke kolam.

   2. Jika jumlah total koneksi dalam kolam telah mencapai batas atas, koneksi segera dilepaskan (mode koneksi singkat).

Optimalisasi ini secara signifikan mengurangi overhead manajemen koneksi pada database, menurunkan penggunaan sumber daya, serta meningkatkan stabilitas dan throughput database.

Penerapan

Instans harus memenuhi persyaratan berikut:

• Mode penyebaran: Cloud native. Anda dapat mengubah mode penyebaran dari classic ke cloud native.

• Arsitektur instans: Kluster. Anda dapat mengubah arsitektur instans dari standar ke kluster.

• Mode koneksi: Mode proxy.

• Versi proxy: 7.0.17 atau lebih baru. Jika versi Anda lebih lama, Anda dapat memperbarui versi proxy.

Mengaktifkan fitur kolam koneksi

Anda dapat mengaktifkan fitur kolam koneksi dengan memodifikasi parameter instans. Operasi ini mendukung pembaruan panas dan tidak memerlukan restart instans. Tidak memengaruhi layanan Anda.

1. Buka halaman Instans. Di bilah navigasi atas, pilih wilayah. Lalu, klik ID instans target.

2. Di panel navigasi di sebelah kiri, klik Parameter Settings.

3. Di daftar parameter, temukan private_conn_pool_enabled dan klik Modify di kolom Aksi.

4. Pada kotak dialog yang muncul, atur nilai parameter menjadi 1 dan klik OK.

Setelah itu, Anda dapat membuka Konsol Cloud Monitor, temukan instans tersebut, dan lihat metrik Connections from Proxy to DB di bawah Infrastructure Monitoring untuk membandingkan data sebelum dan sesudah mengaktifkan fitur ini.

Detail konfigurasi dan panduan tuning

Catatan

• Atur nilai private_conn_pool_min_idle_per_db secara wajar

  Setiap koneksi idle mengonsumsi sejumlah sumber daya memori pada node DB backend. Pada instans dengan banyak shard dan beberapa node proxy, mengatur private_conn_pool_min_idle_per_db ke nilai tinggi dapat menyebabkan penggunaan memori yang tinggi.

• Hindari pergantian konteks DB yang tidak perlu

  Saat koneksi dari pool digunakan kembali oleh klien yang mengakses indeks DB berbeda, proxy harus menjalankan perintah SELECT untuk mengganti konteks. Operasi ini meningkatkan muatan DB dan latensi permintaan. Dalam desain aplikasi Anda, pastikan semua klien menggunakan indeks DB yang sama, biasanya DB 0.

• Tidak berlaku untuk perintah publish/subscribe

  Fitur connection pool tidak berlaku untuk perintah publish/subscribe seperti SUBSCRIBE dan PSUBSCRIBE. Perintah-perintah ini secara permanen menduduki koneksi, sehingga koneksi tersebut tidak dikelola oleh pool.

Referensi

• Arsitektur kluster

• Fitur proxy Tair