Fitur dan aturan routing Tair Proxy - Tair (Redis® OSS-Compatible)

Pada arsitektur kluster dan Pemisahan baca/tulis Tair (Redis OSS-compatible), server proxy (Proxy) menangani pengalihan permintaan, load balancing, dan failover untuk menyederhanakan logika sisi klien. Proxy juga mendukung fitur lanjutan seperti multiple databases (DBs) dan caching data hot spot. Pemahaman yang baik mengenai cara server proxy merutekan permintaan dan menangani perintah tertentu dapat membantu Anda merancang sistem bisnis yang lebih efisien.

Pengenalan proxy

Server proxy adalah komponen berarsitektur satu node dalam instans Tair. Proxy tidak mengonsumsi sumber daya dari shard data dan menerapkan load balancing serta failover melalui beberapa node proxy.

Fitur proxy	Deskripsi
Konversi pola penggunaan instans kluster	Node proxy memungkinkan Anda menggunakan instans kluster dengan cara yang sama seperti menggunakan instans standar. Proxy mendukung operasi multi-key lintas slot untuk perintah seperti DEL, EXISTS, MGET, MSET, SDIFF, dan UNLINK. Untuk informasi selengkapnya, lihat Daftar perintah yang didukung dalam mode proxy. Ketika arsitektur standar tidak dapat mendukung pertumbuhan bisnis Anda, Anda dapat memigrasikan data dari arsitektur standar ke arsitektur kluster dengan proxy tanpa mengubah kode Anda. Hal ini secara signifikan mengurangi biaya transformasi bisnis.
Load balancing dan routing	Proxy membuat koneksi persisten dengan shard data backend, menyeimbangkan beban, dan meneruskan permintaan. Untuk informasi selengkapnya tentang aturan pengalihan, lihat Metode routing node proxy.
Kelola traffic node read-only	Proxy mendeteksi status node read-only secara real time. Ketika situasi berikut terjadi, proxy melakukan aksi kontrol trafik: Node read-only berada dalam kondisi abnormal: Proxy mengurangi bobot layanan node tersebut. Jika proxy gagal terhubung ke node tersebut beberapa kali, layanan node akan dihentikan. Artinya, traffic tidak lagi diteruskan ke node tersebut. Proxy akan mengaktifkan kembali node setelah masalah diperbaiki. Node read-only sedang melakukan sinkronisasi penuh: Proxy sementara menghentikan layanan node hingga sinkronisasi penuh selesai.
Proxy Query Cache	Setelah Anda mengaktifkan fitur proxy query cache (Proxy Query Cache), proxy menyimpan cache permintaan untuk hot keys dan responsnya. Ketika proxy menerima permintaan yang sama dalam periode validitas cache, proxy langsung mengembalikan hasil ke klien tanpa berinteraksi dengan shard data backend. Hal ini membantu mengurangi ketimpangan akses yang disebabkan oleh banyak permintaan baca untuk hot keys. Catatan Anda dapat mengatur query_cache_enabled parameter untuk mengaktifkan fitur ini, yang hanya didukung oleh instans Tair yang dioptimalkan untuk memori dan instans yang dioptimalkan untuk memori persisten.
Dukungan untuk multiple databases (DBs)	Dalam mode kluster, Redis native dan klien Kluster tidak mendukung multiple databases (DBs). Mereka hanya menggunakan database default `0` dan tidak mendukung perintah `SELECT`. Namun, Anda dapat mengakses instans kluster melalui proxy untuk menggunakan multiple databases (DBs) dan perintah `SELECT`. Secara default, instans kluster menyediakan 256 DB. Catatan Jika Anda menggunakan klien StackExchange.Redis, harap gunakan StackExchange.Redis 2.7.20 atau versi yang lebih baru. Jika tidak, akan terjadi error. Untuk informasi selengkapnya, lihat Pengumuman Peningkatan StackExchange.Redis.

Catatan

