Cara menggunakan kaedah RDB dan AOF Redis

Penyelesaian kegigihan Redis

Redis ialah pangkalan data dalam memori, dan data disimpan dalam ingatan Untuk mengelakkan kehilangan data kekal yang disebabkan oleh proses keluar, data dalam Redis perlu disimpan dalam beberapa bentuk secara tetap (Data atau arahan) disimpan dari memori ke cakera keras. Apabila Redis dimulakan semula pada masa akan datang, gunakan fail yang berterusan untuk mencapai pemulihan data. Di samping itu, fail berterusan boleh disalin ke lokasi terpencil untuk tujuan sandaran bencana.

Redis menyediakan pelbagai peringkat kaedah kegigihan: satu RDB dan satu lagi AOF.

Kegigihan RDB boleh menjana syot kilat titik dalam masa set data dalam selang masa tertentu dan menyimpan petikan pangkalan data ke cakera dalam bentuk binari.

AOF secara berterusan merekodkan semua perintah operasi perubahan yang dilaksanakan oleh pelayan Semua arahan dalam fail AOF disimpan dalam format protokol Redis, dan arahan baharu akan ditambahkan pada penghujung fail. Redis juga boleh menulis semula fail AOF di latar belakang supaya saiz fail AOF tidak melebihi saiz sebenar yang diperlukan untuk menyimpan keadaan set data.

Redis boleh menggunakan kegigihan AOF dan kegigihan RDB pada masa yang sama. Dalam kes ini, apabila Redis dimulakan semula, ia akan memberi keutamaan untuk menggunakan fail AOF untuk memulihkan set data, kerana set data yang disimpan oleh fail AOF biasanya lebih lengkap daripada set data yang disimpan oleh fail RDB. Anda juga boleh mematikan kegigihan supaya data hanya wujud semasa pelayan sedang berjalan.

Adalah sangat penting untuk memahami persamaan dan perbezaan antara kegigihan RDB dan kegigihan AOF Bahagian berikut akan memperkenalkan kedua-dua fungsi kegigihan ini secara terperinci dan menerangkan persamaan dan perbezaannya.

Gambar RDB

Mari kita bincangkan tentang strategi kegigihan pertama Redis, gambar RDB. Redis menyokong mekanisme kegigihan yang menyimpan syot kilat data memori semasa ke dalam fail data Bagaimanakah pangkalan data bertulis berterusan menjana syot kilat? Redis bijak menggunakan mekanisme salinan pada perintah fork untuk menukar proses semasa ke dalam proses anak Proses anak secara kitaran mengekalkan data ke dalam fail RDB berdasarkan petikan memori.

Secara lalai, Redis menyimpan petikan pangkalan data dalam fail binari bernama dump.rdb dalam direktori akar. Anda boleh menentukan direktori simpan melalui konfigurasi dir parameter, dan dbfilename menentukan nama fail. Anda boleh menetapkan Redis, seperti "simpan N M", yang bermaksud bahawa apabila terdapat perubahan M dalam item data dalam masa N saat, apabila syarat ini dipenuhi, set data akan disimpan secara automatik. Sebagai contoh, anda boleh mengkonfigurasi untuk menjana syot kilat apabila terdapat 100 tulisan dalam masa 10 minit, atau anda boleh mengkonfigurasi untuk menjana syot kilat apabila terdapat 1,000 tulisan dalam masa 1 minit Ia menyokong berbilang peraturan untuk berkuat kuasa pada masa yang sama, dan yang mana peraturan akan berkuat kuasa apabila ia sepadan. Takrif peraturan ini adalah dalam fail konfigurasi Redis Anda juga boleh menetapkan peraturan semasa Redis berjalan melalui arahan SET CONFIG Redis tanpa memulakan semula Redis.

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

save 60 1000

