Bagaimana untuk mencapai pemulihan yang cepat dan kegigihan tanpa rasa takut akan masa henti di Redis

Bagaimana untuk mencapai pemulihan yang cepat dan kegigihan tanpa rasa takut akan masa henti di Redis? Artikel berikut akan membawa anda melaluinya, saya harap ia akan membantu anda!

Adalah wajar untuk berdikari, dan ia juga betul untuk disepadukan ke dalam bulatan Kuncinya adalah untuk mengetahui jenis kehidupan yang anda inginkan dan apa harga yang anda sanggup bayar untuknya.

Kami biasanya menggunakan Redis sebagai cache untuk meningkatkan prestasi respons baca Setelah Redis turun, semua data dalam memori akan hilang jika kami mengakses pangkalan data dan jumlah trafik yang banyak MySQL, ia boleh menyebabkan masalah yang lebih serius. [Cadangan berkaitan: Tutorial video Redis]

Selain itu, prestasi membaca perlahan-lahan daripada pangkalan data ke Redis pasti akan lebih pantas daripada mendapatkannya daripada Redis, yang juga akan menyebabkan tindak balas kepada perlahankan.

Untuk mencapai pemulihan pantas tanpa rasa takut akan masa henti, Redis telah mereka dua ciri pembunuh utama, iaitu log AOF (Tambah Hanya FAIL) dan syot kilat RDB.

Apabila mempelajari teknologi, anda biasanya hanya berhubung dengan titik teknikal yang berselerak, tanpa mewujudkan rangka kerja pengetahuan dan sistem seni bina yang lengkap dalam fikiran anda, dan tanpa pandangan yang sistematik. Ini akan menjadi sangat sukar, dan nampaknya anda boleh melakukannya pada pandangan pertama, tetapi kemudian anda akan melupakannya dan anda akan keliru.

Ikuti "Ma Ge Byte" untuk memahami Redis secara menyeluruh dan menguasai prinsip teras dan kemahiran praktikal Redis secara mendalam. Bina rangka kerja pengetahuan yang lengkap dan belajar menyusun keseluruhan sistem pengetahuan dari perspektif global.

Artikel ini tegar, saya cadangkan anda simpan, suka, bertenang dan baca, saya percaya anda akan untung banyak.

Dalam artikel sebelumnya, kami menganalisis struktur data teras, model IO, model benang Redis dan menggunakan pengekodan data yang sesuai mengikut data yang berbeza. Fahami dengan mendalam sebab-sebab mengapa ia sangat pantas!

Artikel ini akan menumpukan pada perkara berikut:

• Bagaimana untuk pulih dengan cepat selepas masa rehat?
• Jika mesin rosak, bagaimanakah Redis dapat mengelakkan kehilangan data?
• Apakah petikan memori RDB?
• Mekanisme pelaksanaan log AOF
• Apakah teknologi salin atas tulis?
• ….

Mata pengetahuan yang terlibat adalah seperti yang ditunjukkan dalam rajah:

Redis Panorama

Panorama boleh dikembangkan sekitar dua dimensi, iaitu:

Dimensi aplikasi: penggunaan cache, penggunaan kelompok, penggunaan struktur data yang bijak

Dimensi sistem: boleh dikelaskan kepada tiga tahap tertinggi

1. Prestasi tinggi: model benang, model IO rangkaian, struktur data, mekanisme kegigihan; -Replikasi hamba, Kelompok Sentinel, Kelompok berpecah;
2. Skala tinggi: pengimbangan beban

Bab siri Redis

berkisar pada peta minda berikut terokai rahsia mekanisme prestasi tinggi dan kegigihan Redis.

Mempunyai pandangan panorama dan kuasai pandangan sistem.

Pandangan sistem sebenarnya penting, pada tahap tertentu, apabila menyelesaikan masalah, mempunyai pandangan sistem bermakna anda boleh mencari dan menyelesaikan masalah dalam asas dan kaedah.

Petikan memori RDB, membolehkan pemulihan pantas daripada masa henti

65 Abang: Redis terputus atas sebab tertentu, yang akan menyebabkan semua trafik terkena Backend MySQL , saya memulakan semula Redis dengan segera, tetapi datanya disimpan dalam memori Mengapa masih tiada data selepas dimulakan semula.

65 Jangan risau, "Code Byte" akan membawa anda langkah demi langkah untuk memahami cara memulihkan Redis dengan cepat selepas ia ranap.

