Ketahui tentang RDB dan kegigihan AOP dalam redis dalam satu artikel

Artikel ini akan membawa anda melalui dua mekanisme kegigihan (RDB dan AOP) dalam redis Saya harap ia akan membantu anda!

Redis ialah pangkalan data dalam memori, dan data disimpan dalam memori Walau bagaimanapun, kita semua tahu bahawa data dalam memori berubah dengan cepat dan mudah hilang. Nasib baik, Redis juga menyediakan kami dengan mekanisme kegigihan, iaitu RDB (Redis DataBase) dan AOF (Append Only File). [Cadangan berkaitan: Tutorial video Redis]

Di sini diandaikan bahawa anda sudah memahami sintaks asas redis Tapak web abjad tertentu mempunyai tutorial yang bagus, anda boleh menyemaknya. Saya tidak akan menulis artikel tentang penggunaan asas, semuanya adalah arahan yang biasa digunakan.

Berikut ialah pengenalan kepada dua kaedah ini. Dari cetek ke dalam.

1. Proses kegigihan

Memandangkan data redis boleh disimpan pada cakera, apakah rupa proses ini?

Lima proses berikut diperlukan:

(1) Pelanggan menghantar operasi tulis ke pelayan (data berada dalam ingatan klien).

(2) Pelayan pangkalan data menerima data permintaan tulis (data berada dalam ingatan pelayan).

(3) Pelayan memanggil panggilan sistem tulis untuk menulis data ke cakera (data berada dalam penimbal memori sistem).

(4) Sistem pengendalian memindahkan data dalam penimbal kepada pengawal cakera (data berada dalam cache cakera).

(5) Pengawal cakera menulis data ke medium fizikal cakera (data sebenarnya jatuh pada cakera).

5 proses ini adalah proses penjimatan biasa dalam keadaan yang ideal, tetapi dalam kebanyakan kes, mesin kami, dsb. akan mengalami pelbagai kegagalan:

(1) Jika Redis pangkalan data gagal, selagi langkah ketiga di atas selesai, ia boleh diteruskan dan disimpan, dan sistem pengendalian akan menyelesaikan dua langkah yang tinggal untuk kita.

(2) Jika sistem pengendalian gagal, 5 langkah di atas mesti diselesaikan.

Di sini kami hanya mempertimbangkan kemungkinan kegagalan semasa proses menyimpan Malah, data yang disimpan juga mungkin rosak, memerlukan mekanisme pemulihan tertentu, tetapi ini tidak akan dilanjutkan di sini. Pertimbangan utama sekarang ialah bagaimana redis melaksanakan lima langkah menyimpan cakera di atas. Ia menyediakan dua mekanisme dasar, iaitu RDB dan AOF.

2. Mekanisme RDB

RDB sebenarnya menyimpan data pada cakera dalam bentuk syot kilat. Apakah syot kilat? Anda boleh memahaminya sebagai mengambil foto data pada masa semasa dan menyimpannya.

Kegigihan RDB merujuk kepada menulis syot kilat bagi set data dalam memori pada cakera dalam selang masa yang ditentukan. Ia juga merupakan kaedah kegigihan lalai Kaedah ini menulis data dalam memori ke fail binari dalam bentuk petikan Nama fail lalai ialah dump.rdb.

Selepas kami memasang redis, semua konfigurasi berada dalam fail redis.conf, yang menyimpan pelbagai konfigurasi dua mekanisme kegigihan, RDB dan AOF.

Memandangkan mekanisme RDB menyimpan semua data pada masa tertentu dengan menjana syot kilat, mesti ada mekanisme pencetus untuk melaksanakan proses ini. Untuk RDB, tiga mekanisme disediakan: simpan, bgsave dan automasi. Mari kita lihat

1. Kaedah pencetus Simpan

Arahan ini akan menyekat pelayan Redis semasa menjalankan perintah simpan , Redis tidak boleh memproses arahan lain sehingga proses RDB selesai. Proses khusus adalah seperti berikut:

Jika terdapat fail RDB lama apabila pelaksanaan selesai, gantikan yang lama dengan yang baharu. Pelanggan kami mungkin berpuluh-puluh ribu atau ratusan ribu, jadi pendekatan ini jelas tidak digalakkan.