Anda juga boleh Secara Manual biarkan Redis menyimpan set data dengan memanggil SAVE atau BGSAVE. Perintah SAVE menjalankan operasi penyegerakan dan menyimpan petikan semua data dalam bentuk fail RDB Perintah SAVE jarang digunakan secara langsung dalam persekitaran pengeluaran kerana ia menyekat semua permintaan pelanggan Jangan gunakannya dalam persekitaran pengeluaran boleh menggunakan arahan BGSAVE sebaliknya. Perintah BGSAVE dilaksanakan dengan memotong proses anak, jadi permintaan klien tidak akan disekat Hanya memotong proses anak akan menyekat pelayan. Selain itu, apabila mencetuskan kegigihan RDB secara automatik, Redis juga akan memilih BGSAVE dan bukannya SAVE untuk kegigihan.

Kegigihan RDB automatik Redis dilaksanakan secara dalaman melalui fungsi operasi berkala serverCron, kaunter kotor dan cap masa lastsave. ServerCron dilaksanakan setiap 100ms untuk menyemak status pelayan, yang termasuk menyemak sama ada "simpan N M" memenuhi syarat, dan jika ya, laksanakan BGSAVE sudah tentu, ia juga termasuk semakan penulisan semula AOF. Kaunter kotor ialah keadaan yang dikekalkan oleh pelayan Redis Ia merekodkan berapa kali status pelayan telah diubah suai (termasuk penambahan, pemadaman dan pengubahsuaian) sejak pelaksanaan terakhir arahan BGSAVE/SAVE Apabila pelaksanaan BGSAVE/SAVE selesai , kotor akan ditetapkan semula kepada 0. . Cap masa lastsave juga merupakan keadaan yang dikekalkan oleh pelayan Redis Ia merekodkan masa apabila BGSAVE/SAVE kali terakhir berjaya dilaksanakan Masa semasa tolak lastsave mesti memenuhi M.

Selain manual dan automatik, terdapat beberapa situasi lain yang akan mencetuskan BGSAVE:

Dalam senario replikasi induk-hamba, jika nod hamba melakukan operasi replikasi penuh, nod induk akan melaksanakan arahan BGSAVE Dan menghantar fail rdb ke nod hamba. Apabila melaksanakan arahan penutupan, kegigihan RDB dilakukan secara automatik. Di samping itu, anda perlu memahami bahawa kerana operasi penulisan dilakukan dalam proses baharu, apabila fail RDB baharu dijana, proses anak yang dijana oleh Redis akan menulis data terlebih dahulu ke fail sementara, dan kemudian memanggil sistem nama semula atom Namakan semula fail sementara kepada fail RDB supaya jika kegagalan berlaku pada bila-bila masa, fail Redis RDB sentiasa tersedia.

这种持久化方式被称为快照（snapshot）。但是，我们可以很明显的看到，RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，如果可以忍受间隔内数据丢失，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制，AOF日志方式持久化。

为了尽可能使RDB文件体积减小，Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时，但是可以大大减小RDB文件的体积，因此压缩默认开启，参数为rdbcompression。需要注意的是，RDB文件的压缩并不是针对整个文件进行的，而是对数据库中的字符串进行的，且只有在字符串达到一定长度(20字节)时才会进行。

除了压缩，你也可以检验RDB文件，通过参数rdbchecksum设置，默认为yes。在写入文件和读取文件时都起作用，关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现。

另外，当bgsave出现错误时，Redis是否停止执行写命令。Redis提供了一个参数stop-writes-on-bgsave-error，设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no。

说说FORK的开销？

父进程通过fork操作可以创建子进程，第一代Unix系统实现了一种傻瓜式的进程创建：当执行fork系统调用时，内核复制父进程的整个用户空间并把复制得到的那一份分配给子进程。这种行为时非常耗时的，因为它需要完成以下几项任务：为子进程的页表分配页面、为子进程的页分配页面、初始化子进程的页表、把父进程的页复制到子进程对应的页中。

