Tair (Redis® OSS-Compatible)：Batasan

Catatan Penggunaan

• Setiap instans anak harus berupa instans berbasis DRAM.

  Spesifikasi setiap instans anak harus sama. Jika Anda ingin mengubah spesifikasi instans anak, disarankan untuk menyesuaikan semua instans anak ke spesifikasi yang sama. Ketidaksesuaian spesifikasi pada instans terdistribusi dapat menyebabkan masalah performa atau kapasitas.

• Sebuah instans terdistribusi dapat mencakup hingga tiga instans anak, yang tidak boleh berada di zona yang sama. Instans anak pertama dapat dikonversi dari instans yang sudah ada, sedangkan instans anak kedua dan ketiga harus berupa instans baru yang dibeli.

• Semua instans anak dalam sebuah instans terdistribusi harus berlokasi di daratan Tiongkok atau di wilayah di luar daratan Tiongkok. Untuk menyinkronkan data lintas batas dari daratan Tiongkok ke wilayah lain, gunakan Data Transmission Service (DTS). Informasi lebih lanjut dapat ditemukan di Ajukan izin untuk menyinkronkan data lintas batas.

• Instans anak dalam sebuah instans terdistribusi memiliki batasan berikut:

  • Zona instans tidak dapat diubah.

  • Arsitektur instans tidak dapat diubah, misalnya dari arsitektur kluster ke arsitektur standar.

  • Saat mengubah konfigurasi instans kluster, Anda dapat menyesuaikan spesifikasi shard atau jumlah shard. Untuk informasi lebih lanjut, lihat Mengapa saya tidak dapat mengubah konfigurasi instans kluster klasik (berbasis disk lokal)?

Batasan pada perintah yang dapat disinkronkan

• Perintah FLUSHDB atau FLUSHALL tidak dapat disinkronkan.

  • Untuk membersihkan data, jalankan perintah FLUSHALL pada semua instans anak. Jika tidak, inkonsistensi data dapat terjadi.

  • Untuk menyinkronkan ulang data, misalnya dari Instans A ke Instans B, hapus Instans B dari instans terdistribusi, jalankan perintah FLUSHALL pada Instans B, lalu sambungkan kembali Instans B ke instans terdistribusi.

• Perintah Pub dan Sub tidak dapat disinkronkan. Untuk mereplikasi pesan notifikasi di seluruh domain, disarankan menggunakan struktur data Stream.

• Perintah RESTORE yang disinkronkan ke instans tujuan hanya dapat dijalankan jika instans tujuan tidak berisi kunci dengan nama yang sama dengan yang ditentukan.

• Perintah DEL yang dihasilkan oleh pengusiran data dan kedaluwarsa tidak disinkronkan.

Batasan pada granularitas sinkronisasi

Batasan pada konsistensi data

• Dalam skenario di mana satu instans anak dapat ditulis, seperti skenario pemulihan bencana, data akhir harus konsisten di semua instans anak. Inkonsistensi data dapat terjadi dalam situasi berikut:

  • Operasi pada kunci dengan waktu hidup tertentu (TTL) dapat menyebabkan inkonsistensi data karena latensi sinkronisasi. Misalnya, perintah EXPIRE berhasil dijalankan pada Instans Anak A untuk memperpanjang sebuah kunci, tetapi data telah kedaluwarsa saat disinkronkan ke Instans Anak B. Untuk memastikan konsistensi data yang tinggi, hindari menentukan TTL untuk instans Global Distributed Cache.

  • Kunci untuk pengusiran data di setiap instans anak bersifat independen dan dipilih secara acak. Pastikan penggunaan memori tidak melebihi spesifikasi instans untuk menghindari pemicuan pengusiran data.

