Contoh analisis kegigihan AOF dalam Redis

1. Pengenalan kepada AOF

RDB ialah kaedah kegigihan yang boleh merekodkan status pangkalan data dengan menyimpan pasangan nilai kunci dalam pangkalan data. AOF ialah kaedah kegigihan yang menyimpan keadaan pangkalan data dengan merekodkan arahan tulis yang dilaksanakan oleh pelayan Redis.

Contohnya, untuk arahan berikut:

　

Kaedah kegigihan RDB adalah untuk menyimpan tiga pasangan nilai kunci str1, str2, str3 ke dalam Fail RDB, dan kegigihan AOF menyimpan perintah set, sadd, dan lpush yang dilaksanakan ke fail AOF.

2. Konfigurasi AOF

Dalam fail konfigurasi redis.conf di bawah MOD APPEND SAHAJA:

　①, lampirkan: Nilai lalai ialah tidak, yang bermaksud bahawa redis menggunakan kegigihan rdb secara lalai Jika anda ingin mendayakan kegigihan AOF, anda perlu menukar lampiran kepada ya.

　②, appendfilename: daripada nama fail, lalainya ialah "appendonly.aof"

　③, appendfsync: konfigurasi strategi kegigihan;

tidak bermaksud untuk tidak melaksanakan fsync, dan sistem pengendalian memastikan bahawa data disegerakkan ke cakera, yang merupakan yang terpantas, tetapi tidak begitu selamat

sentiasa bermakna fsync dilaksanakan untuk setiap tulis untuk memastikan penyegerakan data ke cakera, kecekapan adalah sangat rendah

Pilihan "everysec" yang melaksanakan fsync sekali sesaat boleh menyebabkan data hilang dalam masa 1 saat ini. Biasanya pilih everysec untuk mengimbangi keselamatan dan kecekapan.

　④, no-appendfsync-on-rewrite: Apabila aof ditulis semula atau ditulis pada fail rdb, sejumlah besar IO akan dilakukan Pada masa ini, untuk setiap mod setiap saat dan sentiasa aof, melaksanakan fsync akan menyebabkan penyekatan terlalu lama, medan no-appendfsync-on-rewrite ditetapkan kepada tidak secara lalai. Jika aplikasi mempunyai keperluan kependaman yang tinggi, medan ini boleh ditetapkan kepada ya, jika tidak, ia ditetapkan kepada tidak, yang merupakan pilihan yang lebih selamat untuk ciri kegigihan. Menetapkannya kepada ya bermakna bahawa operasi tulis baharu tidak akan disegerakkan semasa penulisan semula, dan akan disimpan sementara dalam memori, dan akan ditulis selepas penulisan semula selesai. Lalai ialah tidak, dan ya disyorkan. Dasar fsync lalai Linux ialah 30 saat. 30 saat data mungkin hilang. Nilai lalai ialah tidak.

Nilai lalai peratusan auto-aof-rewrite ialah 100. konfigurasi penulisan semula automatik aof, apabila saiz fail aof semasa melebihi peratusan saiz fail aof yang ditulis semula terakhir, ia akan ditulis semula, iaitu, apabila fail aof berkembang ke saiz tertentu, Redis boleh memanggil bgrewriteaof untuk menulis semula fail log . Apabila saiz fail AOF mencapai dua kali ganda saiz penulisan semula log terakhir (ditetapkan kepada 100), proses penulisan semula log baharu akan dimulakan secara automatik.

auto-aof-rewrite-min-size ditetapkan kepada 64MB. Untuk mengelakkan keperluan untuk menulis semula apabila peratusan yang dipersetujui dicapai, anda boleh menetapkan saiz fail minimum.