现在Linux的fork()使用写时拷贝（copy-on-write）页实现。写时拷贝是一种可以推迟甚至免除拷贝数据的技术。内核此时并不复制整个进程地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候，数据才会被复制，从而使各个进程拥有各自的拷贝。也就是说，资源的复制只有在需要写入的时候才进行，在此之前，只是以只读方式共享。这种技术使地址空间上的页的拷贝被推迟到实际发生写入的时候。所以就算fork很大内存的进程，对内存的消耗和耗时都很小。

现在虽然fork时，子进程不会复制父进程的数据空间，但是会复制内存页表（页表相当于内存的索引、目录）；父进程的数据空间越大，内存页表越大，fork时复制耗时也会越多。这个问题也是导致Redis内存不宜过大的原因之一，当然还有导致故障恢复时间延长也是Redis内存不宜过大的原因。

AOF日志

通过上面的分析，我们知道RDB快照有大概率丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说，数据安全并不是最重要的考虑因素，但是对于那些追求数据安全的程序来说，快照功能就不太适用了。从1.1版本开始，Redis增加了一种实时性更好的持久化方式，即AOF持久化。AOF日志的全称是append only file，从名字上我们就能看出来，它是一个追加写入的日志文件。与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

AOF文件与MySQL数据库的binlog不同的是，AOF是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点，它记录的内容就是一个个的Redis标准命令。开启AOF持久化命令如下：

appendonly yes
appendfilename "appendonly.aof"

从现在开始，每当Redis执行一个改变数据集的命令时（比如SET），这个命令就会被追加到AOF文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的。

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程：

命令追加（append）

Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：

Untuk meningkatkan kecekapan menulis fail, dalam sistem pengendalian moden, apabila pengguna memanggil fungsi tulis untuk menulis data ke fail, sistem pengendalian biasanya menyimpan sementara data ke dalam penimbal memori Apabila penimbal diisi atau Selepas had masa yang ditentukan telah melebihi, data dalam penimbal sebenarnya ditulis ke cakera keras. Walaupun operasi sedemikian meningkatkan kecekapan, ia juga membawa isu keselamatan: jika komputer dimatikan, data dalam penimbal memori akan hilang oleh itu, sistem juga menyediakan fungsi penyegerakan seperti fsync dan fdatasync, yang boleh memaksa sistem pengendalian; segera simpan data dalam penimbal Data ditulis ke cakera keras untuk memastikan keselamatan data.

Strategi fail penyegerakan kawasan cache AOF dikawal oleh parameter appendfsync Maksud setiap nilai adalah seperti berikut:

sentiasa: Selepas arahan ditulis ke aof_buf, sistem fsync. operasi segera dipanggil untuk menyegerakkan ke fail AOF Selepas fsync selesai Benang kembali. Dalam kes ini, setiap arahan tulis mesti disegerakkan ke fail AOF, dan cakera keras IO menjadi halangan prestasi Redis hanya boleh menyokong kira-kira beberapa ratus TPS menulis, dengan serius mengurangkan prestasi Redis walaupun menggunakan pemacu keadaan pepejal (. SSD), Ia hanya boleh mengendalikan puluhan ribu arahan sesaat, dan ia akan mengurangkan hayat SSD dengan banyak.

tidak: Selepas arahan ditulis ke dalam aof_buf, operasi tulis sistem dipanggil, dan fail AOF tidak disegerakkan oleh sistem pengendalian, dan tempoh penyegerakan biasanya 30 saat. Dalam kes ini, masa penyegerakan fail tidak dapat dikawal, dan akan terdapat banyak data terkumpul dalam penimbal, dan keselamatan data tidak dapat dijamin. everysec: Selepas arahan ditulis ke dalam aof_buf, operasi tulis sistem dipanggil Benang kembali selepas penulisan selesai; Everysec ialah kompromi antara dua strategi yang disebutkan di atas, keseimbangan antara prestasi dan keselamatan data Oleh itu, ia adalah konfigurasi lalai Redis dan konfigurasi kami yang disyorkan.

Tulis semula fail (tulis semula)