Data Redis disimpan dalam ingatan Adakah mungkin untuk mempertimbangkan untuk menulis data dalam memori ke cakera? Apabila Redis dimulakan semula, data yang disimpan pada cakera dipulihkan dengan cepat ke memori, supaya perkhidmatan biasa boleh disediakan selepas dimulakan semula.

65 Abang: Saya memikirkan satu penyelesaian Setiap kali operasi "tulis" dilakukan untuk mengendalikan memori, ia ditulis pada cakera pada masa yang sama

Penyelesaian ini mempunyai masalah maut: setiap kali Perintah tulis bukan sahaja menulis pada memori tetapi juga pada cakera Prestasi cakera terlalu perlahan berbanding dengan memori, yang akan menyebabkan prestasi Redis sangat berkurangan .

Snapshot Memori

65 Abang: Bagaimana untuk mengelakkan masalah penulisan serentak ini?

Kami biasanya menggunakan Redis sebagai cache, jadi walaupun Redis tidak menyimpan semua data, ia masih boleh diperolehi melalui pangkalan data, jadi Redis tidak akan menyimpan semua data yang digunakan oleh data Redis Kaedah "RDB "Data snapshot" untuk mencapai pemulihan pantas daripada masa henti.

65 Abang: Jadi apakah gambar memori RDB?

Semasa Redis melaksanakan arahan "tulis", data memori akan terus berubah. Petikan memori yang dipanggil merujuk kepada data status data dalam memori Redis pada masa tertentu.

Masa seperti membeku pada saat tertentu Apabila kita mengambil gambar, kita boleh merakam detik itu sepenuhnya melalui foto itu.

Redis adalah serupa dengan ini, ia menangkap data pada masa tertentu dalam bentuk fail dan menulisnya ke cakera. Fail syot kilat ini dipanggil Fail RDB ialah singkatan daripada Redis DataBase.

Redis melaksanakan syot kilat memori RDB dengan kerap, supaya tidak perlu menulis pada cakera setiap kali arahan "tulis" dilaksanakan, dan hanya perlu ditulis pada cakera apabila syot kilat memori dilaksanakan. Ia bukan sahaja memastikan ia cepat tetapi tidak rosak, ia juga mencapai ketahanan dan boleh pulih dengan cepat daripada masa henti.

Apabila melakukan pemulihan data, baca fail RDB terus ke dalam memori untuk melengkapkan pemulihan.

65 Abang: Data apa yang kamu ambil gambar? Atau berapa kerap mengambil gambar? Ini akan menjejaskan kecekapan pelaksanaan syot kilat.

65 Baguslah, saya mula memikirkan tentang kecekapan data. Dalam artikel sebelumnya, kami mengetahui bahawa model satu-benangnya menentukan bahawa kami harus mengelakkan operasi yang menyekat utas utama sebanyak mungkin dan mengelakkan penjanaan fail RDB daripada menyekat utas utama.

Strategi RDB generasi

Redis menyediakan dua arahan untuk menjana fail RDB:

• simpan: dilaksanakan oleh utas utama, yang akan menyekat ;
• bgsave: Panggil fungsi glibc fork untuk menjana proses anak untuk menulis fail RDB sepenuhnya dikendalikan oleh proses anak Proses induk terus memproses permintaan pelanggan dan menjana fail RDB konfigurasi.

65 Abang: Apabila mengambil "snapshot" data memori, adakah data memori masih boleh diubah suai? Iaitu, bolehkah arahan tulis diproses secara normal?

Pertama sekali, kita perlu menjelaskan dengan jelas bahawa mengelakkan penyekatan dan dapat mengendalikan operasi tulis semasa penjanaan fail RDB bukanlah perkara yang sama. Walaupun utas utama tidak disekat, untuk memastikan ketekalan data syot kilat, ia hanya boleh memproses operasi baca dan tidak boleh mengubah suai data syot kilat yang sedang dilaksanakan.

Jelas sekali, Redis tidak membenarkan operasi penulisan digantung untuk menjana RDB.

65 Abang: Bagaimanakah Redis boleh memproses permintaan tulis dan menjana fail RDB pada masa yang sama?

Redis menggunakan sistem pengendalian berbilang proses teknologi salin atas tulis COW (Copy On Write) untuk mencapai ketekunan syot kilat Mekanisme ini sangat menarik dan hanya sedikit orang yang tahu ia. COW berbilang proses juga merupakan penunjuk penting tentang keluasan pengetahuan pengaturcara.

