All Products
Search

This Product

    Tair (Redis® OSS-Compatible):Praktik terbaik kolam koneksi untuk modus proxy kluster

    Document Center

    Tair (Redis® OSS-Compatible):Praktik terbaik kolam koneksi untuk modus proxy kluster

    Last Updated:Jun 03, 2026

    Kolam koneksi dalam modus proxy kluster menggunakan kembali koneksi dari proxy ke database, mencegah kehabisan koneksi backend akibat perintah stateful, dan memastikan stabilitas instans Tair (Redis OSS-compatible) Anda.

    Skenario

    Dalam modus proxy kluster cloud native, perintah standar menggunakan koneksi bersama sehingga pertumbuhan koneksi klien tidak memengaruhi koneksi database backend. Namun, perintah stateful tertentu mengubah koneksi dari proxy ke node data dari mode bersama menjadi mode eksklusif.

    Dalam mode eksklusif, setiap koneksi klien membuat koneksi khusus pada node data. Di bawah konkurensi tinggi, jumlah koneksi node data meningkat secara linear seiring dengan koneksi klien, berpotensi memicu error max number of clients reached dan menyebabkan gangguan layanan.

    Scaling out dengan menambahkan shard tidak menyelesaikan kehabisan koneksi per shard yang disebabkan oleh permintaan WATCH atau perintah blocking.

    Perintah yang memicu mode eksklusif:

    • Perintah transaksi: MULTI/EXEC (setelah WATCH)

    • Perintah blocking: BLPOP, BRPOP, BRPOPLPUSH, dan XREAD ... BLOCK ...

    Kolam koneksi menggunakan kembali koneksi eksklusif dari proxy ke node data, mengurangi jumlah koneksi ke node data, dan mencegah kegagalan akibat melebihi batas koneksi.

    Arsitektur

    Setiap instans anak proxy menjalankan kolam koneksi independen dan memelihara kolam khusus untuk setiap node data.

    Contoh:

    Tanpa kolam koneksi, setiap koneksi klien-proxy membuat koneksi terpisah ke setiap shard backend. Misalnya, 10 koneksi klien yang mengakses 5 shard menghasilkan 10 × 5 = 50 koneksi.

    Dengan pooling koneksi diaktifkan, proxy memelihara kolam terbatas untuk setiap shard, dan permintaan klien menggunakan kembali koneksi dalam kolam tersebut. Misalnya, 10 koneksi klien yang sama mungkin hanya memerlukan 2 koneksi dalam kolam per shard, sehingga totalnya menjadi 2 × 5 = 10 koneksi.

    Alur kerja:

    1. Saat klien memulai permintaan dalam mode eksklusif, proxy mengambil koneksi idle dari kolam koneksi shard target.

    2. Pool hit: Koneksi idle ditautkan ke koneksi klien untuk permintaan tersebut. Setelah selesai, koneksi dilepas dan dikembalikan ke kolam untuk digunakan kembali.

    3. Pool miss: Proxy membuat koneksi baru. Setelah permintaan selesai:

      1. Jika kolam belum mencapai batas (private_conn_pool_max_idle_per_db), koneksi tersebut ditambahkan ke kolam.

      2. Jika kolam penuh, koneksi segera dilepaskan (mode koneksi singkat).

    Hal ini mengurangi beban manajemen koneksi, menurunkan konsumsi sumber daya pada database, serta meningkatkan stabilitas dan throughput.

    Persyaratan

    Instans Anda harus memenuhi persyaratan berikut:

    Aktifkan pooling koneksi

    Aktifkan pooling koneksi dengan memodifikasi parameter instans. Ini merupakan pembaruan panas yang tidak memerlukan restart atau memengaruhi layanan yang sedang berjalan.

    1. Buka halaman Instances. Pada bilah navigasi atas, pilih wilayah. Lalu, klik ID instans target.

    2. Pada panel navigasi kiri, klik Parameter Settings.

    3. Temukan private_conn_pool_enabled dan klik Modify pada kolom Actions.

    4. Pada kotak dialog, atur nilainya menjadi 1 lalu klik OK.

    Untuk memverifikasi, periksa metrik Connections from Proxy to DB di bawah Infrastructure Monitoring pada Konsol Cloud Monitor untuk membandingkan data sebelum dan sesudah mengaktifkan fitur ini.

    Konfigurasi dan penyetelan

    Nama konfigurasi

    Deskripsi

    Nilai default

    Rentang nilai

    private_conn_pool_enabled

    Mengaktifkan atau menonaktifkan pooling koneksi. 1: diaktifkan. 0: dinonaktifkan.

    0

    [0|1]

    private_conn_idle_time_sec

    TTL untuk koneksi idle dalam kolam, dalam satuan detik. Koneksi yang idle melebihi ambang batas ini akan ditutup. 0: tutup segera.

    60

    [0-4294967295]

    private_conn_pool_max_idle_per_db

    Jumlah maksimum koneksi idle yang dipertahankan setiap node proxy per node data. Saat batas ini tercapai, koneksi yang dilepaskan akan ditutup alih-alih dikembalikan ke kolam.

    1000

    [0-4294967295]

    private_conn_pool_min_idle_per_db

    Jumlah minimum koneksi idle yang dipertahankan setiap node proxy per node data. Koneksi di bawah ambang batas ini tetap dipertahankan meskipun melebihi private_conn_idle_time_sec.

    0

    [0-4294967295]

    Rekomendasi penyetelan

    • Skenario umum: Gunakan nilai default. Nilai tersebut sesuai untuk sebagian besar beban kerja.

    • Skenario transaksi konkurensi tinggi dengan koneksi singkat (seperti penjualan kilat)

      • Karakteristik: Koneksi singkat dengan siklus pinjam/kembalikan yang sering.

      • Rekomendasi: Atur private_conn_pool_max_idle_per_db cukup tinggi untuk menangani permintaan konkuren puncak, memaksimalkan penggunaan kembali, dan menghindari koneksi singkat. Secara opsional, turunkan private_conn_idle_time_sec agar sumber daya lebih cepat dilepaskan selama jam sepi.

    • Skenario layanan blocking jangka panjang (seperti konsumen antrian)

      • Karakteristik: Koneksi yang dipertahankan lama dan jarang dikembalikan ke kolam.

      • Rekomendasi: Tingkatkan private_conn_pool_max_idle_per_db agar sesuai dengan jumlah konsumen konkuren. Atur private_conn_pool_min_idle_per_db sedikit di atas rata-rata koneksi konkuren untuk melakukan pra-ambil koneksi dan mengurangi latensi bagi konsumen baru.

    • Skenario instans kecil atau terbatas memori

      • Karakteristik: Anggaran memori ketat.

      • Rekomendasi: Turunkan private_conn_pool_max_idle_per_db dan private_conn_pool_min_idle_per_db. Hal ini mengorbankan sedikit efisiensi penggunaan kembali demi mengurangi konsumsi memori pada node data.

    Catatan penggunaan

    • Atur nilai private_conn_pool_min_idle_per_db secara wajar

      Setiap koneksi idle mengonsumsi memori pada node database backend. Dengan banyak shard dan node proxy, nilai private_conn_pool_min_idle_per_db yang tinggi dapat menyebabkan penggunaan memori berlebihan.

    • Hindari pergantian konteks database yang tidak perlu

      Saat koneksi dalam kolam digunakan kembali oleh klien yang mengakses indeks database berbeda, proxy menjalankan perintah SELECT untuk mengganti konteks, sehingga meningkatkan muatan dan latensi database. Rancang aplikasi Anda untuk menggunakan satu indeks database saja (biasanya DB 0).

    • Tidak berlaku untuk perintah publish/subscribe

      Pooling koneksi tidak berlaku untuk perintah SUBSCRIBE dan PSUBSCRIBE. Perintah ini secara permanen menduduki koneksi dan tidak dikelola oleh kolam.

    Referensi