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

Pada instans Tair (Redis OSS-compatible) yang menggunakan arsitektur kluster atau arsitektur pemisahan baca/tulis, node proxy bertanggung jawab atas routing permintaan, load balancing, dan failover. Node proxy dapat menyederhanakan logika sisi klien serta mendukung fitur lanjutan seperti beberapa database (DB) dan caching hotkey. Memahami aturan routing node proxy serta cara menangani perintah tertentu membantu Anda merancang sistem bisnis yang lebih efisien.

Ikhtisar node proxy

Node proxy adalah komponen mandiri dalam instans Tair. Komponen ini tidak mengonsumsi sumber daya shard data. Tair menggunakan beberapa node proxy untuk menerapkan load balancing dan failover.

Kemampuan	Deskripsi
Transisi mode penggunaan untuk instans kluster	Node proxy dapat menjembatani arsitektur, memungkinkan Anda menggunakan instans dengan arsitektur kluster seolah-olah merupakan instans standalone. Node proxy mendukung operasi cross-slot untuk perintah yang mengelola beberapa kunci, seperti DEL, EXISTS, MGET, MSET, SDIFF, dan UNLINK. Untuk informasi selengkapnya, lihat Daftar perintah yang didukung dalam modus proxy. Saat instans dengan arsitektur standalone tidak lagi memenuhi kebutuhan bisnis Anda, Anda dapat memigrasikan data ke instans dengan arsitektur kluster yang menggunakan node proxy tanpa mengubah kode Anda. Hal ini secara signifikan mengurangi biaya transformasi bisnis.
Load balancing dan routing permintaan	Node proxy membuat koneksi persisten dengan shard data backend dan menangani routing serta load balancing permintaan. Untuk informasi selengkapnya tentang routing, lihat Aturan routing node proxy.
Mengelola traffic ke replika baca	Node proxy terus memantau status replika baca dan mengendalikan traffic dalam situasi berikut: Replika baca berada dalam kondisi abnormal: Node proxy mengurangi bobot layanan replika tersebut. Jika node proxy gagal terhubung ke replika tersebut beberapa kali, node tersebut berhenti mengirimkan traffic ke replika tersebut. Node proxy melanjutkan pengiriman traffic setelah replika pulih. Replika baca sedang melakukan sinkronisasi data penuh: Node proxy sementara berhenti mengirimkan traffic ke replika tersebut hingga proses sinkronisasi selesai.
Proxy query cache	Setelah Anda mengaktifkan fitur proxy query cache, node proxy menyimpan cache permintaan yang berisi hotkey beserta respons yang sesuai. Saat node proxy menerima permintaan yang sama dalam periode validitas cache, node tersebut langsung mengembalikan hasilnya ke klien tanpa berinteraksi dengan shard data backend. Hal ini membantu mengurangi ketimpangan akses yang disebabkan oleh banyaknya permintaan baca ke hotkey. Catatan Anda dapat mengaktifkan fitur ini dengan mengatur parameter query_cache_enabled parameter. Fitur ini hanya tersedia untuk instans Tair Memory-optimized dan Persistent Memory-optimized.
Dukungan untuk beberapa database (DB)	Dalam mode kluster, Redis native dan klien kluster tidak mendukung beberapa database (DB). Mereka hanya menggunakan database default `0` dan tidak mendukung perintah `SELECT`. Namun, Anda dapat terhubung ke instans kluster melalui node proxy untuk menggunakan beberapa DB dan perintah `SELECT`. Instans Edisi Kluster mendukung 256 DB secara default. Catatan Jika Anda menggunakan klien StackExchange.Redis, Anda harus menggunakan versi 2.7.20 atau yang lebih baru. Jika tidak, akan terjadi error. Untuk informasi selengkapnya, lihat Pengumuman peningkatan StackExchange.Redis.

Catatan

Seiring perkembangan teknologi proxy, jumlah node proxy bukan satu-satunya faktor yang menentukan kapasitas pemrosesan. Alibaba Cloud memastikan rasio node proxy dalam instans kluster memenuhi persyaratan yang ditentukan.

