Analisis ringkas tentang kegigihan RDB dan AOF, apakah kelebihan dan kekurangannya? Bagaimana untuk memilih?

Artikel ini akan membincangkan prinsip kegigihan RDB dan AOF dalam redis Apakah kelebihan dan kekurangannya? Analisis yang mana satu harus digunakan? Semoga ia membantu semua orang!

Redis menyediakan dua penyelesaian kegigihan: RDB dan AOF:

• RDB: Menghasilkan petikan data dalam memori Redis ialah fail binari dumpr.rdb

• AOF: merekodkan semua arahan tulis Redis kecuali pertanyaan, dan laksanakan semula arahan ini apabila perkhidmatan Redis bermula.

Kegigihan RDB

Secara lalai, Redis akan mengekalkan data dalam satu tempoh masa ke cakera keras dalam bentuk petikan RDB, menyimpan ia sebagai dumpr.rdb Fail binari. [Cadangan berkaitan: Tutorial video Redis]

Pengenalan ringkas kepada prinsip kerja:

Apabila Redis perlu diteruskan, Redis akan berhenti proses Kanak-kanak, proses kanak-kanak menulis data ke fail RDB sementara pada cakera. Apabila proses anak selesai menulis fail sementara, gantikan RDB asal Kelebihan ini ialah ia boleh copy-on-write.

Sudah tentu kita juga boleh melaksanakan secara manual save atau bgsave (tak segerak) untuk menjana fail RDB.

konfigurasi lalai redis.conf

save 900  1
save 300  10
save 60  10000

• Jika lebih daripada 1 kekunci diubah suai dalam masa 900 saat, penjimatan syot kilat akan dimulakan
• Selepas 300 saat Dalam 60 saat, jika lebih daripada 10 kekunci diubah suai, simpan syot kilat dimulakan;
• Dalam masa 60 saat, jika 10,000 kekunci diubah suai, simpan syot kilat dimulakan; >
Arahan syot kilat RDB

Secara lalai, Redis menyimpan petikan pangkalan data dalam fail binari bernama dump.rdb. Anda boleh menetapkan Redis untuk menyimpan set data secara automatik apabila syarat "set data mempunyai sekurang-kurangnya M perubahan dalam N saat" dipenuhi.

Anda juga boleh membenarkan Redis menyimpan set data secara manual dengan memanggil

atau

.

Sebagai contoh, tetapan berikut akan menyebabkan Redis menyimpan set data secara automatik apabila ia memenuhi syarat "sekurang-kurangnya 1000 kekunci telah ditukar dalam masa 60 saat": SAVEBGSAVE

Ini Kaedah kegigihan ini dipanggil syot kilat.

save 60 1000

Prinsip penciptaan RDB

Apabila Redis perlu menyimpan fail dump.rdb, pelayan menjalankan operasi berikut:

Redis memanggil fork() dan mempunyai kedua-dua proses ibu bapa dan anak.

Proses kanak-kanak menulis set data ke fail RDB sementara.

• Apabila proses anak selesai menulis ke fail RDB baharu, Redis menggantikan fail RDB asal dengan fail RDB baharu dan memadamkan fail RDB lama.
• Cara kerja ini membolehkan Redis mendapat manfaat daripada mekanisme salin atas tulis.

Kelebihan RDB

RDB ialah fail yang agak padat yang menyimpan data Redis pada masa tertentu Data jenis ini Lebih sesuai untuk sandaran dan pemulihan bencana. Sebagai contoh, anda boleh menyandarkan fail RDB setiap jam dalam 24 jam yang lalu, dan juga menyandarkan fail RDB setiap hari dalam bulan tersebut. Dengan cara ini, walaupun anda menghadapi masalah, anda sentiasa boleh memulihkan set data kepada versi yang berbeza.

Kelemahan RDB

Jika anda perlu meminimumkan kehilangan data sekiranya berlaku kegagalan pelayan, maka RDB bukan untuk anda. Walaupun Redis membenarkan anda menetapkan titik simpan yang berbeza untuk mengawal kekerapan menyimpan fail RDB, ia bukanlah satu operasi yang mudah kerana fail RDB perlu menyimpan keadaan keseluruhan set data. Oleh itu, anda boleh menyimpan fail RDB sekurang-kurangnya sekali setiap 5 minit. Dalam kes ini, sekiranya berlaku gangguan, anda mungkin kehilangan beberapa minit data.

Kegigihan AOF

menggunakan AOF untuk kegigihan Setiap arahan tulis dilampirkan pada fail melalui fungsi .

