Kuasai sepenuhnya kegigihan Redis: RDB dan AOF

Artikel ini membawa anda pengetahuan yang berkaitan tentang Redis, yang terutamanya memperkenalkan isu berkaitan tentang kegigihan, termasuk sebab kegigihan diperlukan, kegigihan RDB, kegigihan AOF, dll. Mari lihat kandungan di bawah I semoga ianya bermanfaat kepada semua.

Pembelajaran yang disyorkan: Tutorial video Redis

1. Mengapakah ketekunan diperlukan?

Redis mengendalikan data berdasarkan memori Apabila menghadapi situasi yang tidak dijangka seperti proses keluar dan masa henti pelayan, jika tiada mekanisme kegigihan, data dalam Redis akan hilang dan tidak boleh dipulihkan. Dengan mekanisme kegigihan, Redis boleh menggunakan fail yang berterusan sebelum ini untuk pemulihan data apabila ia dimulakan semula. Dua mekanisme kegigihan yang disokong oleh Redis:

RDB: menjana syot kilat data semasa dan menyimpannya pada cakera keras.
AOF: Rakam setiap operasi pada data ke cakera keras.

2. Kegigihan RDB

Tulis syot kilat set data dalam ingatan ke cakera dalam selang masa yang ditetapkan Apabila ia dipulihkan, fail syot kilat baca terus dalam ingatan. Kegigihan RDB (Redis DataBase) adalah untuk menjana gambar semua data semasa dalam Redis dan menyimpannya pada cakera keras. Kegigihan RDB boleh dicetuskan secara manual atau automatik.

1. Bagaimanakah sandaran dilakukan?

Redis akan mencipta (fork) sub-proses yang berasingan untuk kegigihan Ia akan menulis data ke fail sementara Selepas proses kegigihan selesai, fail sementara ini akan digunakan untuk menggantikan kegigihan terakhir. Ok fail. Semasa keseluruhan proses, proses utama tidak melakukan sebarang operasi IO, yang memastikan prestasi yang sangat tinggi. Jika pemulihan data berskala besar diperlukan dan integriti pemulihan data tidak begitu sensitif, maka kaedah RDB adalah lebih cekap daripada kaedah AOF. Kelemahan RDB ialah data terakhir yang berterusan mungkin hilang.

2. Proses kegigihan RDB

3 Pencetus manual

save dan Perintah bgsave boleh mencetuskan kegigihan RDB secara manual.

1. save
   Melaksanakan perintah save secara manual akan mencetuskan kegigihan RDB, tetapi perintah save akan menyekat perkhidmatan Redis sehingga kegigihan RDB selesai. Apabila perkhidmatan Redis menyimpan sejumlah besar data, ia akan menyebabkan kesesakan jangka panjang dan tidak disyorkan.
2. bgsave
   Melaksanakan perintah bgsave juga akan mencetuskan kegigihan RDB secara manual Tidak seperti perintah save, perkhidmatan Redis biasanya tidak menyekat. Proses Redis akan melakukan operasi garpu untuk mencipta proses anak Proses anak bertanggungjawab untuk kegigihan RDB dan tidak akan menyekat proses perkhidmatan Redis. Penyekatan perkhidmatan Redis hanya berlaku dalam fasa garpu, dan secara amnya masanya sangat singkat. Proses khusus perintah
   bgsave adalah seperti berikut:
   
   1. Jalankan perintah bgsave terlebih dahulu menentukan sama ada terdapat pada masa ini melaksanakan subrutin RDB atau AOF Utas, jika wujud, ditamatkan secara langsung.
   2. Proses Redis melakukan operasi garpu untuk mencipta benang anak Proses Redis akan disekat semasa operasi garpu.
   3. Selepas garpu proses Redis selesai, perintah bgsave tamat Mulai dari itu, proses Redis tidak akan disekat dan boleh bertindak balas kepada arahan lain.
   4. Proses anak menjana fail syot kilat berdasarkan memori proses Redis dan menggantikan fail RDB asal.
   5. Pada masa yang sama, isyarat dihantar ke proses utama untuk memberitahu proses utama bahawa kegigihan rdb telah selesai, dan proses utama mengemas kini maklumat statistik yang berkaitan (pilihan berkaitan rdb_* di bawah info Persitence).