Redis akan memanggil fungsi glibc fork untuk menjana proses anak semasa kegigihan Gambaran kegigihan dikendalikan sepenuhnya oleh proses anak dan proses induk terus memproses permintaan pelanggan.

Apabila proses anak baru dibuat, ia berkongsi segmen kod dan segmen data dalam ingatan dengan proses induk. Pada masa ini, anda boleh membayangkan proses bapa-anak sebagai kembar siam, berkongsi badan.

Ini adalah mekanisme sistem pengendalian Linux Untuk menjimatkan sumber memori, mereka harus dikongsi sebanyak mungkin. Pada masa ini apabila proses dipisahkan, hampir tiada perubahan jelas dalam pertumbuhan ingatan.

bgsave Proses kanak-kanak boleh berkongsi semua data memori utas utama, membaca data utas utama dan menulisnya ke fail RDB.

Apabila melaksanakan perintah SAVE atau perintah BGSAVE untuk mencipta fail RDB baharu, atur cara akan menyemak kunci dalam pangkalan data dan kunci tamat tempoh tidak akan disimpan ke fail RDB yang baru dibuat. .

Apabila utas utama melaksanakan perintah tulis untuk mengubah suai data, salinan data akan dibuat bgsave Proses kanak-kanak membaca data salinan dan menulisnya ke fail RDB, jadi utas utama boleh mengubah suai data asal secara langsung.

Ini bukan sahaja memastikan integriti syot kilat, tetapi juga membenarkan urutan utama mengubah suai data pada masa yang sama, mengelakkan kesan ke atas perniagaan biasa.

Redis akan menggunakan bgsave untuk mengambil gambar semua data dalam memori semasa Operasi ini diselesaikan oleh proses kanak-kanak di latar belakang, yang membolehkan utas utama mengubah suai data pada masa yang sama .

65 Abang: Bolehkah anda melaksanakan fail RDB setiap saat Dengan cara ini, walaupun terdapat masa henti, sehingga 1 saat data akan hilang.

Melaksanakan syot kilat data penuh terlalu kerap mempunyai dua overhed prestasi yang serius:

• Kerap menjana fail RDB dan menulisnya ke cakera menyebabkan tekanan cakera yang berlebihan. Nampaknya RDB sebelumnya belum dilaksanakan lagi, dan yang seterusnya mula dijana semula, jatuh ke dalam gelung tak terhingga.

• Keluar daripada sub-proses bgsave akan menyekat utas utama Semakin besar memori utas utama, semakin lama masa penyekatan.

Kebaikan dan Kelemahan

Kelajuan pemulihan syot kilat adalah pantas, tetapi kekerapan menjana fail RDB sukar dikawal Jika kekerapan terlalu rendah, data yang hilang akan lebih banyak;

RDB menggunakan pemampatan data binari untuk menulis ke cakera, dengan saiz fail yang kecil dan kelajuan pemulihan data yang pantas.

Selain gambar penuh RDB, Redis juga mereka bentuk log pasca tulis AOF Seterusnya, mari kita bincangkan tentang log AOF.

Log pasca tulis AOF untuk mengelakkan kehilangan data semasa masa henti

Log AOF menyimpan jujukan arahan berurutan bagi pelayan Redis Log AOF hanya merekodkan arahan yang mengubah suai ingatan itu.

Dengan mengandaikan bahawa log AOF merekodkan semua urutan arahan yang diubah suai sejak penciptaan contoh Redis, maka ingatan contoh Redis semasa boleh dipulihkan dengan melaksanakan semua arahan secara berurutan pada contoh Redis kosong, iaitu, "memainkan semula" keadaan struktur data.

Perbandingan antara log pratulis dan pasca tulis

Tulis Log Hadapan (WAL): Pengubahsuaian akan dibuat sebelum data sebenarnya ditulis. Data ditulis ke fail log, dan pemulihan kesalahan dijamin.

Sebagai contoh, log buat semula (redo log) dalam enjin storan MySQL Innodb ialah log data yang merekodkan pengubahsuaian Log pengubahsuaian direkodkan sebelum data sebenarnya diubah suai dan data diubah suai.

Log pasca tulis: Mula-mula laksanakan permintaan arahan "tulis", tulis data ke dalam memori, dan kemudian rekod log.

Format log

Apabila Redis menerima arahan "set key MageByte" untuk menulis data ke memori, Redis akan mengikuti perkara berikut format langkah untuk menulis fail AOF.