Karena evolusi proxy, jumlah proxy tidak secara langsung merepresentasikan kapasitas pemrosesannya. Alibaba Cloud memastikan bahwa rasio proxy dalam tipe instans kluster memenuhi persyaratan yang tercantum dalam deskripsi tipe instans.

Aturan routing proxy

Catatan

Untuk informasi selengkapnya tentang perintah, lihat Ikhtisar perintah.

Arsitektur	Aturan routing	Deskripsi
Arsitektur kluster	Aturan routing dasar	Untuk perintah yang beroperasi pada satu kunci, proxy mengirim permintaan ke shard data yang sesuai berdasarkan slot kunci tersebut. Untuk perintah yang beroperasi pada beberapa kunci, jika kunci-kunci tersebut disimpan di shard data yang berbeda, proxy membagi perintah menjadi beberapa perintah dan mengirimkannya ke masing-masing shard. Catatan Mulai dari versi minor 5.0.1 Redis Open-Source Edition 5.0, dan pada versi 6.0, 7.0, serta yang lebih baru, Proxy membagi perintah berdasarkan level slot, yang konsisten dengan komunitas Redis. Namun, pada versi minor Redis Open-Source Edition 5.0 yang lebih awal dari 5.0.1, dan pada versi 4.0 serta 2.8, Proxy membagi perintah berdasarkan level shard. Ketika instans-instans ini ditingkatkan ke Redis Open-Source Edition 5.0 atau yang lebih baru, perubahan aturan pembagian perintah ini dapat menyebabkan peningkatan permintaan per detik (QPS) dan sedikit peningkatan traffic. Namun, karena Proxy mengirimkan perintah menggunakan pipelining, dampak terhadap performa relatif kecil.
Arsitektur kluster	Aturan routing perintah spesifik	Perintah publish/subscribe Untuk perintah publish/subscribe seperti PUBLISH dan SUBSCRIBE, proxy melakukan perhitungan hash pada nama channel dan merutekan perintah ke shard data yang sesuai. Meskipun perintah Pub/Sub tidak menulis data ke database, perintah tersebut tetap mengonsumsi sejumlah memori dan resource. Konsumsi resource terutama terjadi pada koneksi klien, manajemen status langganan, dan buffer pesan. Sebagai contoh, jika sebuah channel termasuk dalam shard data 1, klien yang berlangganan channel tersebut akan menggunakan memori, CPU, dan bandwidth jaringan dari shard data 1. Catatan Pada halaman Pemantauan Performa di Konsol, Anda dapat memilih Data node dan mengatur item pemantauan kustom ke Pub/Sub Monitoring Group untuk melihat informasi pemantauan perintah Publish/Subscribe (Pub/Sub) untuk setiap shard data (secara default, shard data pertama yang ditampilkan). Perintah proprietary Alibaba Cloud Saat Anda menggunakan perintah yang dikembangkan oleh Alibaba Cloud, seperti IINFO dan ISCAN, jika Anda menentukan ID shard data menggunakan parameter idx, Proxy mengirim perintah-perintah tersebut ke shard data yang ditentukan. Untuk informasi selengkapnya, lihat Perintah Proxy buatan sendiri.
Arsitektur Pemisahan baca/tulis	Aturan routing dasar	Permintaan tulis: Proxy meneruskannya langsung ke node primary (Master). Permintaan baca: Proxy mendistribusikan permintaan baca secara merata di antara node primary dan node read-only. Kontrol kustom tidak didukung. Sebagai contoh, dalam instans dengan tiga node read-only, bobot baca untuk node primary dan masing-masing dari tiga node read-only adalah 25%. Catatan SLOWLOG dan DBSIZE juga dianggap sebagai perintah baca.
Arsitektur Pemisahan baca/tulis	Aturan routing perintah spesifik	Perintah SCAN Saat Anda menjalankan perintah HSCAN, SSCAN, atau ZSCAN, proxy terlebih dahulu menghitung slot kunci tersebut. Kemudian, proxy menentukan node target menggunakan operasi modulo untuk mendistribusikan permintaan secara merata ke node primary dan node read-only. Perintah proprietary Alibaba Cloud Saat menggunakan perintah yang dikembangkan sendiri oleh Alibaba Cloud, seperti RIINFO dan RIMONITOR, Anda dapat menggunakan parameter ro_slave_idx untuk meneruskan perintah ke node read-only tertentu, dan parameter idx untuk meneruskannya ke shard data tertentu. Untuk informasi selengkapnya, lihat Perintah Proxy yang dikembangkan sendiri oleh Alibaba Cloud. Perintah lainnya Proxy meneruskan perintah transaksi (MULTI atau EXEC), perintah skrip Lua (EVAL atau EVALSHA), SCAN, INFO, dan perintah publish/subscribe (seperti PUBLISH dan SUBSCRIBE) ke node primary.