AOF boleh mencapai ketekunan penuh hanya perlu dihidupkan dalam fail konfigurasi (lalainya ialah tidak write Selepas menghidupkan AOF, setiap kali Redis melaksanakan perintah untuk mengubah suai data, ia akan. ditambahkan pada fail AOF, apabila Redis dimulakan semula, fail AOF akan dibaca dan "dimainkan semula" untuk dipulihkan ke saat terakhir sebelum Redis ditutup. appendonly.aof

appendfsync yesKonfigurasi AOF

Anda boleh mengkonfigurasi kekerapan Redis menyegerakkan data ke cakera. konfigurasi lalai redis.conf

mempunyai tiga pilihan:

1, laksanakan fsync setiap kali arahan baharu dilampirkan pada fail AOF : sangat perlahan dan sangat selamat.
2, fsync sekali sesaat : cukup pantas (kira-kira sama seperti menggunakan kegigihan RDB), dan hanya kehilangan 1 saat data sekiranya berlaku kegagalan.
3, jangan sesekali fsync: Serahkan data kepada sistem pengendalian untuk diproses. Pilihan yang lebih pantas dan kurang selamat.

Langkah yang disyorkan (dan lalai) ialah fsync sekali sesaat. Strategi fsync ini boleh mengimbangi kelajuan dan keselamatan.

Prinsip penciptaan AOF

Penulisan semula AOF, seperti penciptaan syot kilat RDB, menggunakan mekanisme salin atas-tulis dengan bijak.

Berikut ialah langkah pelaksanaan penulisan semula AOF :

Redis melaksanakan fork() dan kini mempunyai proses induk dan anak.

Proses kanak-kanak mula menulis kandungan fail AOF baharu ke fail sementara.

Untuk semua arahan tulis yang baru dilaksanakan, proses induk mengumpulnya ke dalam cache memori dan menambahkan perubahan ini pada penghujung fail AOF sedia ada: Dengan cara ini, walaupun penutupan berlaku di tengah-tengah penulisan semula, Fail AOF sedia ada masih selamat.

Apabila proses anak menyelesaikan kerja penulisan semula, ia menghantar isyarat kepada proses induk Selepas menerima isyarat, proses induk menambahkan semua data dalam cache memori ke penghujung fail AOF baharu.

Selesai! Redis kini secara atom menggantikan fail lama dengan yang baharu, dan semua arahan selepas itu dilampirkan terus ke penghujung fail AOF baharu.

Kelebihan AOF

1 Menggunakan AOF untuk kegigihan, anda boleh menetapkan strategi fsync yang berbeza, seperti tanpa fsync, fsync sekali sesaat. , atau fsync setiap kali arahan tulis dilaksanakan.

Dasar lalai AOF ialah menyegerak sekali sesaat Di bawah konfigurasi ini, Redis masih boleh mengekalkan prestasi yang baik, dan walaupun kegagalan berlaku, hanya satu saat data akan hilang paling banyak.

fsync akan dilaksanakan pada utas latar belakang, jadi utas utama boleh terus bekerja keras memproses permintaan arahan.

2. Fail AOF ialah fail log yang hanya menjalankan operasi tambah Cakera penuh, penulisan dihentikan di tengah jalan, dsb.), alat redis-check-aof juga boleh menyelesaikan masalah ini dengan mudah.

3. Redis boleh menulis semula AOF secara automatik di latar belakang apabila saiz fail AOF menjadi terlalu besar: fail AOF baharu yang ditulis semula mengandungi set perintah minimum yang diperlukan untuk memulihkan set data semasa.

Keseluruhan operasi penulisan semula adalah benar-benar selamat, kerana penulisan semula Redis mencipta fail AOF baharu dan akan terus menambahkan arahan pada fail AOF lama sedia ada semasa proses penulisan semula, walaupun ralat berlaku semasa proses penulisan semula Walaupun jika terdapat penutupan, fail AOF lama yang sedia ada tidak akan hilang. Setelah fail AOF baharu dibuat, Redis akan bertukar daripada fail AOF lama kepada fail AOF baharu dan mula melampirkan fail AOF baharu.

4. Fail AOF menyimpan semua operasi tulis yang dilakukan pada pangkalan data dengan teratur Operasi tulis ini disimpan dalam format protokol Redis, jadi kandungan fail AOF sangat mudah dibaca. Analisis (parse) juga mudah. Mengeksport fail AOF juga sangat mudah: Contohnya, jika anda secara tidak sengaja melaksanakan perintah _FLUSH ALL_ (kosongkan data keseluruhan pelayan Redis (padam semua kunci dalam semua pangkalan data).), tetapi selagi fail AOF belum ditulis ganti , kemudian selagi anda menghentikan pelayan, alih keluar perintah FLUSHALL pada penghujung fail AOF dan mulakan semula Redis, anda boleh memulihkan set data kepada keadaan sebelum FLUSHALL telah dilaksanakan.

Kelemahan AOF

Untuk set data yang sama, saiz fail AOF biasanya lebih besar daripada fail RDB.

AOF mungkin lebih perlahan daripada RDB bergantung pada strategi fsync yang digunakan. Dalam keadaan biasa, prestasi fsync sesaat masih sangat tinggi, dan mematikan fsync boleh menjadikan AOF sepantas RDB, walaupun di bawah beban berat.