Aturan routing node 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, node proxy mengirim permintaan ke shard data yang sesuai berdasarkan slot tempat kunci tersebut berada. Untuk perintah yang beroperasi pada beberapa kunci yang disimpan di shard data berbeda, node proxy membagi perintah menjadi beberapa perintah dan mengirimkannya ke shard yang sesuai. Catatan Mulai dari Redis Open-Source Edition 5.0.1, serta versi 6.0, 7.0, dan seterusnya, node proxy membagi perintah berdasarkan level slot, yang konsisten dengan komunitas Redis. Namun, pada versi minor Redis Open-Source Edition 5.0 sebelum 5.0.1, serta versi 4.0 dan 2.8, Proxy membagi perintah berdasarkan level shard. Saat instans tersebut ditingkatkan ke Redis Open-Source Edition 5.0 atau yang lebih baru, perubahan aturan pembagian perintah ini dapat menyebabkan peningkatan QPS dan sedikit peningkatan traffic. Namun, karena Proxy mengirimkan perintah menggunakan pipeline, dampak terhadap performa relatif kecil.
Arsitektur kluster	Aturan routing untuk perintah tertentu	Perintah Pub/Sub Untuk perintah Pub/Sub seperti SUBSCRIBE, node proxy menghitung hash dari nama channel dan mengarahkan permintaan ke shard data yang sesuai. Meskipun perintah Pub/Sub tidak menulis data ke database, perintah tersebut tetap mengonsumsi memori dan sumber daya. Konsumsi ini terutama disebabkan oleh koneksi klien, manajemen status langganan, dan buffer pesan. Sebagai contoh, jika sebuah channel termasuk dalam shard data 1, klien yang berlangganan channel tersebut akan mengonsumsi memori, CPU, dan bandwidth jaringan dari shard data 1. Catatan Di Konsol Tair, Anda dapat membuka halaman Pemantauan Performa, memilih Data Node, lalu memilih Pub/Sub Monitoring Group dari daftar metrik kustom. Hal ini memungkinkan Anda melihat informasi pemantauan untuk perintah terkait Pub/Sub di setiap shard data. Secara default, data untuk shard data pertama yang ditampilkan. Perintah yang dikembangkan Alibaba Cloud Saat Anda menggunakan perintah yang dikembangkan Alibaba Cloud, seperti IINFO dan ISCAN, Anda dapat menentukan ID shard data menggunakan parameter idx. Node proxy kemudian mengirimkan perintah tersebut ke shard data yang ditentukan. Untuk informasi selengkapnya, lihat Perintah proxy yang dikembangkan Alibaba Cloud.
Arsitektur pemisahan baca/tulis	Aturan routing dasar	Permintaan tulis: Node proxy meneruskan permintaan tulis langsung ke node master. Permintaan baca: Node proxy mendistribusikan permintaan baca secara merata di antara node master dan replika baca. Penyesuaian distribusi tidak didukung. Sebagai contoh, pada instans dengan satu node master dan tiga replika baca, masing-masing dari empat node tersebut menangani 25% permintaan baca. Catatan SLOWLOG dan DBSIZE juga dianggap sebagai perintah baca.
Arsitektur pemisahan baca/tulis	Aturan routing untuk perintah tertentu	Perintah SCAN Saat Anda menjalankan perintah HSCAN, SSCAN, atau ZSCAN, node proxy pertama-tama menghitung slot tempat kunci tersebut berada. Kemudian, node tersebut menggunakan operasi modulo untuk menentukan node target. Hal ini memastikan permintaan didistribusikan secara merata antara node master dan replika baca. Perintah yang dikembangkan Alibaba Cloud Saat Anda menggunakan perintah yang dikembangkan Alibaba Cloud, seperti RIINFO dan RIMONITOR, gunakan parameter ro_slave_idx untuk menentukan replika baca target dan parameter idx untuk menentukan shard data. Untuk informasi selengkapnya, lihat Perintah proxy yang dikembangkan Alibaba Cloud. Perintah lainnya Node proxy meneruskan perintah transaksi (MULTI atau EXEC), perintah skrip Lua (EVAL atau EVALSHA), SCAN, INFO, dan perintah Pub/Sub (seperti PUBLISH dan SUBSCRIBE) ke node master.

Proxy query cache

Node proxy dapat menyimpan cache permintaan yang berisi hotkey beserta hasil kueri yang sesuai. Saat node proxy menerima permintaan yang sama dalam periode validitas cache, node tersebut langsung mengembalikan hasilnya ke klien tanpa berinteraksi dengan shard data backend. Fitur ini dapat mengurangi atau mencegah degradasi performa akibat ketimpangan akses yang disebabkan oleh volume tinggi permintaan baca ke hotkey.

Kernel database mengidentifikasi hotkey menggunakan algoritma pengurutan dan statistik, mirip dengan Hot Key (QPS) dalam fitur Analisis Top Key. Secara default, kunci diidentifikasi sebagai hotkey jika QPS-nya melebihi 5.000. Anda juga dapat menyesuaikan ambang batas ini menggunakan parameter bigkey-threshold.
Jika hotkey dimodifikasi saat datanya masih dalam cache, perubahan tersebut tidak disinkronkan ke cache. Artinya, permintaan berikutnya mungkin membaca data kedaluwarsa dari cache hingga entri cache tersebut kedaluwarsa. Anda dapat memperpendek periode validitas cache sesuai kebutuhan bisnis Anda.

Catatan

Node proxy tidak menyimpan cache seluruh hotkey. Sebaliknya, node tersebut menyimpan cache permintaan yang berisi hotkey beserta hasil kueri yang sesuai.
Fitur ini hanya tersedia untuk instans Tair Memory-optimized dan Persistent Memory-optimized yang menggunakan arsitektur kluster dalam modus proxy atau arsitektur pemisahan baca/tulis.

Kasus penggunaan

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

Arsitektur

Penggunaan

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

Parameter

Parameter	Deskripsi

query_cache_enabled
query_cache_expire
query_cache_mode