　⑦, aof-load-truncated: Fail aof mungkin tidak lengkap pada penghujung Apabila redis bermula, data fail aof dimuatkan ke dalam memori. Mulakan semula mungkin berlaku selepas sistem pengendalian hos di mana redis terletak, terutamanya jika sistem fail ext4 tidak menambah pilihan data=tertib Fenomena ini berlaku atau penamatan tidak normal pilih untuk membiarkan redis keluar , atau mengimport sebanyak mungkin data. Sebaik sahaja pilihan ya dipilih, log akan dihantar secara automatik kepada klien dan dimuatkan apabila fail aof yang dipotong diimport. Jika jawapannya tidak, pengguna perlu menjalankan perintah redis-check-aof secara manual untuk membaiki fail AOF. Nilai lalai ialah ya.

3 Hidupkan AOF

Tukar konfigurasi lampiran redis.conf kepada ya.

　Lokasi tempat AOF menyimpan fail adalah sama dengan lokasi RDB menyimpan fail ia dikonfigurasikan melalui dir fail konfigurasi redis.conf:

　

<.>Boleh dikonfigurasikan melalui config get Arahan dir mendapat laluan yang disimpan.

4. Pemulihan fail AOF

Selepas memulakan semula Redis, fail AOF akan dimuatkan.

Perintah pembaikan pengecualian: redis-check-aof --fix untuk membaiki

5 AOF menulis semula

Memandangkan kegigihan AOF bermakna Redis terus merekod arahan tulis ke AOF Dalam fail. , apabila Redis terus maju, fail AOF akan menjadi lebih besar dan lebih besar Semakin besar fail, semakin banyak memori pelayan akan diduduki dan semakin lama masa pemulihan AOF. Untuk menyelesaikan masalah ini, Redis telah menambah mekanisme penulisan semula baharu Apabila saiz fail AOF melebihi ambang yang ditetapkan, Redis akan memulakan pemampatan kandungan fail AOF, hanya mengekalkan set arahan minimum yang boleh memulihkan data. Anda boleh menggunakan arahan bgrewriteaof untuk menulis semula.

Contohnya, untuk arahan berikut:

Jika penulisan semula fail AOF tidak dilakukan, maka fail AOF akan menyimpan empat arahan SADD Jika AOF menulis semula digunakan, maka Hanya perintah berikut akan dikekalkan dalam fail AOF:

1	sadd animals "dog" "tiger" "panda" "lion" "cat"

　Maksudnya, penulisan semula fail AOF tidak menyusun semula fail asal, tetapi membaca secara langsung pasangan nilai kunci sedia ada pelayan, dan kemudian menggunakan arahan untuk menggantikan nilai kunci yang direkodkan sebelum ini berpasangan. Berbilang arahan untuk menjana fail baharu dan menggantikan fail AOF yang asal.

Mekanisme pencetus penulisan semula fail AOF: melalui peratusan auto-aof-rewrite dalam fail konfigurasi redis.conf: nilai lalai ialah 100 dan auto-aof-rewrite-min-size: konfigurasi 64mb , maksudnya, secara lalai Redis akan merekodkan saiz AOF apabila ia terakhir ditulis semula Konfigurasi lalai adalah untuk mencetuskan apabila saiz fail AOF adalah dua kali ganda saiz selepas penulisan semula terakhir dan fail lebih besar daripada 64M.

Biar saya nyatakan di sini sekali lagi bahawa kita tahu bahawa Redis ialah kerja satu utas Jika mengambil masa yang lama untuk menulis semula AOF, Redis tidak akan dapat bekerja lama semasa menulis semula AOF Berurusan dengan arahan lain, ini jelas tidak boleh ditoleransi. Untuk mengatasi masalah ini, penyelesaian Redis ialah meletakkan program penulisan semula AOF ke dalam subrutin Ini mempunyai dua faedah:

　① Semasa penulisan semula AOF proses anak, proses pelayan (proses induk) boleh Diteruskan. memproses arahan lain.

Menggunakan proses anak dan bukannya benang boleh mengelak daripada menggunakan kunci dan memastikan keselamatan data, kerana proses anak mempunyai salinan data proses induk.