4. Pencetusan automatik

Selain pencetus manual dengan melaksanakan arahan di atas, kegigihan RDB boleh dicetuskan secara automatik di dalam Redis. Kegigihan RDB yang dicetuskan secara automatik menggunakan kaedah bgsave untuk mengurangkan penyekatan proses Redis. Jadi, dalam keadaan apakah ia akan dicetuskan secara automatik?

1. menetapkan konfigurasi berkaitan save dalam fail konfigurasi, seperti sava m n, yang bermaksud apabila data diubah suai n kali dalam m saat, operasi bgsave dicetuskan secara automatik .
2. Apabila nod hamba melakukan replikasi penuh, nod induk akan secara automatik melaksanakan operasi bgsave dan menghantar fail RDB yang dijana ke nod hamba. Apabila
3. melaksanakan perintah debug reload, operasi bgsave juga akan dicetuskan secara automatik.
4. Apabila melaksanakan perintah shutdown, jika kegigihan AOF tidak didayakan, operasi bgsave akan dicetuskan secara automatik.

5. Kelebihan RDB

Fail RDB ialah fail mampat binari padat, yang merupakan petikan semua data Redis pada masa tertentu. Oleh itu, kelajuan pemulihan data menggunakan RDB jauh lebih pantas daripada AOF, yang sangat sesuai untuk senario seperti sandaran, replikasi penuh dan pemulihan bencana.

6. Kelemahan RDB

Setiap kali operasi bgsave dilakukan, operasi garpu mesti dilakukan untuk mencipta anak. Kos pelaksanaan yang kerap adalah terlalu tinggi. jadi ketekunan masa nyata tidak boleh dicapai, atau tahap ketekunan saat.

Selain itu, disebabkan oleh lelaran berterusan versi Redis, terdapat versi RDB dalam format yang berbeza, dan mungkin terdapat masalah bahawa format RDB versi lebih rendah tidak serasi dengan fail RDB versi lebih tinggi.

7. Konfigurasikan RDB dalam dump.rdb

Tempoh syot kilat : Walaupun syot kilat memori boleh dilakukan oleh juruteknik yang melaksanakan perintah SAVE atau BGSAVE secara manual, Dalam kebanyakan persekitaran pengeluaran, syarat pelaksanaan berkala akan ditetapkan.

• Tetapan kitaran lalai baharu dalam Redis

# 周期性执行条件的设置格式为
save <seconds> <changes>

# 默认的设置为：
save 900 1
save 300 10
save 60 10000

# 以下设置方式为关闭RDB快照功能
save ""</changes></seconds>

Maksud tiga tetapan maklumat lalai di atas ialah:

• 如果900秒内有1条Key信息发生变化，则进行快照；
• 如果300秒内有10条Key信息发生变化，则进行快照；
• 如果60秒内有10000条Key信息发生变化，则进行快照。读者可以按照这个规则，根据自己的实际请求压力进行设置调整。
• 其它相关配置

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir ./

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

