全部产品
Search
文档中心

Tair (Redis® OSS-Compatible):Arsitektur standar

更新时间:Nov 11, 2025

Arsitektur standar Tair (Redis OSS-compatible) adalah arsitektur non-kluster yang menyimpan seluruh data dalam satu shard guna menjamin kemudahan penggunaan, keandalan, dan efisiensi biaya di berbagai skenario. Berbeda dengan arsitektur kluster, arsitektur standar tidak mendukung penyesuaian jumlah shard dan menyediakan tipe instans ketersediaan tinggi (multi-replika).

Ketersediaan tinggi

Arsitektur ketersediaan tinggi (HA) standar menerapkan model master-replika. Node master menangani beban kerja harian, sedangkan node replika tetap dalam mode hot standby untuk menjamin ketersediaan tinggi. Jika node master gagal, sistem akan mengalihkan beban kerja ke node replika dalam waktu 30 detik guna memastikan stabilitas layanan.

Arsitektur standar cloud-native

Instans cloud-native dapat terdiri dari satu node master dan hingga 9 node replika. Saat alih bencana HA dipicu di beberapa zona, sistem pertama-tama akan mencoba melakukan alih bencana dalam zona yang sama untuk menghindari akses lintas zona oleh aplikasi bisnis.

Arsitektur standar klasik

Instans klasik hanya terdiri dari satu node master dan satu node replika. Jika instans diterapkan di beberapa zona, node replika ditempatkan di zona sekunder.

Fitur

  • Keandalan

    • Keandalan layanan: Arsitektur HA standar menggunakan model master-replika dengan node master dan replika yang ditempatkan pada host fisik berbeda. Jika node master gagal, sistem HA proprietary akan melakukan alih bencana master-replika untuk memastikan kelangsungan operasi bisnis.

    • Keandalan data: Persistensi data diaktifkan secara default, sehingga semua data ditulis ke disk. Arsitektur ini mendukung pencadangan data. Anda dapat mengkloning atau memulihkan instans dari set cadangan untuk memulihkan data setelah kesalahan operasi. Instans yang dibuat di zona dengan kemampuan pemulihan bencana—seperti Hangzhou Zona H dan Zona I—mendukung pemulihan bencana antarzona.

  • Kompatibilitas: Arsitektur ini sepenuhnya kompatibel dengan protokol Redis. Anda dapat memigrasikan data secara mulus dari database Redis proprietary ke instans standar. Selain itu, Anda dapat menggunakan Alibaba Cloud Data Transmission Service (DTS) untuk memigrasikan data inkremental tanpa gangguan layanan.

  • Sistem proprietary internal

    • Sistem HA: Sistem HA proprietary digunakan untuk mendeteksi kegagalan pada node master—seperti kegagalan I/O disk dan CPU—serta melakukan alih bencana master-replika guna menjamin ketersediaan layanan.

    • Mekanisme replikasi master-replika: Masalah fork selama sinkronisasi data penuh antara node master dan replika telah diatasi untuk mencapai sinkronisasi non-blocking. Anda dapat menggunakan write-ahead log (WAL) untuk mereplikasi data antar node. Jika replikasi terputus, dampak terhadap kinerja dan stabilitas sistem minimal, sehingga mengatasi kelemahan mekanisme replikasi master-replika Redis native.

      Kerugian mekanisme replikasi Redis native

      • Jika replikasi terputus, node replika menjalankan perintah PSYNC untuk menyinkronkan ulang sebagian data. Jika penyinkronan ulang gagal, node master akan mengirim seluruh file Redis Database (RDB) ke node replika.

      • Untuk sinkronisasi penuh, node master melakukan replikasi data penuh melalui proses forking, yang menyebabkan latensi selama beberapa milidetik hingga beberapa detik.

      • Proses anak yang dibuat untuk menjalankan tugas copy-on-write (COW) mengonsumsi memori pada node master. Dalam skenario ekstrem, memori node master dapat habis dan menyebabkan aplikasi keluar secara tak terduga.

      • File replika yang dihasilkan oleh node master mengonsumsi sumber daya I/O disk dan CPU.

      • Replikasi file berukuran GB dapat menyebabkan lonjakan lalu lintas keluar pada server dan peningkatan throughput I/O sekuensial pada disk, sehingga menunda tanggapan dan memicu masalah tambahan.