Oleh kerana AOF berfungsi dengan menambahkan arahan secara berterusan ke hujung fail, jadi apabila bilangan arahan bertulis terus meningkat, saiz fail AOF juga akan bertambah menjadi semakin besar. Sebagai contoh, jika anda memanggil INCR 100 kali pada kaunter, maka fail AOF perlu menggunakan 100 entri hanya untuk menyimpan nilai semasa kaunter. Walau bagaimanapun, pada hakikatnya, menggunakan hanya satu arahan SET sudah cukup untuk menyimpan nilai semasa kaunter, dan baki 99 rekod sebenarnya berlebihan. Selain itu, terdapat beberapa data tamat tempoh dan data tidak sah yang juga boleh dialih keluar.

Fail AOF yang terlalu besar bukan sahaja akan menjejaskan operasi biasa pelayan, tetapi juga menyebabkan pemulihan data mengambil masa terlalu lama. Untuk mengendalikan situasi ini, Redis menyokong ciri menarik yang boleh membina semula fail AOF tanpa mengganggu klien perkhidmatan. Laksanakan arahan BGREWRITEAOF, Redis akan menjana fail AOF baharu, yang mengandungi arahan minimum yang diperlukan untuk membina semula set data semasa.

Proses penjanaan AOF REWRITE (tulis semula) adalah serupa dengan syot kilat RDB, yang kedua-duanya bijak menggunakan mekanisme salin atas tulis. Ia juga menghentikan proses kanak-kanak (benang utama disekat pada masa ini Proses kanak-kanak menulis ke fail AOF baharu mengikut petikan memori dan peraturan penggabungan arahan). Apabila proses utama memotong benang kanak-kanak dan terus menerima permintaan, semua arahan tulis masih ditulis pada penimbal AOF (aof_buf) dan disegerakkan ke cakera keras mengikut dasar appendfsync untuk memastikan ketepatan mekanisme AOF asal. Walau bagaimanapun, oleh kerana operasi garpu menggunakan teknologi salin atas tulis, proses kanak-kanak hanya boleh berkongsi data memori semasa operasi garpu. Memandangkan proses induk masih bertindak balas kepada arahan, Redis menggunakan penimbal tulis semula AOF (aof_rewrite_buf) untuk menyimpan bahagian log baharu ini untuk mengelakkan bahagian data ini daripada hilang semasa penjanaan fail AOF baharu. Dalam erti kata lain, semasa pelaksanaan bgrewriteaof, arahan tulis Redis dilampirkan pada dua penimbal aof_buf dan aof_rewirte_buf pada masa yang sama.

Apabila proses anak selesai menulis fail AOF baharu, ia menghantar isyarat kepada proses induk dan proses induk mengemas kini maklumat statistik, yang boleh dilihat melalui ketekunan maklumat. Kemudian proses induk menulis data dalam penimbal tulis semula AOF ke fail AOF baharu, dengan itu memastikan keadaan pangkalan data yang disimpan dalam fail AOF baharu adalah konsisten dengan keadaan semasa pelayan. Kemudian panggil perintah nama semula atom untuk menggantikan fail AOF lama dengan fail AOF baharu untuk melengkapkan penulisan semula AOF.

Anda perlu memberi perhatian di sini kerana proses utama menambahkan cache aof_rewrite_buf ke fail log baharu. Apabila proses utama menambahkan log, ia tidak akan memproses permintaan lain Jika aof_rewrite_buf sangat besar, seperti ratusan M, ia mungkin menyebabkan Redis tidak bertindak balas selama beberapa saat atau bahkan berpuluh-puluh saat.

Daripada proses di atas, kita dapat melihat bahawa operasi RDB dan AOF adalah kedua-dua operasi IO berjujukan, dan prestasinya sangat tinggi. Apabila memulihkan pangkalan data melalui fail RDB atau log AOF, data juga dibaca secara berurutan dan dimuatkan ke dalam memori. Jadi ia tidak akan menyebabkan pembacaan rawak cakera.

Pencetusan penulisan semula fail dibahagikan kepada pencetus manual dan pencetus automatik:

Pencetusan manual: panggil terus arahan bgrewriteaof Perlaksanaan arahan ini agak serupa dengan bgsave: kedua-duanya adalah fork sub -proses untuk melakukan operasi tertentu, dan mereka hanya menyekat apabila bercabang.

Pencetusan automatik: Tentukan masa pencetus berdasarkan parameter auto-aof-rewrite-min-size dan auto-aof-rewrite-percentage, serta status aof_current_size dan aof_base_size.

auto-aof-rewrite-min-size menunjukkan saiz minimum fail semasa melakukan penulisan semula AOF Nilai lalai ialah 64MB.

auto-aof-rewrite-percentage表示执行AOF重写时，当前AOF大小（即aof_current_size）和上一次重写时AOF大小（aof_base_size）的比值，即增长比例达到设定值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

其中，参数可以通过config get命令查看：

127.0.0.1:6391> CONFIG GET auto-aof-rewrite-min-size
1) "auto-aof-rewrite-min-size"2) "64000000"127.0.0.1:6391> CONFIG GET auto-aof-rewrite-percentage
1) "auto-aof-rewrite-percentage"2) "100"

状态可以通过info persistence查看：

127.0.0.1:6379> info persistence# Persistenceaof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:40876638
aof_base_size:2217565
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0

另外在aof rewrite过程中，是否采取增量”文件同步”策略，由参数aof-rewrite-incremental-fsync控制，默认为”yes”，而且必须为yes。rewrite过程中，每32M数据进行一次文件同步，这样可以减少”aof大文件”写入对磁盘的操作次数。

bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。

如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候Redis挂掉，就会丢失数据。丢失多少数据呢？在Linux的操作系统的默认设置下，最多会丢失30s的数据。因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

AOF刷新策略？

前面提到过，在AOF中，如果AOF缓冲区的文件同步策略为everysec，则：在主线程中，命令写入aof_buf后调用系统write操作，write完成后主线程返回；fsync同步文件操作由专门的文件同步线程每秒调用一次。这种做法的问题在于，如果硬盘负载过高，那么fsync操作可能会超过1s；如果Redis主线程持续高速向aof_buf写入命令，硬盘的负载可能会越来越大，IO资源消耗更快；如果此时Redis进程异常退出，丢失的数据也会越来越多，可能远超过1s。

为此，Redis的处理策略是这样的：主线程每次进行AOF会对比上次fsync成功的时间；如果距上次不到2s（也就是延迟了1s），主线程直接返回；如果超过2s，则主线程阻塞直到上一次fsync同步完成。因此，如果系统硬盘负载过大导致fsync速度太慢，会导致Redis主线程的阻塞；此外，使用everysec配置，AOF最多可能丢失2s的数据，而不是1s。具体看Redis AOF刷新策略分析

AOF追加阻塞问题定位的方法，监控info Persistence中的aof_delayed_fsync，当AOF追加阻塞发生时（即主线程等待fsync而阻塞），该指标累加。另外，AOF阻塞时的Redis日志：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

如果AOF追加阻塞频繁发生，说明系统的硬盘负载太大；可以考虑更换IO速度更快的硬盘，或者通过IO监控分析工具对系统的IO负载进行分析。

对于pipelining有什么不同？

对于pipelining的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用pipilining就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置appendfsync为everysec时，可能会有一些偏差，因为这N个命令可能执行时间超过1秒甚至2秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。

如果AOF文件出错了，怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成了 AOF 文件出错（corrupt），那么Redis在重启时会拒绝载入这个AOF文件， 从而确保数据的一致性不会被破坏。当发生这种情况时，可以用以下方法来修复出错的 AOF 文件：为现有的AOF文件创建一个备份。然后使用Redis附带的redis-check-aof –fix程序对原来的AOF文件进行修复。

然后可选使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。再次重启Redis服务器，等待服务器载入修复后的AOF文件，并进行数据恢复。