2. kaedah pencetus bgsave

Apabila arahan ini dilaksanakan, Redis akan melakukan operasi syot kilat secara tidak segerak di latar belakang dan syot kilat juga boleh menjawab soalan klien. Proses khusus adalah seperti berikut:

Operasi khusus ialah proses Redis melakukan operasi garpu untuk mencipta proses anak Proses kegigihan RDB bertanggungjawab untuk proses anak dan tamat secara automatik selepas selesai. Penyekatan hanya berlaku semasa fasa garpu dan secara amnya sangat singkat. Pada asasnya semua operasi RDB di dalam Redis menggunakan arahan bgsave.

3. Pencetusan automatik

Pencetusan automatik dilakukan oleh fail konfigurasi kami. Dalam fail konfigurasi redis.conf, terdapat konfigurasi berikut, yang boleh kami tetapkan:

①save: Ini digunakan untuk mengkonfigurasi keadaan kegigihan RDB yang mencetuskan Redis, iaitu, masa untuk menyimpan data dalam ingatan kepada cakera keras. Contohnya "simpan m n". Menunjukkan bahawa bgsave dicetuskan secara automatik apabila set data diubah suai n kali dalam m saat.

Konfigurasi lalai adalah seperti berikut:

# bermaksud jika sekurang-kurangnya 1 nilai kunci berubah dalam 900 saat, simpan 900 1# bermakna jika sekurang-kurangnya 10 nilai kunci berubah dalam masa 300 saat, simpan 300 10# bermakna jika sekurang-kurangnya 10 nilai kunci berubah dalam 60 saat Jika nilai 10000 kekunci berubah, maka simpan 60 10000

tidak memerlukan ketekunan, maka anda boleh mengulas semua simpan baris untuk melumpuhkan fungsi simpan.

②stop-writes-on-bgsave-error: Nilai lalai ialah ya. Apabila RDB didayakan dan penyimpanan data latar belakang terakhir gagal, sama ada Redis berhenti menerima data. Ini akan membuatkan pengguna sedar bahawa data tidak disimpan dalam cakera dengan betul, jika tidak, tiada siapa yang akan menyedari bahawa bencana telah berlaku. Jika Redis dimulakan semula, ia boleh mula menerima data semula

③rdbmampatan ialah ya. Untuk syot kilat yang disimpan pada cakera, anda boleh menetapkan sama ada untuk memampatkannya untuk penyimpanan.

④rdbchecksum: Nilai lalai ialah ya. Selepas menyimpan syot kilat, kami juga boleh membenarkan redis menggunakan algoritma CRC64 untuk pengesahan data, tetapi ini akan meningkatkan penggunaan prestasi sebanyak kira-kira 10%. Jika anda ingin mendapatkan peningkatan prestasi maksimum, anda boleh mematikan fungsi ini.

⑤dbfilename: Tetapkan nama fail syot kilat, lalainya ialah dump.rdb

⑥dir: Tetapkan laluan storan fail syot kilat ini mestilah direktori, bukan fail nama.

Kami boleh mengubah suai konfigurasi ini untuk mencapai kesan yang kami inginkan. Oleh kerana kaedah ketiga dikonfigurasikan, kami membandingkan dua yang pertama:

4 Kelebihan dan keburukan RDB

① Kelebihan

(1) Fail RDB padat dan disandarkan sepenuhnya, menjadikannya sangat sesuai untuk sandaran dan pemulihan bencana.

(2) Apabila menjana fail RDB, proses utama redis akan memotong() proses anak untuk mengendalikan semua kerja menyimpan Proses utama tidak perlu melakukan sebarang operasi IO cakera.

(3) RDB lebih pantas daripada AOF apabila memulihkan set data yang besar.

② Kelemahan

Syot kilat RDB ialah sandaran penuh, yang menyimpan bentuk data memori bersiri binari dan sangat padat dalam storan. Apabila ketekunan syot kilat dilakukan, proses anak akan dimulakan secara khusus untuk kegigihan syot kilat Proses anak akan memiliki data memori proses induk Pengubahsuaian pada memori oleh proses induk tidak akan ditunjukkan oleh proses anak data yang diubah suai semasa kegigihan syot kilat tidak akan dicerminkan disimpan, data mungkin hilang.