• "*3": Menunjukkan bahawa arahan semasa dibahagikan kepada tiga bahagian, setiap bahagian bermula dengan "nombor $", diikuti dengan "perintah, kunci, nilai" khusus bahagian itu.
• "Nombor": Menunjukkan saiz bait yang diduduki oleh bahagian perintah, kunci dan nilai ini. Contohnya, "$3" bermaksud bahagian ini mengandungi 3 bait, iaitu arahan "set".

65 Abang: Mengapa Redis menggunakan pengelogan pasca tulis?

Log pasca tulis mengelakkan overhed semakan tambahan dan tidak memerlukan semakan sintaks bagi arahan yang dilaksanakan. Jika anda menggunakan pengelogan tulis ke hadapan, anda perlu menyemak sama ada sintaks itu betul terlebih dahulu, jika tidak, log merekodkan arahan yang salah dan ralat akan berlaku apabila menggunakan pemulihan log.

Selain itu, log direkodkan selepas menulis, tidak akan menyekat pelaksanaan arahan "tulis" semasa.

65 Abang: Jadi dengan AOF, adakah ianya kalis?

Budak bodoh, ia tidak semudah itu. Jika Redis baru sahaja selesai melaksanakan arahan dan ranap sebelum merekodkan log, data yang berkaitan dengan arahan itu mungkin hilang.

Selain itu, AOF mengelak daripada menyekat perintah semasa, tetapi mungkin membawa risiko menyekat kepada arahan seterusnya. Log AOF dilaksanakan oleh utas utama Semasa proses menulis log ke cakera, jika tekanan cakera tinggi, penulisan ke cakera akan menjadi sangat perlahan, menyebabkan arahan "tulis" seterusnya disekat.

Adakah anda mendapati bahawa kedua-dua masalah ini berkaitan dengan tulis balik cakera Jika masa menulis log AOF kembali ke cakera selepas arahan "tulis" dilaksanakan boleh dikawal dengan munasabah, masalah itu akan diselesaikan.

Strategi tulis balik

Untuk meningkatkan kecekapan menulis fail, apabila pengguna memanggil fungsi write untuk menulis beberapa data pada fail, sistem pengendalian biasanya data bertulis akan disimpan sementara dalam penimbal memori, dan data dalam penimbal tidak akan ditulis pada cakera sehingga ruang penimbal diisi atau melebihi had masa yang ditentukan.

Walaupun pendekatan ini meningkatkan kecekapan, ia juga membawa isu keselamatan kepada data bertulis, kerana jika komputer dimatikan, data bertulis yang disimpan dalam penimbal memori akan hilang.

Untuk tujuan ini, sistem menyediakan dua fungsi penyegerakan, fsync dan fdatasync, yang boleh memaksa sistem pengendalian untuk segera menulis data dalam penimbal ke cakera keras, dengan itu memastikan keselamatan data bertulis.

Item konfigurasi AOF yang disediakan oleh RedisappendfsyncStrategi tulis balik secara langsung menentukan kecekapan dan keselamatan fungsi kegigihan AOF.

• sentiasa: Tulis balik segerak, kandungan dalam penimbal aof_buf akan dipadamkan ke fail AOF sejurus selepas arahan tulis dilaksanakan.
• everysec: Tulis semula setiap saat Selepas arahan tulis dilaksanakan, log hanya akan ditulis ke penimbal fail AOF dan kandungan penimbal akan disegerakkan ke cakera setiap saat. .
• tidak: Dikawal oleh sistem pengendalian, selepas pelaksanaan tulis selesai, log ditulis ke penimbal memori fail AOF, dan sistem pengendalian memutuskan masa untuk membuangnya ke cakera .

Tiada strategi terbaik dari kedua-dua dunia, kita perlu membuat pertukaran antara prestasi dan kebolehpercayaan.

alwaysTulis balik segerak boleh menghalang kehilangan data, tetapi setiap arahan "tulis" perlu ditulis pada cakera, yang mempunyai prestasi paling teruk.

everysecTulis balik setiap saat, mengelakkan overhed prestasi tulis balik segerak Sekiranya berlaku masa henti, data yang ditulis pada cakera mungkin hilang selama satu saat, membuat kompromi antara prestasi dan kebolehpercayaan.

noKawalan sistem pengendalian, selepas melaksanakan arahan tulis, ia ditulis ke penimbal fail AOF dan kemudian arahan "tulis" seterusnya boleh dilaksanakan Prestasinya adalah yang terbaik, tetapi banyak data mungkin hilang.

65 Abang: Jadi bagaimana saya harus memilih strategi?