Anda dapat menggunakan perintah QUERYCACHE KEYS, QUERYCACHE INFO, dan QUERYCACHE LISTALL yang dikembangkan Tair untuk melihat penggunaan cache kueri proxy Tair.

Perintah

QUERYCACHE KEYS

Sintaks: QUERYCACHE KEYS

Deskripsi: Menanyakan semua hotkey yang di-cache di node proxy. Perintah ini mengembalikan nama database dan nama kunci untuk setiap hotkey.

Contoh:

QUERYCACHE KEYS

Respons contoh:

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

Sintaks: QUERYCACHE INFO

Deskripsi: Mengambil status operasional cache kueri proxy.

Contoh:

QUERYCACHE INFO

Respons 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"

Bidang respons:

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

QUERYCACHE LISTALL

Sintaks: QUERYCACHE LISTALL

Deskripsi: Mengambil semua perintah permintaan yang di-cache.

Contoh:

QUERYCACHE LISTALL

Respons contoh:

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 contoh: Informasi untuk setiap perintah permintaan terdiri dari tiga baris: nama database, konten lengkap perintah permintaan (diformat sesuai spesifikasi protokol Redis), dan sisa waktu hidup (TTL) dalam milidetik.

Penggunaan koneksi

Umumnya, node proxy membuat koneksi persisten dengan shard data untuk memproses permintaan. Namun, saat permintaan mencakup salah satu perintah berikut, node proxy membuat koneksi tambahan yang tidak dapat diagregasi pada shard data yang sesuai berdasarkan kebutuhan perintah tersebut. Dalam kasus ini, jumlah maksimum koneksi untuk instans dibatasi oleh batas koneksi satu shard data. Untuk informasi tentang batas koneksi satu shard, lihat spesifikasi instans Anda. Gunakan perintah-perintah ini dengan hati-hati agar tidak melebihi batas koneksi.

Catatan

Dalam modus proxy, jumlah maksimum koneksi untuk setiap shard data adalah 10.000 untuk instans Redis Open-Source Edition dan 30.000 untuk instans Tair (Enterprise Edition).

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?
Ya, Anda dapat meneruskan skrip Lua yang hanya melakukan operasi baca ke replika baca. Namun, persyaratan berikut harus dipenuhi:
- 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 diarahkan ke replika baca. Untuk informasi selengkapnya, lihat Konfigurasi parameter instans.
T: Apa perbedaan antara modus proxy dan mode koneksi langsung? Mode mana yang direkomendasikan?
J: Kami merekomendasikan penggunaan modus proxy. Perbedaannya sebagai berikut:
- Modus proxy: node proxy meneruskan permintaan klien ke shard data. Mode ini menyediakan fitur seperti load balancing, pemisahan baca/tulis, failover, proxy query cache, dan koneksi persisten.
- Mode koneksi langsung: Anda dapat menggunakan titik akhir koneksi langsung untuk melewati node proxy dan terhubung langsung ke shard data backend. Ini mirip dengan menghubungkan ke kluster Redis native. Dibandingkan dengan modus proxy, mode koneksi langsung mengurangi overhead pemrosesan proxy dan meningkatkan latensi respons.

T: Bagaimana pembacaan dan penulisan data terpengaruh jika shard data backend menjadi tidak tersedia?

Setiap shard data menggunakan arsitektur master-replika dengan ketersediaan tinggi. Jika node master gagal, sistem secara otomatis melakukan failover untuk memastikan ketersediaan tinggi. Tabel berikut menjelaskan dampak kegagalan shard data terhadap pembacaan dan penulisan data dalam skenario ekstrem serta memberikan solusi optimasi.

Skenario	Dampak dan optimasi
Gambar 1. Perintah multi-kunci	Dampak: Klien mengirim empat permintaan melalui empat koneksi. Jika shard data 2 tidak tersedia, hanya Permintaan 1 (GET Key1) yang berhasil membaca data. Permintaan yang diarahkan ke shard data 2 mengalami timeout. Optimasi: Kurangi penggunaan perintah multi-kunci, seperti MGET, atau kurangi jumlah kunci dalam satu permintaan. Hal ini mencegah seluruh permintaan gagal karena satu shard data yang tidak tersedia. Kurangi penggunaan perintah transaksi atau perkecil ukuran transaksi. Hal ini mencegah kegagalan sub-transaksi menyebabkan seluruh transaksi gagal.
Gambar 2. Koneksi tunggal	Dampak: Klien mengirim dua permintaan terpisah melalui satu koneksi. Jika shard data 2 tidak tersedia, Permintaan 2 (GET Key2) mengalami timeout. Karena Permintaan 1 (GET Key1) berbagi koneksi yang sama, permintaan tersebut juga gagal mengembalikan hasil. Optimasi: Hindari atau kurangi penggunaan pipeline. Hindari penggunaan klien yang hanya mendukung satu koneksi. Kami merekomendasikan Anda menggunakan klien yang mendukung pooling koneksi. Untuk informasi selengkapnya, lihat Tutorial koneksi klien. Pastikan Anda mengonfigurasi timeout dan ukuran kolam koneksi yang wajar.