Tetapi jika penghujung fail AOF tidak lengkap (masa henti mesin secara tiba-tiba boleh membawa kepada penghujung fail yang tidak lengkap dengan mudah), dan parameter aof-load-truncated dihidupkan, amaran akan dikeluarkan dalam log , dan Redis akan mengabaikan penghujung fail AOF dan mula berjaya. Parameter aof-load-truncated didayakan secara lalai.

Kebaikan dan Kelemahan RDB dan AOF

Apakah kelebihan RDB?

RDB ialah fail yang sangat padat dengan saiz kecil dan penghantaran rangkaian yang pantas. Ia menyimpan set data Redis pada masa tertentu. Fail jenis ini sangat sesuai untuk sandaran, dan kelajuan pemulihan adalah lebih pantas daripada AOF. Sudah tentu, salah satu kelebihan RDB yang paling penting ialah ia mempunyai kesan yang agak kecil terhadap prestasi berbanding dengan AOF. Satu-satunya perkara yang perlu dilakukan oleh proses induk semasa menyimpan fail RDB adalah untuk menghentikan proses anak, dan kemudian proses anak akan mengendalikan semua kerja menyimpan seterusnya Proses induk tidak perlu melakukan sebarang operasi I/O cakera.

Kelemahan RDB?

Kelemahan maut fail RDB ialah kaedah ketekalan syot kilat data menentukan bahawa ketekunan masa nyata tidak dapat dicapai Hari ini, apabila data menjadi semakin penting, sejumlah besar kehilangan data selalunya tidak boleh diterima . Oleh itu, kegigihan AOF telah menjadi arus perdana. Selain itu, fail RDB perlu memenuhi format tertentu dan mempunyai keserasian yang lemah (contohnya, versi lama Redis tidak serasi dengan versi baharu fail RDB).

Kelebihan AOF?

Sejajar dengan kegigihan RDB, kelebihan AOF ialah ia menyokong kegigihan peringkat kedua dan mempunyai keserasian yang baik. Anda boleh menetapkan dasar fsync yang berbeza, seperti tiada fsync, fsync setiap saat atau fsync setiap kali arahan tulis dilaksanakan. Dasar lalai AOF ialah fsync 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. Fail AOF ialah fail log yang hanya menjalankan operasi tambah (tambah log sahaja), jadi menulis ke fail AOF tidak memerlukan pencarian, walaupun log mengandungi arahan yang tidak lengkap atas sebab tertentu (seperti menulis Cakera penuh, menulis adalah berhenti semasa menulis, dsb.), alat redis-check-aof juga boleh menyelesaikan masalah ini dengan mudah.

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 Redis akan terus menambahkan arahan pada fail AOF sedia ada semasa proses mencipta fail AOF baharu Walaupun terdapat penutupan semasa proses penulisan semula, fail AOF 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. Fail AOF menyimpan semua operasi tulis yang dilakukan pada pangkalan data dengan cara yang teratur Operasi tulis ini disimpan dalam format protokol Redis, jadi kandungan fail AOF sangat mudah dibaca dan mudah untuk menganalisis fail (. menghurai). Mengeksport (mengeksport) fail AOF juga sangat mudah: contohnya, jika anda secara tidak sengaja melaksanakan arahan FLUSHALL, tetapi selagi fail AOF belum ditimpa, maka hentikan sahaja pelayan, alih keluar arahan FLUSHALL di penghujung AOF fail, dan mulakan semula Redis Anda boleh memulihkan set data kepada keadaan sebelum FLUSHALL dilaksanakan.

Kelemahan AOF?

Saiz fail AOF biasanya lebih besar daripada fail RDB, dan kelajuan pemulihan adalah perlahan. Untuk set data yang sama, 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. Di samping itu, AOF mempunyai pepijat sedemikian pada masa lalu Disebabkan arahan tertentu, apabila fail AOF dimuat semula, set data tidak boleh dipulihkan kepada keadaan asal apabila ia disimpan. Walaupun pepijat jenis ini tidak biasa dalam fail AOF, secara perbandingan, hampir mustahil untuk RDB mempunyai pepijat jenis ini.

RDB dan AOF, yang manakah harus saya gunakan?