Kita boleh memilih strategi tulis balik berdasarkan keperluan sistem untuk prestasi tinggi dan kebolehpercayaan yang tinggi. Untuk meringkaskan: Jika anda ingin memperoleh prestasi tinggi, pilih strategi Tiada jika anda ingin mendapatkan jaminan kebolehpercayaan yang tinggi, pilih strategi Sentiasa jika anda membenarkan sedikit kehilangan data tetapi mahu prestasi terjejas dengan ketara, kemudian pilih strategi Everysec .

Kebaikan dan Kelemahan

Kelebihan: Log direkodkan hanya selepas pelaksanaan berjaya, mengelakkan overhed penyemakan sintaks arahan. Pada masa yang sama, arahan "tulis" semasa tidak akan disekat.

Kelemahan: Memandangkan AOF merekodkan kandungan setiap arahan, sila lihat format log di atas untuk format khusus. Setiap arahan perlu dilaksanakan semasa pemulihan kerosakan Jika fail log terlalu besar, keseluruhan proses pemulihan akan menjadi sangat perlahan.

Selain itu, sistem fail juga mempunyai sekatan pada saiz fail yang terlalu besar tidak boleh disimpan Apabila fail menjadi lebih besar, kecekapan penambahan akan menjadi lebih rendah.

Log terlalu besar: Mekanisme penulisan semula AOF

65 Abang: Apa yang perlu saya lakukan jika fail log AOF terlalu besar?

Log pratulis AOF merekodkan setiap operasi arahan "tulis". Ia tidak akan menyebabkan kehilangan prestasi seperti petikan penuh RDB, tetapi kelajuan pelaksanaan tidak sepantas RDB Pada masa yang sama, fail log yang terlalu besar juga akan menyebabkan masalah prestasi Bagi lelaki sejati seperti Redis yang hanya mahu pantas. dia sama sekali tidak boleh bertolak ansur dengan masalah yang disebabkan oleh kayu balak yang terlalu besar.

Oleh itu, Redis telah mereka bentuk "mekanisme penulisan semula AOF" yang mematikan Redis menyediakan perintah bgrewriteaof untuk mengurangkan log AOF.

Prinsipnya adalah untuk membuka sub-proses untuk melintasi memori dan menukarnya kepada satu siri arahan operasi Redis, yang disiri menjadi fail log AOF baharu. Selepas bersiri selesai, log AOF tambahan yang berlaku semasa operasi dilampirkan pada fail log AOF baharu Selepas penambahan selesai, fail log AOF lama digantikan dengan serta-merta, dan kerja pelangsingan selesai.

65 Abang: Mengapa mekanisme penulisan semula AOF boleh mengecilkan fail log?

Mekanisme penulisan semula mempunyai fungsi "berbilang kepada satu", yang menukarkan berbilang arahan dalam log lama kepada satu arahan selepas menulis semula.

Seperti yang ditunjukkan di bawah:

Tiga arahan LPUSH, satu dijana selepas ditulis semula oleh AOF Untuk adegan yang telah diubah suai beberapa kali, kesan pengurangan adalah lebih jelas.

65 Abang: Selepas menulis semula, log AOF menjadi lebih kecil, dan akhirnya log operasi data terkini seluruh pangkalan data telah dibuang ke cakera. Adakah penulisan semula akan menyekat utas utama?

Seperti yang dinyatakan di atas, log AOF ditulis kembali oleh utas utama Proses penulisan semula AOF sebenarnya diselesaikan oleh sub-proses latar belakang bgrewriteaof untuk mengelakkan sekatan utas utama.

Proses penulisan semula

berbeza daripada log AOF yang ditulis semula oleh utas utama Proses penulisan semula diselesaikan oleh sub-proses latar belakang bgrewriteaof, yang juga untuk mengelak daripada menyekat utas utama, menyebabkan prestasi pangkalan data merosot.

Secara amnya, terdapat dua log kesemuanya, satu salinan data memori, iaitu log AOF lama dan log tulis semula AOF baharu dan salinan data Redis .

Redis akan merekodkan operasi arahan "tulis" yang diterima semasa proses penulisan semula kepada penimbal AOF lama dan penimbal tulis semula AOF pada masa yang sama, supaya log tulis semula juga menyimpan operasi terkini. Selepas semua rekod operasi data yang disalin ditulis semula, operasi terkini yang direkodkan dalam penimbal tulis semula juga akan ditulis ke fail AOF baharu.

Setiap kali AOF ditulis semula, Redis akan melakukan salinan memori terlebih dahulu untuk menjana rekod penulisan semula untuk memastikan data yang baru ditulis tidak akan hilang semasa proses penulisan semula dan mengekalkan data konsisten.