Skenario

  • Aplikasi yang memerlukan kompatibilitas tinggi dengan protokol Redis

    Arsitektur standar kompatibel dengan protokol Redis, sehingga memungkinkan migrasi beban kerja ke instans standar tanpa gangguan layanan.

  • Aplikasi yang menggunakan Redis sebagai penyimpanan data persisten

    Arsitektur standar menyediakan mekanisme persistensi, pencadangan, dan pemulihan data untuk menjamin keandalan data.

  • Aplikasi dengan laju kueri stabil pada satu instans

    Database Redis native beroperasi dalam mode single-threaded. Jika beban kerja Anda memiliki laju kueri kurang dari 100.000 permintaan per detik (QPS), kami menyarankan penggunaan arsitektur standar. Untuk laju kueri yang lebih tinggi, aktifkan pemisahan baca/tulis atau gunakan arsitektur kluster.

  • Aplikasi dengan beban kerja pengurutan dan komputasi ringan yang memerlukan perintah Redis sederhana

    Kinerja CPU menjadi bottleneck utama karena mode single-threaded Redis native. Untuk memproses banyak beban kerja pengurutan dan komputasi, kami menyarankan penggunaan arsitektur kluster.

Pertanyaan Umum

  • Bisnis yang ada beroperasi dalam mode Redis Sentinel. Arsitektur apa yang harus saya pilih saat memigrasikan bisnis ke cloud?

    Kami menyarankan Anda memilih arsitektur HA standar. Setelah membuat instans, Anda dapat mengaktifkan mode kompatibel Sentinel untuk instans tersebut. Anda kemudian dapat terhubung ke Tair (dan Redis Edisi Open-Source) dengan cara yang sama seperti saat terhubung ke Redis Sentinel.

  • Jika sebuah instans memiliki memori 8 GB dan menggunakan arsitektur standar, bagaimana cara meningkatkan kinerja instans tanpa meningkatkan kapasitas memorinya?

    Kami menyarankan salah satu solusi berikut sesuai kebutuhan bisnis Anda:

    • Jika jumlah koneksi atau bandwidth tidak mencukupi, instans mungkin gagal menangani lalu lintas baca yang tinggi. Untuk meningkatkan kinerja baca tanpa menaikkan spesifikasi memori, kami menyarankan mengaktifkan pemisahan baca/tulis.

      Solusi ini siap pakai tanpa perlu memodifikasi kode bisnis atau titik akhir instans Anda, serta dapat dinonaktifkan kapan saja. Setelah diaktifkan, instans secara otomatis mengidentifikasi dan meneruskan permintaan baca dan tulis ke node yang sesuai, sehingga mendukung operasi baca dan tulis konkuren tinggi.

    • Jika pemanfaatan CPU instans terus-menerus tinggi, pertimbangkan peningkatan ke instans kluster. Dengan demikian, Anda dapat menambahkan shard data untuk mengurangi beban CPU pada satu shard.

      Namun, solusi ini melibatkan perubahan arsitektur instans, dan beberapa perintah mungkin tidak kompatibel antara arsitektur standar dan kluster. Untuk informasi lebih lanjut, lihat Batasan perintah untuk instans kluster dan instans dengan pemisahan baca/tulis. Sebelum melakukan peningkatan, evaluasi terlebih dahulu kompatibilitas dan dampak perubahan tersebut.

    Bagian berikut membandingkan kinerja instans Redis Edisi Open-Source berkapasitas 8 GB di bawah arsitektur yang berbeda.

    Arsitektur

    Memori (GB)

    Inti CPU

    Bandwidth (Mbit/s)

    Jumlah koneksi maksimum

    Nilai referensi QPS

    Arsitektur standar (node master dan replika)

    8

    2

    96

    20.000

    100.000

    Arsitektur standar (pemisahan baca/tulis diaktifkan, satu node master, satu replika baca)

    8

    4 (2 × 2)

    192 (96 × 2)

    40.000 (20.000 × 2)

    200.000

    Arsitektur kluster (2 shard)

    8 (4 GB × 2 shard)

    4 (2 × 2)

    192 (96 × 2)

    40.000 (20.000 × 2)

    200.000

Referensi

Kelola node