Pertama sekali, anda mesti faham bahawa sama ada RDB atau AOF, menghidupkan kegigihan datang pada kos prestasi: untuk kegigihan RDB, dalam satu pihak, proses utama Redis akan disekat apabila bgsave melakukan operasi garpu sebaliknya, sebaliknya, menulis data ke cakera keras oleh proses kanak-kanak juga akan membawa tekanan IO. Tetapi jika perniagaan boleh bertolak ansur dengan kehilangan data dari beberapa minit hingga 10 minit (dan tidak menggunakan pangkalan data siap sedia), RDB ialah pilihan yang baik, jika tidak, pilih AOF.

Untuk kegigihan AOF, kekerapan menulis data ke cakera keras sangat meningkat (tahap kedua di bawah dasar setiap detik), tekanan IO lebih tinggi, malah boleh menyebabkan masalah penyekatan tambahan AOF (sekatan ini akan diterangkan terperinci kemudian). Secara relatifnya, kerana AOF menulis data ke cakera keras dengan lebih kerap, ia akan memberi kesan yang lebih besar terhadap prestasi proses utama Redis.

在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一种，或同时开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从机slave可以独立的选择持久化方案。比如完全关闭master持久化（包括RDB和AOF），这样可以让master的性能达到最好；而slave可以只开启AOF。但这种情况下，如果master服务因为故障宕掉了，如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自动重启，由于没有持久化文件，那么master重启后数据是空的，slave同步数据也变成了空的，意味着数据丢失。所以尽量避免这种情况出现。

RDB和AOF之间的相互作用？

在版本号大于等于2.4的Redis中，BGSAVE执行的过程中，不可以执行BGREWRITEAOF。反过来说，在BGREWRITEAOF执行的过程中，也不可以执行BGSAVE。这可以防止两个Redis后台进程同时对磁盘进行大量的I/O操作。

如果BGSAVE正在执行，并且用户显示地调用BGREWRITEAOF命令，那么服务器将向用户回复一个OK状态，并告知用户，BGREWRITEAOF已经被预定执行： 一旦BGSAVE执行完毕，BGREWRITEAOF就会正式开始。当Redis启动时，如果RDB持久化和AOF持久化都被打开了，那么程序会优先使用AOF文件来恢复数据集，因为AOF文件所保存的数据通常是最完整的。

RDB和AOF数据导入

这些持久化的数据有什么用，当然是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB或AOF进行恢复的时候，会读取RDB或AOF文件，重新加载到内存中。相对于MySQL等数据库的启动时间来说，会长很多，因为MySQL本来是不需要将数据加载到内存中的。

但是相对来说，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是非常快的。

而在利用RDB和利用AOF启动上，其启动时间有一些差别。RDB的启动时间会更短，原因有两个，一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在CPU消耗上要远小于AOF日志的加载。

注意：当redis启动时，如果rdb持久化和aof持久化都打开了，那么程序会优先使用aof方式来恢复数据集，因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了，则启动之后数据库内容为空。

注意：如果想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。(不能直接修改配置文件，重启数据库，否则数据库中数据就为空了。) 在Redis 2.2或以上版本，可以在不重启的情况下，从RDB切换到AOF ：

为最新的dump.rdb文件创建一个备份，将备份放到一个安全的地方。执行以下两条命令：

127.0.0.1:6379> CONFIG SET dir /apps/redis/data/redis-8836
127.0.0.1:6379> CONFIG SET appendonly yes
127.0.0.1:6379> CONFIG SET save ""

确保命令执行之后，数据库的键的数量没有改变。确保写命令会被正确地追加到 AOF 文件的末尾。

步骤2是开启了AOF功能，Redis会阻塞直到初始AOF文件创建完成为止，之后Redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。

步骤3用于关闭RDB功能，这一步是可选的，如果你愿意的话，也可以同时使用RDB和AOF这两种持久化功能。

Atas ialah kandungan terperinci Cara menggunakan kaedah RDB dan AOF Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!