65 Abang: AOF menulis semula juga mempunyai log tulis semula, mengapa ia tidak berkongsi log menggunakan AOF itu sendiri?

Ini adalah soalan yang bagus untuk dua sebab berikut:

• Salah satu sebab ialah proses ibu bapa dan anak menulis fail yang sama pasti akan menyebabkan masalah persaingan. Kawal persaingan. Ini bermakna ia akan menjejaskan prestasi proses induk.

• Jika proses penulisan semula AOF gagal, fail AOF asal adalah bersamaan dengan tercemar dan tidak boleh dipulihkan. Oleh itu, Redis AOF menulis semula fail baru Jika penulisan semula gagal, hanya padamkan fail itu secara langsung. Selepas penulisan semula selesai, gantikan sahaja fail lama.

Model log hibrid Redis 4.0

Apabila memulakan semula Redis, kami jarang menggunakan rdb untuk memulihkan keadaan memori kerana banyak data akan hilang . Kami biasanya menggunakan main semula log AOF, tetapi prestasi main semula log AOF jauh lebih perlahan daripada RDB, jadi apabila kejadian Redis besar, ia mengambil masa yang lama untuk dimulakan.

Untuk menyelesaikan masalah ini, Redis 4.0 membawakan pilihan kegigihan baharu - Kegigihan hibrid. Simpan kandungan fail rdb bersama-sama dengan fail log AOF tambahan. Log AOF di sini bukan lagi log penuh, tetapi log AOF tambahan yang berlaku dalam tempoh dari awal kegigihan hingga akhir kegigihan Biasanya bahagian log AOF ini sangat kecil.

Jadi apabila Redis dimulakan semula, anda boleh memuatkan kandungan rdb dahulu, dan kemudian memainkan semula log AOF tambahan, yang boleh menggantikan main semula fail penuh AOF sebelumnya sepenuhnya, dan kecekapan mulakan semula bertambah baik.

Jadi syot kilat memori RDB dilakukan pada frekuensi yang lebih perlahan, menggunakan pengelogan AOF antara dua syot kilat RDB untuk merekodkan semua operasi "tulis" yang berlaku dalam tempoh tersebut.

Dengan cara ini, syot kilat tidak perlu dilaksanakan dengan kerap Pada masa yang sama, kerana AOF hanya perlu merekodkan arahan "tulis" yang berlaku di antara dua syot kilat, ia tidak perlu merekodkan semua operasi ke. elakkan fail yang terlalu besar.

Ringkasan

Redis direka bgsave dan copy-on-write untuk mengelakkan kesan pada arahan baca dan tulis semasa pelaksanaan syot kilat yang kerap akan memberi tekanan pada cakera dan garpu menghalang benang utama.

Redis telah mereka dua ciri pembunuh utama untuk mencapai pemulihan pantas daripada masa henti tanpa kehilangan data.

Untuk mengelakkan log daripada menjadi terlalu besar, mekanisme penulisan semula AOF disediakan Mengikut status data terkini pangkalan data, operasi penulisan data dijana sebagai log baharu dan diselesaikan di latar belakang tanpa. menyekat benang utama.

Mengintegrasikan AOF dan RDB menyediakan strategi kegigihan baharu dan model log hibrid dalam Redis 4.0. Apabila Redis dimulakan semula, anda boleh memuatkan kandungan rdb dahulu, dan kemudian memainkan semula log AOF tambahan, yang boleh menggantikan main semula fail penuh AOF sebelumnya, dan kecekapan mulakan semula bertambah baik.

Akhir sekali, mengenai pilihan AOF dan RDB, "Code Byte" mempunyai tiga cadangan:

• Apabila data tidak boleh hilang, penggunaan campuran syot kilat memori dan AOF adalah bagus. penyelesaian Pilihan yang baik;
• Jika kehilangan data peringkat minit dibenarkan, anda hanya boleh menggunakan RDB
• Jika anda hanya menggunakan AOF, beri keutamaan kepada pilihan konfigurasi everysec, kerana ia adalah kompromi; antara kebolehpercayaan dan prestasi Pukul keseimbangan.

Nantikan...

Alamat asal: https://juejin.cn/post/6961735998547951653

Pengarang: Code Brother Byte

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

Atas ialah kandungan terperinci Bagaimana untuk mencapai pemulihan yang cepat dan kegigihan tanpa rasa takut akan masa henti di Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!