• dbfilename：RDB文件在磁盘上的名称。
• dir：RDB文件的存储路径。默认设置为“./”，也就是Redis服务的主目录。
• stop-writes-on-bgsave-error：上文提到的在快照进行过程中，主进程照样可以接受客户端的任何写操作的特性，是指在快照操作正常的情况下。如果快照操作出现异常（例如操作系统用户权限不够、磁盘空间写满等等）时，Redis就会禁止写操作。这个特性的主要目的是使运维人员在第一时间就发现Redis的运行错误，并进行解决。一些特定的场景下，您可能需要对这个特性进行配置，这时就可以调整这个参数项。该参数项默认情况下值为yes，如果要关闭这个特性，指定即使出现快照错误Redis一样允许写操作，则可以将该值更改为no。
• rdbcompression：该属性将在字符串类型的数据被快照到磁盘文件时，启用LZF压缩算法。Redis官方的建议是请保持该选项设置为yes，因为“it’s almost always a win”。
• rdbchecksum：从RDB快照功能的version 5 版本开始，一个64位的CRC冗余校验编码会被放置在RDB文件的末尾，以便对整个RDB文件的完整性进行验证。这个功能大概会多损失10%左右的性能，但获得了更高的数据可靠性。所以如果您的Redis服务需要追求极致的性能，就可以将这个选项设置为no。

8、 RDB 更深入理解

• 由于生产环境中我们为Redis开辟的内存区域都比较大（例如6GB），那么将内存中的数据同步到硬盘的过程可能就会持续比较长的时间，而实际情况是这段时间Redis服务一般都会收到数据写操作请求。那么如何保证数据一致性呢？
  RDB中的核心思路是Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程专门来做这个事情，这样保证了Redis服务不会停止对客户端包括写请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域，待快照操作结束后才会同步到原来的内存区域。
  举个例子：如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。
  
• 在进行快照操作的这段时间，如果发生服务崩溃怎么办？
  很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现了服务崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。
• 可以每秒做一次快照吗？
  对于快照来说，所谓“连拍”就是指连续地做快照。这样一来，快照的间隔时间变得很短，即使某一时刻发生宕机了，因为上一时刻快照刚执行，丢失的数据也不会太多。但是，这其中的快照间隔时间就很关键了。
  如下图所示，我们先在 T0 时刻做了一次快照，然后又在 T0+t 时刻做了一次快照，在这期间，数据块 5 和 9 被修改了。如果在 t 这段时间内，机器宕机了，那么，只能按照 T0 时刻的快照进行恢复。此时，数据块 5 和 9 的修改值因为没有快照记录，就无法恢复了。
  

针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决

三、AOF持久化

AOF（Append Only File）持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式。

Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

而AOF日志采用写后日志，即先写内存，后写日志。

为什么采用写后日志？
Redis要求高性能，采用写日志有两方面好处：

• 避免额外的检查开销：Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。
• 不会阻塞当前的写操作

但这种方式存在潜在风险：

• 如果命令执行完成，写日志之前宕机了，会丢失数据。
• 主线程写磁盘压力大，导致写盘慢，阻塞后续操作。

1、如何实现AOF？

AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

• 命令追加 当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
• 文件写入和同步 关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：
  
• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
• Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

2、redis.conf中配置AOF

默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：

# appendonly参数开启AOF持久化
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

以下是Redis中关于AOF的主要配置信息：
appendfsync：这个参数项是AOF功能最重要的设置项之一，主要用于设置“真正执行”操作命令向AOF文件中同步的策略。

什么叫“真正执行”呢？还记得Linux操作系统对磁盘设备的操作方式吗？ 为了保证操作系统中I/O队列的操作效率，应用程序提交的I/O操作请求一般是被放置在linux Page Cache中的，然后再由Linux操作系统中的策略自行决定正在写到磁盘上的时机。而Redis中有一个fsync()函数，可以将Page Cache中待写的数据真正写入到物理设备上，而缺点是频繁调用这个fsync()函数干预操作系统的既定策略，可能导致I/O卡顿的现象频繁 。

与上节对应，appendfsync参数项可以设置三个值，分别是：always、everysec、no，默认的值为everysec。

