Redis adalah database nilai kunci tingkat lanjut. Ini mirip dengan memcached, tetapi data dapat dipertahankan dan tipe datanya kaya. Ada string, daftar tertaut, set, dan koleksi yang diurutkan. Ini mendukung perhitungan penjumlahan, interpotongan, dan pelengkap (perbedaan) koleksi di sisi server, dan juga mendukung berbagai fungsi penyortiran. Jadi Redis juga bisa dilihat sebagai server struktur data.
Semua data Redis disimpan dalam memori dan kemudian disimpan ke disk secara asinkron dari waktu ke waktu (ini disebut "mode semi-persisten"); Anda juga dapat menulis setiap perubahan data ke dalam File Hanya Tambahkan (AOF) (ini disebut "mode persistensi penuh").
Metode pertama adalah filesnapshotting: Redis default akan menyimpan data ke disk dalam bentuk snapshot (file biner, dump.rdb, nama file ini dapat ditentukan), dan format dalam file konfigurasi adalah: save N M berarti bahwa dalam N detik, redis akan mengambil snapshot ke disk jika setidaknya M modifikasi terjadi di redis. Tentu saja, kita juga dapat melakukan save atau bgsave (asinkron) secara manual untuk mengambil snapshot.
Berikut adalah pengantar singkat tentang cara kerjanya: Ketika Redis perlu bertahan, Redis akan melakukan fork proses anak; Proses turunan menulis data ke file RDB sementara pada disk; Ketika subproses selesai menulis file sementara, itu menggantikan RDB asli, yang memiliki keunggulan copy-on-write
Ada juga metode persistensi Append-only:filesnapshotting method Ketika redis mati secara tidak normal, data terbaru akan hilang (jumlah data yang hilang tergantung pada konfigurasi kebijakan penyimpanan Anda), jadi ini adalah kelemahan terbesarnya, ketika volume bisnis besar, data yang hilang banyak. Metode append-only dapat mencapai semua kehilangan data, tetapi kinerja redis lebih buruk. AOF dapat dipertahankan selama proses, hanya perlu diaktifkan dalam file konfigurasi (defaultnya adalah tidak), appendonly ya Setelah AOF diaktifkan, setiap kali redis menjalankan perintah untuk memodifikasi data, itu akan ditambahkan ke file aof, dan ketika redis dimulai ulang, file AOF akan dibaca untuk "replay" untuk dipulihkan ke saat terakhir sebelum redis ditutup.
Penulisan Ulang LOG Saat file AOF menjadi lebih besar dan lebih besar saat data dimodifikasi, banyak di antaranya mencatat perubahan dalam kunci. Oleh karena itu, redis memiliki fitur yang menarik: merekonstruksi file AOF di latar belakang tanpa memengaruhi operasi sisi klien. Menjalankan perintah BGREWRITEAOF kapan saja akan menulis urutan perintah terpendek dalam memori saat ini ke disk, dan perintah ini dapat sepenuhnya membangun situasi data saat ini tanpa perubahan yang tidak perlu (seperti perubahan status, perubahan penghitung, dll.), mengurangi ukuran file AOF. Jadi saat menggunakan OF, redis merekomendasikan untuk menggunakan BGREWRITEAOF juga.
Ada tiga cara untuk menyegarkan file AOF, lihat parameter konfigurasi appendfsync: appendfsync selalu memanggil fsync untuk mengolas ke file AOF setiap kali perintah modifikasi dikirimkan, yang sangat, sangat lambat, tetapi juga sangat aman; appendfsync everysec memanggil fsync setiap detik untuk mengolas ke file AOF, dengan cepat, tetapi mungkin kehilangan data dalam satu detik; appendfsync tidak mengandalkan OS untuk menyegarkan, redis tidak secara aktif menyegarkan OV, yang merupakan yang tercepat, tetapi keamanannya buruk. Refresh per detik direkomendasikan secara default, sehingga kecepatan dan keamanan diperhitungkan.
Mungkin karena alasan sistem bahwa AOF rusak, redis tidak dapat lagi memuat OV ini, Anda dapat mengikuti langkah-langkah di bawah ini untuk memperbaikinya: Pertama, buat cadangan file AOF dan salin ke tempat lain; Perbaiki file OF asli, jalankan: $redis-check-aof –fix; Anda dapat menggunakan perintah diff –u untuk melihat di mana file tidak konsisten sebelum dan sesudah perbaikan. Mulai ulang layanan Redis.
Cara kerja LOG Rewrite: Hal yang sama menggunakan copy-on-write: redis pertama akan melakukan fork proses turunan; Proses turunan menulis AOF terbaru ke file sementara; Proses induk secara bertahap menulis perubahan terbaru yang dieksekusi dalam memori (saat ini, AOF lama masih ditulis, dan aman untuk menulis ulang jika gagal); Ketika proses turunan selesai menulis ulang file sementara, proses induk menerima sinyal dan menulis perubahan inkremental sebelumnya dalam memori ke akhir file sementara. Redis mengganti nama file OF lama, mengganti nama file sementara, dan mulai menulis ke OF baru.
Terakhir, untuk berjaga-jaga (mesin mogok atau disk crash), ingatlah untuk secara teratur mencadangkan file *rdb *.aof yang dihasilkan menggunakan filesnapshotting atau Append-only ke mesin jarak jauh. Saya menggunakan crontab untuk SCP setiap setengah jam. Saya tidak menggunakan fungsi master-slave redis, karena cadangan setengah jam seharusnya baik-baik saja, dan saya merasa itu sedikit membuang-buang mesin jika Anda memiliki master-slave. Ini pada akhirnya tergantung pada aplikasinya.
|
Diposting pada 24/08/2017 16.37.45
|
|
|