3. Mekanisme AOF

Sandaran penuh sentiasa memakan masa yang lebih berkesan arahan yang diterima dilampirkan pada fail melalui fungsi tulis. Pemahaman yang popular ialah pembalakan.

1 Prinsip Kegigihan

Lihat gambar di bawah untuk prinsipnya:

Apabila arahan tulis datang, ia disimpan terus dalam fail AOF kami.

2. Prinsip penulisan semula fail

Kaedah AOF juga membawa masalah lain. Fail kegigihan akan menjadi lebih besar dan lebih besar. Untuk memampatkan fail kegigihan aof. Redis menyediakan arahan bgrewriteaof. Simpan data dalam memori ke fail sementara dalam bentuk arahan, dan pada masa yang sama memotong proses baharu untuk menulis semula fail.

Kendalian menulis semula fail aof tidak membaca fail aof lama, tetapi menulis semula keseluruhan kandungan pangkalan data dalam ingatan kepada yang baharu menggunakan fail aof, iaitu agak serupa dengan syot kilat.

3 AOF juga mempunyai tiga mekanisme pencetus

(1) Penyegerakan untuk setiap pengubahsuaian sentiasa: kegigihan penyegerakan akan dicetuskan setiap kali data perubahan berlaku Serta-merta rakaman ke cakera mempunyai prestasi yang lemah tetapi integriti data yang baik

(2) Penyegerakan setiap saat: operasi tak segerak, rakaman setiap saat Jika mesin mati dalam masa satu saat, data akan hilang

( 3) No berbeza: Jangan sesekali menyegerakkan

4. Kelebihan

(1) AOF boleh melindungi data daripada kehilangan dengan lebih baik, secara amnya AOF Operasi fsync akan dilakukan melalui benang latar belakang setiap 1 saat dan sehingga 1 saat data akan hilang. (2) Fail log AOF tidak mempunyai sebarang overhed pengalamatan cakera, prestasi penulisan sangat tinggi, dan fail tidak mudah rosak.

(3) Walaupun fail log AOF terlalu besar, operasi penulisan semula latar belakang tidak akan menjejaskan pembacaan dan penulisan pelanggan.

(4) Arahan fail log AOF direkodkan dengan cara yang sangat mudah dibaca Ciri ini sangat sesuai untuk pemulihan kecemasan pemadaman tidak sengaja. Sebagai contoh, seseorang secara tidak sengaja mengosongkan semua data menggunakan arahan flushall selagi penulisan semula latar belakang belum berlaku pada masa ini, fail AOF boleh disalin serta-merta, perintah flushall yang terakhir dipadamkan, dan kemudian fail AOF diletakkan semula. . Pulihkan semua data secara automatik melalui mekanisme pemulihan

5. Kelemahan

(1) Untuk data yang sama, fail log AOF biasanya lebih besar daripada fail snapshot data RDB

(2) Selepas AOF dihidupkan, QPS tulis yang disokong akan lebih rendah daripada QPS tulis yang disokong oleh RDB. Oleh kerana AOF biasanya dikonfigurasikan untuk menyegerakkan fail log sekali sesaat, sudah tentu, fsync sekali sesaat, prestasinya masih sangat tinggi

(3) Terdapat pepijat dalam AOF sebelum ini, dan datanya adalah diproses melalui log yang direkodkan oleh AOF Semasa pemulihan, data yang sama tidak dipulihkan.

4. Bagaimana untuk memilih antara RDB dan AOF

Jika anda memilih, kedua-duanya bersama-sama akan menjadi lebih baik. Kerana anda memahami dua mekanisme kegigihan, selebihnya bergantung pada keperluan anda sendiri Anda mungkin tidak semestinya memilih satu berdasarkan keperluan yang berbeza, tetapi ia biasanya digunakan dalam kombinasi. Terdapat gambar untuk diringkaskan:

Selepas membandingkan ciri ini, selebihnya terpulang kepada anda.

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

Atas ialah kandungan terperinci Ketahui tentang RDB dan kegigihan AOP dalam redis dalam satu artikel. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!