Proxy query cache

Node proxy dapat menyimpan cache permintaan yang berisi hot keys beserta hasil kuerinya. Saat menerima permintaan yang sama dalam periode validitas cache, proxy langsung mengembalikan hasil ke klien tanpa berinteraksi dengan shard data backend. Fitur ini dapat mengurangi atau mencegah ketimpangan kinerja akses akibat permintaan baca terhadap hot keys.

Hot key ini sama dengan hot key (QPS) dalam fitur Statistik Top Key. Hot key diidentifikasi oleh kernel database berdasarkan algoritma pengurutan dan statistik. Secara default, kunci dianggap hot jika permintaan per detik (QPS)-nya melebihi 5.000. Anda juga dapat menyesuaikan ambang batas ini menggunakan parameter bigkey-threshold.
Jika hot key dimodifikasi selama periode validitas cache, perubahan tersebut tidak disinkronkan ke cache. Artinya, permintaan selanjutnya mungkin membaca data kotor dari cache hingga cache kedaluwarsa. Untuk mengatasi hal ini, Anda dapat memperpendek periode validitas cache sesuai kebutuhan.

Catatan

Node proxy tidak menyimpan cache seluruh hot key. Sebaliknya, mereka menyimpan cache permintaan yang berisi hot key beserta hasil kueri yang sesuai.
Fitur ini hanya tersedia untuk instans Tair optimasi memori dan optimasi memori persisten yang menggunakan mode proksi pada arsitektur kluster atau arsitektur Pemisahan baca/tulis.

Skenario

Fitur ini cocok untuk skenario seperti daftar pencarian teratas, profil pengguna populer, dan pengumuman game, di mana aplikasi dapat mentolerir data yang sedikit kedaluwarsa.

Arsitektur fitur

Cara menggunakan

Fitur ini dinonaktifkan secara default. Anda dapat mengatur parameter query_cache_enabled untuk mengaktifkannya.

Lihat petunjuk detail

Parameter	Deskripsi

query_cache_enabled	Fitur cache kueri node proxy. Saat diaktifkan, node proxy menyimpan cache permintaan dan hasil kueri untuk hot keys. Jika permintaan yang sama diterima dalam periode validitas, node proxy langsung mengembalikan hasil ke klien tanpa berinteraksi dengan shard data backend. Penting Pasangan kunci-nilai hot keys yang di-cache pada node proxy tidak diperbarui selama periode validitas. Sebelum mengaktifkan fitur ini, pastikan bisnis Anda dapat mentolerir eventual consistency untuk data dalam periode validitas cache. query_cache_enabled: Menentukan apakah fitur ini diaktifkan. Nilai yang valid adalah 0 (nonaktif, default) dan 1 (aktif). query_cache_expire: Periode validitas data yang di-cache. Satuan dalam milidetik. Rentang [100-60000]. Default adalah 1000. Jika data yang di-cache dimodifikasi selama periode validitasnya, perubahan tersebut tidak disinkronkan ke cache. Artinya, permintaan baca yang sama akan mengambil data kotor dari cache hingga cache kedaluwarsa. Anda perlu mengevaluasi nilai parameter ini secara hati-hati berdasarkan skenario bisnis spesifik dan toleransi terhadap data kotor. Mengatur nilai terlalu rendah mengurangi tingkat hit cache, sedangkan mengatur nilai terlalu tinggi menyebabkan klien membaca data kotor lebih lama. query_cache_mode: Mode kerja fitur cache kueri node proxy. Nilai yang valid: 0 (default): Hanya menyimpan cache hot keys yang didorong oleh shard data. 1: Menyimpan cache semua kunci dan menghapusnya berdasarkan algoritma Least Recently Used (LRU). Karena ruang cache node proxy terbatas (100 MB per thread), jika Anda mengatur parameter ini ke 1, node proxy akan menghapus kunci sesuai algoritma LRU. Hal ini dapat mengurangi tingkat hit cache dan menyebabkan penurunan performa keseluruhan.
query_cache_expire
query_cache_mode