no-appendfsync-on-rewrite：always和everysec的设置会使真正的I/O操作高频度的出现，甚至会出现长时间的卡顿情况，这个问题出现在操作系统层面上，所有靠工作在操作系统之上的Redis是没法解决的。为了尽量缓解这个情况，Redis提供了这个设置项，保证在完成fsync函数调用时，不会将这段时间内发生的命令操作放入操作系统的Page Cache（这段时间Redis还在接受客户端的各种写操作命令）。

auto-aof-rewrite-percentage: Seperti yang dinyatakan di atas, dalam persekitaran pengeluaran, adalah mustahil untuk juruteknik menggunakan perintah "BGREWRITEAOF" untuk menulis semula fail AOF bila-bila masa dan di mana sahaja. Jadi lebih kerap kita perlu bergantung pada strategi penulisan semula automatik fail AOF dalam Redis. Redis menyediakan dua tetapan untuk mencetuskan penulisan semula automatik fail AOF:
auto-aof-rewrite-percentage bermakna jika saiz fail AOF semasa melebihi masa terakhir Selepas menulis semula a peratusan tertentu fail AOF, mula menulis semula fail AOF sekali lagi. Sebagai contoh, nilai tetapan lalai bagi nilai parameter ini ialah 100, yang bermaksud bahawa jika saiz fail AOF melebihi 1 kali saiz penulisan semula fail AOF terakhir, operasi tulis semula akan dimulakan.
auto-aof-rewrite-min-size: Item tetapan menunjukkan saiz minimum fail AOF untuk memulakan operasi menulis semula fail AOF. Jika saiz fail AOF lebih rendah daripada nilai ini, operasi tulis semula tidak akan dicetuskan. Ambil perhatian bahawa auto-aof-rewrite-percentage dan auto-aof-rewrite-min-size hanya digunakan untuk mengawal penulisan semula automatik fail AOF dalam Redis Jika juruteknik memanggil perintah "BGREWRITEAOF" secara manual, ia tidak akan Tertakluk kepada dua kekangan ini.

3. Pemahaman mendalam tentang penulisan semula AOF

AOF akan merekodkan setiap arahan tulis ke fail AOF seiring dengan berlalunya masa, fail AOF akan menjadi lebih besar. Jika tidak dikawal, ia akan menjejaskan pelayan Redis dan juga sistem pengendalian Selain itu, lebih besar fail AOF, semakin perlahan pemulihan data. Untuk menyelesaikan masalah pengembangan saiz fail AOF, Redis menyediakan mekanisme penulisan semula fail AOF untuk "mengurangkan" fail AOF.

Ilustrasi yang menerangkan penulisan semula AOF

Adakah AOF akan menulis semula menyekat?
Proses penulisan semula AOF diselesaikan dengan proses latar belakang bgrewriteaof. Benang utama bercabang daripada proses anak bgrewriteaof di latar belakang Garpu akan menyalin memori utas utama ke proses anak bgrewriteaof, yang mengandungi data terkini pangkalan data. Kemudian, sub-proses bgrewriteaof boleh menulis data yang disalin ke dalam operasi satu demi satu dan merekodkannya dalam log tulis semula tanpa menjejaskan utas utama. Oleh itu, apabila aof ditulis semula, ia akan menyekat benang utama apabila memotong proses.

Bilakah log AOF akan ditulis semula?
Terdapat dua item konfigurasi untuk mengawal pencetus penulisan semula AOF:
auto-aof-rewrite-min-size: Menunjukkan saiz minimum fail semasa menjalankan AOF menulis semula , lalai ialah 64MB.
auto-aof-rewrite-percentage: Nilai ini dikira sebagai perbezaan antara saiz fail aof semasa dan saiz fail aof selepas penulisan semula terakhir, dibahagikan dengan saiz fail aof selepas penulisan semula terakhir saiz. Iaitu, saiz tambahan fail aof semasa berbanding dengan fail aof selepas penulisan semula terakhir, dan nisbah saiz fail aof selepas penulisan semula terakhir.