Walau bagaimanapun, RDB boleh memberikan kependaman maksimum yang lebih terjamin apabila mengendalikan beban tulis yang besar.

Perbezaan antara RDB dan AOF

Kegigihan RDB merujuk kepada menulis petikan set data dalam memori ke cakera dalam selang masa yang ditentukan Proses operasi sebenar Ia adalah untuk memotong proses anak dan mula-mula menulis set data ke dalam fail sementara Selepas penulisan berjaya, fail sebelumnya diganti dan disimpan menggunakan pemampatan binari.

Kegigihan AOF merekodkan setiap operasi tulis dan padam yang diproses oleh pelayan dalam bentuk log Operasi tidak akan direkodkan dalam bentuk teks. Anda boleh membuka fail untuk melihat operasi terperinci rekod.

RDB atau AOF yang manakah harus saya gunakan?

Jika anda sangat mengambil berat tentang data anda tetapi masih mampu menanggung kehilangan data dalam beberapa minit, maka anda hanya boleh menggunakan kegigihan RDB.

AOF menambahkan setiap arahan yang dilaksanakan oleh Redis pada cakera Memproses penulisan besar akan mengurangkan prestasi Redis.

Sandaran Pangkalan Data dan Pemulihan Bencana:

Menjana syot kilat RDB secara kerap adalah sangat mudah untuk sandaran pangkalan data, dan RDB memulihkan set data lebih cepat daripada AOF.

Redis menyokong pembukaan RDB dan AOF pada masa yang sama Selepas sistem dimulakan semula, Redis akan memberi keutamaan untuk menggunakan AOF untuk memulihkan data, supaya data yang hilang akan menjadi paling sedikit.

AOF BGREWRITEAOF tulis semula

Oleh kerana AOF berfungsi dengan menambahkan arahan secara berterusan ke penghujung fail, jadi apabila bilangan arahan bertulis terus meningkat, fail AOF saiz juga akan menjadi lebih besar dan lebih besar.

Sebagai contoh

Jika anda memanggil INCR 100 kali pada kaunter, maka hanya untuk menyimpan nilai semasa kaunter, fail AOF diperlukan Gunakan 100 penyertaan .

Namun, sebenarnya, menggunakan hanya satu arahan SET sudah cukup untuk menyimpan nilai semasa kaunter, dan baki 99 rekod sebenarnya berlebihan.

Untuk mengendalikan situasi ini, Redis menyokong ciri menarik: Fail AOF boleh dibina semula tanpa mengganggu klien perkhidmatan.

Laksanakan perintah BG REWRITE AOF, Redis akan menjana fail AOF baharu, yang mengandungi arahan minimum yang diperlukan untuk membina semula set data semasa.

Redis 2.2 memerlukan anda melaksanakan perintah BGREWRITEAOF secara manual; Redis 2.4 boleh mencetuskan penulisan semula AOF secara automatik Untuk maklumat khusus, sila lihat fail konfigurasi 2.4.

Sandarkan data Redis

Kegagalan cakera, kegagalan nod dan masalah lain boleh menyebabkan data anda hilang jika tidak membuat sandaran.

Redis sangat mesra untuk sandaran data, kerana anda boleh menyalin fail RDB semasa pelayan sedang berjalan: Setelah fail RDB dibuat, tiada pengubahsuaian akan dibuat. Apabila pelayan ingin mencipta fail RDB baharu, ia mula-mula menyimpan kandungan fail dalam fail sementara Apabila fail sementara ditulis, program menggunakan nama semula(2) untuk menggantikan fail RDB asal dengan fail sementara secara atom.

Ini bermakna ia benar-benar selamat untuk menyalin fail RDB pada bila-bila masa.

Berikut ialah cadangan kami:

1 Cipta tugas biasa (cron job), sandarkan fail RDB ke folder setiap jam dan sandarkannya setiap jam sandarkan fail RDB ke folder lain.

2 Pastikan sandaran syot kilat mempunyai maklumat tarikh dan masa yang sepadan Setiap kali anda melaksanakan skrip tugas biasa, gunakan arahan cari untuk memadamkan syot kilat yang telah tamat tempoh: Sebagai contoh, anda boleh menyimpan syot kilat dalam tempoh yang terakhir. 48 jam gambar setiap jam, dan gambar harian untuk satu atau dua bulan terakhir juga boleh disimpan.

3. Sekurang-kurangnya sekali sehari, sandarkan RDB di luar pusat data anda, atau sekurang-kurangnya di luar mesin fizikal tempat anda menjalankan pelayan Redis.

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Video Pengaturcaraan! !

Atas ialah kandungan terperinci Analisis ringkas tentang kegigihan RDB dan AOF, apakah kelebihan dan kekurangannya? Bagaimana untuk memilih?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!