Menggunakan sub-proses menyelesaikan masalah di atas, tetapi masalah baharu juga timbul: kerana proses pelayan masih memproses arahan lain semasa AOF menulis semula sub-proses, arahan baharu ini juga mungkin menjalankan operasi pada pangkalan data . Operasi pengubahsuaian menjadikan status pangkalan data semasa dan status fail AOF yang ditulis semula tidak konsisten.

Untuk menyelesaikan masalah status data yang tidak konsisten, pelayan Redis menyediakan penimbal tulis semula AOF ini digunakan selepas proses anak dibuat Apabila pelayan Redis melaksanakan arahan tulis, ia akan Ini arahan tulis juga dihantar ke penimbal tulis semula AOF. Apabila proses anak melengkapkan penulisan semula AOF, ia akan menghantar isyarat kepada proses induk Selepas proses induk menerima isyarat, ia akan memanggil fungsi untuk menulis kandungan penimbal penulisan semula AOF ke fail AOF baharu.

Ini meminimumkan kesan penulisan semula AOF pada pelayan.

6. Kelebihan dan Kekurangan AOF

Kelebihan:

① kaedah kegigihan AOF menyediakan pelbagai frekuensi penyegerakan, walaupun kekerapan penyegerakan lalai digunakan untuk menyegerakkan. kedua Pada satu masa, Redis hanya kehilangan 1 saat data paling banyak.

　② Fail AOF dibina menggunakan perintah Redis append Oleh itu, walaupun Redis hanya boleh menulis serpihan arahan pada fail AOF, adalah mudah untuk membetulkan fail AOF menggunakan alat redis-check-aof.

Format fail AOF mudah dibaca, yang membolehkan pengguna memprosesnya dengan lebih fleksibel. Sebagai contoh, jika kami secara tidak sengaja menggunakan arahan FLUSHALL secara tidak sengaja, sebelum penulisan semula sedang dijalankan, kami boleh mengalih keluar perintah FLUSHALL terakhir secara manual dan kemudian menggunakan AOF untuk memulihkan data.

Kelemahan:

① Untuk Redis dengan data yang sama, fail AOF biasanya lebih besar daripada fail RDF.

Kekerapan penyegerakan lalai AOF adalah sekali sesaat, walaupun ia menyediakan pelbagai pilihan kekerapan penyegerakan, tetapi prestasinya masih tinggi. Apabila beban Redis tinggi, RDB memberikan jaminan prestasi yang lebih baik daripada AOF.

　③, RDB menggunakan syot kilat untuk mengekalkan keseluruhan data Redis, manakala AOF hanya menambahkan setiap arahan yang dilaksanakan pada fail AOF, jadi secara teori, RDB lebih teguh daripada AOF. Menurut dokumentasi rasmi, AOF mempunyai beberapa pepijat yang tidak ada pada RDB.

Jadi bagaimana kita harus memilih antara kaedah kegigihan AOF dan RDB?

Jika anda boleh bertolak ansur dengan kehilangan data dalam tempoh yang singkat, tidak syak lagi bahawa menggunakan RDB adalah yang terbaik Menjana syot kilat RDB secara kerap adalah sangat mudah untuk sandaran pangkalan data, dan RDB memulihkan set data lebih cepat daripada Kelajuan pemulihan AOF harus pantas, dan menggunakan RDB juga boleh mengelakkan beberapa pepijat tersembunyi AOF, jika tidak, gunakan penulisan semula AOF. Walau bagaimanapun, secara amnya disyorkan untuk tidak menggunakan mekanisme kegigihan tertentu sahaja, tetapi menggunakan kedua-duanya bersama-sama Dalam kes ini, apabila redis dimulakan semula, fail AOF akan dimuatkan terlebih dahulu untuk memulihkan data asal, kerana dalam keadaan biasa Set data disimpan. dalam fail AOF adalah lebih lengkap daripada set data yang disimpan dalam fail RDB. Mungkin pada masa hadapan, pegawai Redis akan menggabungkan dua kaedah kegigihan ke dalam satu mod kegigihan.

Atas ialah kandungan terperinci Contoh analisis kegigihan AOF dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!