Apakah yang berlaku apabila data baharu ditulis semasa menulis semula log?
Proses penulisan semula diringkaskan sebagai: "Satu salinan, dua log". Apabila keluar daripada proses kanak-kanak, dan apabila menulis semula, jika data baharu ditulis, utas utama akan merekodkan arahan ke dalam dua penimbal memori log aof. Jika dasar tulis balik AOF dikonfigurasikan untuk sentiasa, arahan akan ditulis kembali ke fail log lama dan salinan arahan akan disimpan dalam penimbal tulis semula AOF Operasi ini tidak akan memberi kesan kepada fail log baharu. (Fail log lama: fail log yang digunakan oleh utas utama, fail log baharu: fail log yang digunakan oleh proses bgrewriteaof)

Selepas proses anak bgrewriteaof menyelesaikan operasi penulisan semula fail log, ia akan menggesa bahawa benang utama mempunyai Selepas menyelesaikan operasi tulis semula, utas utama akan menambahkan arahan dalam penimbal tulis semula AOF ke penghujung fail log baharu. Pada masa ini, dalam keadaan konkurensi yang tinggi, pengumpulan penimbal tulis semula AOF mungkin sangat besar, yang akan menyebabkan penyekatan kemudiannya Redis menggunakan teknologi saluran paip Linux untuk membenarkan main balik serentak semasa penulisan semula AOF, supaya selepas penulisan semula AOF selesai, hanya A. sejumlah kecil data yang tinggal perlu dimainkan semula. Akhir sekali, keatoman penukaran fail dipastikan dengan mengubah suai nama fail.

Jika masa henti berlaku semasa AOF menulis semula log, kerana fail log belum ditukar, fail log lama masih akan digunakan semasa memulihkan data.

Kendalian ringkasan:

• Benang utama menghentikan proses kanak-kanak dan menulis semula log aof
• proses anak menulis semula Selepas log selesai, utas utama menambahkan penimbal log aof
• untuk menggantikan fail log

Peringatan hangat

Proses dan benang di sini Konsepnya agak mengelirukan. Kerana proses bgreweiteaof latar belakang hanya mempunyai satu utas yang beroperasi, dan utas utama ialah proses pengendalian Redis, yang juga merupakan satu utas. Apa yang saya ingin nyatakan di sini ialah selepas proses utama Redis memotong proses latar belakang, operasi proses latar belakang tidak ada kaitan dengan proses utama, dan tidak akan menyekat utas utama

Bagaimanakah benang utama menghalang proses kanak-kanak dan menyalin data memori?
Fork menggunakan mekanisme copy on write yang disediakan oleh sistem pengendalian untuk mengelak daripada menyalin sejumlah besar data memori sekaligus dan menyekat proses kanak-kanak. Apabila memotong proses anak, proses anak akan menyalin jadual halaman proses induk, iaitu hubungan pemetaan maya dan sebenar (jadual indeks pemetaan antara ingatan maya dan ingatan fizikal), tetapi bukan ingatan fizikal. Salinan ini akan menggunakan banyak sumber CPU, dan utas utama akan disekat sebelum salinan selesai Masa menyekat bergantung pada jumlah data dalam memori Semakin besar jumlah data, semakin besar jadual halaman memori. Selepas salinan selesai, proses ibu bapa dan anak menggunakan ruang alamat memori yang sama.

Tetapi proses utama boleh menulis data, dan pada masa ini data dalam memori fizikal akan disalin. Seperti yang ditunjukkan di bawah (proses 1 dianggap sebagai proses utama, proses 2 dianggap sebagai proses kanak-kanak):

Apabila proses utama mempunyai data yang ditulis, dan data ini berada di halaman c, sistem pengendalian akan Mencipta salinan halaman ini (salinan halaman c), iaitu menyalin data fizikal halaman semasa dan memetakannya ke proses utama, sementara proses anak masih menggunakan halaman asal c.