• Dalam skenario di mana beberapa instans anak dapat ditulis, seperti skenario redundansi geo aktif, pastikan sistem bisnis Anda tidak memodifikasi kunci yang sama di beberapa instans anak pada saat yang sama atau dalam interval singkat. Jika tidak, Global Distributed Cache tidak dapat menjamin bahwa nilai akhir dari kunci tersebut sama di setiap instans anak, dan data dapat menumpuk di instans anak dalam skenario streaming di mana konflik dapat timbul karena monotonicity yang ketat. Tabel berikut menjelaskan jenis-jenis inkonsistensi data yang mungkin terjadi.

  Catatan

  Global Distributed Cache tidak mendukung tipe data replikasi tanpa konflik (CRDTs). Pastikan konsistensi data dalam sistem bisnis Anda.

  Inkonsistensi	Ilustrasi	Deskripsi
  Pembaharuan kunci gagal		Pada titik waktu 1, Instans Anak A dan B memegang kunci dengan TTL tertentu. Kunci tersebut kedaluwarsa pada titik waktu 3. Pada titik waktu 2, Instans Anak A menjalankan perintah PEXPIREAT untuk memperbarui kunci ke titik waktu 5. Pada titik waktu 3, Instans Anak B tidak menerima perintah sinkronisasi PEXPIREAT dari Instans Anak A karena latensi jaringan. Pada saat yang sama, kunci di Instans Anak B dihapus karena kedaluwarsa. Pada titik waktu 4, Instans Anak B menerima perintah ekstensi untuk kunci tersebut, tetapi perintah ekstensi gagal dijalankan karena kunci telah dihapus karena kedaluwarsa. Dalam hal ini, Instans Anak A masih memegang kunci, sedangkan kunci di Instans Anak B hilang.
  Hasil eksekusi perintah yang tidak konsisten karena TTL		Perintah SMOVE digunakan dalam contoh berikut. Pada titik waktu 1, Instans Anak A dan B memegang Key1 dan Key2. Key1 kedaluwarsa pada titik waktu 3, dan Key2 tidak memiliki TTL yang dikonfigurasi. Pada titik waktu 2, Instans Anak A menjalankan perintah SMOVE Key1 Key2 "foo" untuk memindahkan anggota "foo" ke Key2. Pada titik waktu 3, Instans Anak B tidak menerima perintah sinkronisasi dari Instans Anak A karena latensi jaringan. Pada saat yang sama, Key1 di Instans Anak A dan B dihapus karena kedaluwarsa. Pada titik waktu 4, Instans Anak B menerima perintah SMOVE, tetapi perintah SMOVE gagal dijalankan karena Key1 dihapus karena kedaluwarsa. Dalam hal ini, Key2 di Instans Anak A berisi anggota "foo", tetapi Key2 di Instans Anak B tidak berisi anggota "foo".
  Pengusiran data acak		Pada titik waktu 1, Instans Anak A dan B memegang Key1 dan Key2. Pada titik waktu 2, memori Instans Anak A habis, pengusiran data dipicu, dan Key2 dihapus secara acak. Pada titik waktu 3, memori Instans Anak B habis, pengusiran data dipicu, dan Key1 dihapus secara acak. Kebijakan pengusiran data default adalah volatile-lru, dan operasi penghapusan selama pengusiran data tidak disinkronkan. Oleh karena itu, data Instans Anak A dan B tidak konsisten.
  Penulisan data ke beberapa instans anak - pertukaran nilai		Jika sebuah kunci ditulis ke beberapa instans anak pada saat yang sama, data mungkin tidak konsisten. Pada titik waktu 1, Key:valA ditulis ke Instans Anak A. Pada titik waktu 2, Key:valB ditulis ke Instans Anak B. Pada titik waktu 3, Instans Anak A menyinkronkan Key:valA ke Instans Anak B. Pada saat yang sama, Instans Anak B menyinkronkan Key:valB ke Instans Anak A. Setelah sinkronisasi selesai, nilai-nilai kunci bertukar antara dua instans anak.
  Penulisan data ke beberapa instans anak - tipe data tidak konsisten		Pada titik waktu 1, sebuah Key bertipe data Hash ditulis ke Instans Anak A. Pada titik waktu 2, sebuah Key bertipe data String ditulis ke Instans Anak B. Saat perintah sinkronisasi dijalankan pada titik waktu 3, kegagalan terjadi karena konflik tipe data.
  Penulisan data ke beberapa instans anak - kondisi penulisan tidak terpenuhi		Pada titik waktu 1, SETNX Key valA ditulis ke Instans Anak A. Pada titik waktu 2, SETNX Key valB ditulis ke Instans Anak B. Saat perintah sinkronisasi dijalankan pada titik waktu 3, kegagalan terjadi karena kondisi penulisan tidak terpenuhi. Catatan Perintah seperti HSETNX dan SET[NX | XX] juga menyebabkan masalah serupa.
  Penulisan data ke beberapa instans anak - data tidak beraturan atau hilang		Pada titik waktu 1, RPUSH Key valA ditulis ke Instans Anak A. Pada titik waktu 2, RPUSH Key valB ditulis ke Instans Anak B. Saat perintah sinkronisasi dijalankan pada titik waktu 3, data tidak beraturan atau hilang. Catatan Perintah seperti LPUSH, APPEND, DEL, HDEL, INCR, dan XADD juga menyebabkan masalah serupa.