Anda dapat menggunakan perintah khusus QUERYCACHE KEYS, QUERYCACHE INFO, dan QUERYCACHE LISTALL dari Tair untuk memantau penggunaan proxy query cache.

Lihat penggunaan

QUERYCACHE KEYS

Format perintah: QUERYCACHE KEYS

Deskripsi perintah: Menampilkan semua hot keys yang di-cache dalam node proxy. Mengembalikan nama database dan nama kunci untuk setiap hot key.

Contoh:

QUERYCACHE KEYS

Contoh respons:

1) 1) (integer) 0
   2) "key:000000000003"
2) 1) (integer) 0
   2) "key:000000000001"
3) 1) (integer) 0
   2) "key:000000000002"
4) 1) (integer) 0
   2) "key:000000000000"

QUERYCACHE INFO

Format perintah: QUERYCACHE INFO

Deskripsi perintah: Mengambil status berjalan dari proxy query cache.

Contoh:

QUERYCACHE INFO

Contoh:

1) "put_qps:4.00"
2) "get_qps:16570.00"
3) "hit_rate:99.98"
4) "memory_size:180"
5) "query_count:4"
6) "bandwidth_limit_query_cnt:0"
7) "qps_limit_query_cnt:0"

Output contoh:

put_qps: Jumlah penulisan per detik dari node data ke Querycache.
get_qps: Jumlah pembacaan per detik dari klien ke Querycache.
hit_rate: Tingkat hit cache.
memory_size: Jumlah memori yang digunakan oleh data yang di-cache, dalam byte.
query_count: Jumlah kueri yang di-cache.
bandwidth_limit_query_cnt: Jumlah kali akses ke Querycache dibatasi karena batas bandwidth. Batas ini dinonaktifkan secara default.
qps_limit_query_cnt: Jumlah kali akses ke Querycache dibatasi karena batas permintaan per detik (QPS). Batas ini dinonaktifkan secara default.

QUERYCACHE LISTALL

Format perintah: QUERYCACHE LISTALL

Deskripsi perintah: Mengambil semua perintah permintaan yang di-cache.

Contoh:

QUERYCACHE LISTALL

Contoh respons:

1) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000000\r\n"
   3) (integer) 668
2) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000001\r\n"
   3) (integer) 668
3) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000003\r\n"
   3) (integer) 668
4) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000002\r\n"
   3) (integer) 667

Deskripsi respons: Informasi untuk setiap perintah permintaan terdiri dari tiga baris: nama database, konten lengkap perintah permintaan dalam format yang ditentukan oleh protokol Redis, dan sisa masa hidup (TTL) dalam milidetik.

Penggunaan koneksi

Umumnya, proxy memproses permintaan dengan membuat koneksi persisten ke shard data. Namun, saat permintaan mencakup perintah tertentu, proxy membuat koneksi tambahan ke shard data yang sesuai berdasarkan kebutuhan pemrosesan perintah tersebut. Dalam kasus ini, koneksi tidak dapat diagregasi. Jumlah maksimum koneksi untuk instans dibatasi oleh satu shard data. Untuk informasi mengenai batas per shard, lihat spesifikasi tipe instans yang relevan. Gunakan perintah-perintah berikut secara bijak untuk menghindari melebihi batas koneksi.

Catatan