Di manakah urutan utama akan disekat semasa keseluruhan proses menulis semula log?

• Apabila memotong proses anak, jadual halaman maya perlu disalin, yang akan menyekat utas utama.
• Apabila proses utama menulis kunci besar, sistem pengendalian akan membuat salinan halaman dan menyalin data asal, yang akan menyekat utas utama.
• Selepas log penulisan semula sub-proses selesai, utas utama mungkin disekat apabila proses utama menambahkan penimbal tulis semula aof.

Mengapakah penulisan semula AOF tidak menggunakan semula log AOF asal?

• Menulis fail yang sama antara proses ibu bapa dan anak akan menyebabkan masalah persaingan dan menjejaskan prestasi proses induk.
• Jika proses penulisan semula AOF gagal, ia sama dengan mencemarkan fail AOF asal dan tidak boleh digunakan untuk pemulihan data.

3. Kaedah hibrid RDB dan AOF (versi 4.0)

Redis 4.0 mencadangkan kaedah penggunaan campuran log AOF dan syot kilat memori. Ringkasnya, syot kilat memori dilaksanakan pada frekuensi tertentu, dan antara dua syot kilat, log AOF digunakan untuk merekod semua operasi arahan dalam tempoh ini.

Dengan cara ini, syot kilat tidak perlu dilaksanakan dengan kerap sekali, yang mengelakkan kesan garpu yang kerap pada utas utama. Selain itu, log AOF hanya merekodkan operasi antara dua syot kilat, yang bermaksud bahawa tidak perlu merekodkan semua operasi Oleh itu, fail tidak akan terlalu besar dan overhed menulis semula boleh dielakkan.

Seperti yang ditunjukkan dalam rajah di bawah, pengubahsuaian pada T1 dan T2 direkodkan dalam log AOF Apabila syot kilat penuh kedua diambil, log AOF boleh dikosongkan, kerana semua pengubahsuaian pada masa ini telah direkodkan. dalam petikan , log tidak akan digunakan lagi semasa pemulihan.

Kaedah ini bukan sahaja boleh menikmati faedah pemulihan pantas fail RDB, tetapi juga menikmati kelebihan mudah AOF hanya merakam arahan operasi Ia digunakan secara meluas dalam persekitaran sebenar.

4. Pulihkan data daripada ketekunan

Sekarang sandaran dan ketekunan data selesai, bagaimanakah kita memulihkan data daripada fail berterusan ini? Jika terdapat kedua-dua fail RDB dan fail AOF pada pelayan, yang manakah harus dimuatkan?

Malah, jika anda ingin memulihkan data daripada fail ini, anda hanya perlu memulakan semula Redis. Kami masih memahami proses ini melalui rajah:

• Apabila redis dimulakan semula, ia menentukan sama ada untuk membolehkan aof didayakan, maka fail aof akan dimuatkan dahulu; 🎜>
Jika aof wujud, kemudian muatkan fail aof Jika pemuatan berjaya, redis dimulakan semula Jika fail aof gagal dimuatkan, log akan dicetak yang menunjukkan bahawa permulaan gagal baiki fail aof dan mulakan semula;
• Jika fail aof tidak wujud, maka redis akan memuatkan fail rdb sebaliknya Jika fail rdb wujud, ia akan memuatkan fail rdb untuk memulihkan data Jika pemuatan gagal, maka Log cetakan menunjukkan bahawa permulaan gagal, kemudian redis dimulakan semula dan menggunakan fail rdb untuk memulihkan fail data;

Jadi mengapa AOF dimuatkan dahulu? Kerana data yang disimpan oleh AOF adalah lebih lengkap, melalui analisis di atas kita tahu bahawa AOF pada asasnya kehilangan sehingga 1 saat data.

Pembelajaran yang disyorkan: Tutorial video Redis

Atas ialah kandungan terperinci Kuasai sepenuhnya kegigihan Redis: RDB dan AOF. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!