Dalam mode proxy, instans Redis Community Edition memiliki batas koneksi 10.000 per shard data. (Edisi Perusahaan) memiliki batas koneksi 30.000 per shard data.

Perintah blocking: BRPOP, BRPOPLPUSH, BLPOP, BZPOPMAX, BZPOPMIN, BLMOVE, BLMPOP, dan BZMPOP.
Perintah transaksi: MULTI, EXEC, dan WATCH.
Perintah MONITOR: MONITOR, IMONITOR, dan RIMONITOR.
Perintah subscription: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, SSUBSCRIBE, dan SUNSUBSCRIBE.

FAQ

Bisakah saya meneruskan skrip Lua yang hanya melakukan operasi baca ke replika baca saja?
Ya, Anda dapat meneruskan skrip Lua yang hanya melakukan operasi baca ke replika baca saja, asalkan memenuhi persyaratan berikut:
- Akun read-only digunakan. Untuk informasi selengkapnya, lihat Buat dan kelola akun.
- Parameter readonly_lua_route_ronode_enable diatur ke 1 untuk instans Tair Anda. Nilai 1 menunjukkan bahwa skrip Lua yang hanya melakukan operasi baca akan dirutekan ke replika baca saja. Untuk informasi selengkapnya, lihat Konfigurasi parameter instans.
T: Apa perbedaan antara mode proxy dan mode koneksi langsung, serta mode mana yang direkomendasikan?
J: Mode proxy direkomendasikan. Berikut penjelasan dan perbandingannya:
- Mode proxy: Permintaan klien diteruskan oleh node proxy ke shard data. Mode ini memungkinkan penggunaan fitur seperti load balancing, Pemisahan baca/tulis, failover, proxy query cache, dan koneksi persisten.
- Mode koneksi langsung: Anda dapat melewati proxy dan langsung mengakses shard data backend menggunakan alamat koneksi langsung, mirip dengan menghubungkan ke kluster Redis native. Dibandingkan mode proxy, mode koneksi langsung menghemat waktu pemrosesan permintaan melalui proxy dan dapat meningkatkan kecepatan respons layanan Redis hingga batas tertentu.

T: Jika shard data backend menjadi abnormal, bagaimana dampaknya terhadap pembacaan dan penulisan data?

J: Shard data menggunakan arsitektur high-availability primary/secondary. Ketika node primary gagal, sistem secara otomatis melakukan failover primary/secondary untuk memastikan ketersediaan layanan yang tinggi. Dalam skenario langka di mana shard data menjadi abnormal, dampak terhadap data dan solusi optimasinya sebagai berikut.

Skenario	Dampak dan solusi optimasi
Gambar 1. Skenario perintah multi-key	Dampak: Klien mengirim empat permintaan melalui empat koneksi. Saat shard data 2 abnormal, hanya permintaan 1 (GET Key1) yang dapat membaca data secara normal. Permintaan lain yang mengakses shard data 2 akan timeout. Solusi optimasi: Kurangi frekuensi penggunaan perintah multi-key seperti MGET, atau kurangi jumlah kunci dalam satu permintaan. Hal ini mencegah seluruh permintaan gagal karena satu shard data abnormal. Kurangi frekuensi penggunaan perintah transaksi atau kurangi ukuran transaksi. Hal ini mencegah seluruh transaksi gagal karena sub-transaksi yang gagal.
Gambar 2. Skenario koneksi tunggal	Dampak: Klien mengirim dua permintaan terpisah melalui satu koneksi. Saat shard data 2 abnormal, permintaan 2 (GET Key2) akan timeout. Karena permintaan 1 (GET Key1) dan permintaan 2 berbagi koneksi yang sama, permintaan 1 juga gagal mengembalikan hasil secara normal. Solusi optimasi: Hindari atau kurangi penggunaan pipeline. Hindari menggunakan klien koneksi tunggal dan gunakan klien dengan kolam koneksi, seperti yang dijelaskan dalam Tutorial Koneksi Program Klien (Anda harus mengatur timeout dan ukuran kolam koneksi yang wajar).