Analisis terperinci mengenai mekanisme kegigihan dalam Redis

Artikel ini akan membawa anda memahami mekanisme kegigihan dalam Redis: RDB dan AOF, dan membandingkan RDB dan AOF, saya harap ia akan membantu anda!

Mekanisme kegigihan Redis

Mengapa kegigihan

Jika Redis diakses semula dan mendapati bahawa data Redis kosong, penembusan cache akan berlaku. Lebih penting lagi, kerana data Redis kosong, tiada kunci yang ingin diakses oleh pelanggan, yang akan menyebabkan sejumlah besar permintaan untuk memukul pangkalan data serta-merta, menyebabkan runtuhan cache (sebilangan kecil kunci ditembusi, dan bilangan besar Kuncinya ialah Avalanche).

Pada masa ini, pangkalan data mungkin hang. Dan tidak ada jaminan bahawa redis tidak akan turun, jadi apabila redis turun, kandungan di dalamnya perlu dipulihkan dengan cepat. Oleh itu, kegigihan diperlukan. Kegigihan adalah untuk memulihkan data, bukan untuk menyimpan data. [Cadangan berkaitan: Tutorial video Redis]

RDB

RDB (Redis DataBase), ialah storan lalai bagi Redis Kaedah RDB dilaksanakan melalui snapshot.

Cara mencetuskan syot kilat

Patuhi peraturan syot kilat terkonfigurasi tersuai

• save 900 1 # Menunjukkan bahawa syot kilat akan diambil jika sekurang-kurangnya 1 kekunci ditukar dalam masa 15 minit (900 saat).

• save 300 10 # Menunjukkan bahawa syot kilat akan diambil jika sekurang-kurangnya 10 kekunci ditukar dalam masa 5 minit (300 saat).

• jimat 60 10000 # Menunjukkan bahawa jika sekurang-kurangnya 10,000 kekunci telah ditukar dalam masa 1 minit, teruskan dengan pantas

N秒内数据集至少有M个改动”这一条件被满足时，自动保存一次数据集。

Laksanakan perintah save atau bgsave

Laksanakan perintah save atau bgsave untuk menjana fail dump.rdb Setiap pelaksanaan arahan akan menangkap semua memori redis ke dalam fail rdb baharu dan menulis ganti yang asal Terdapat fail snapshot rdb.

Perbandingan antara save dan bgsave:

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其它命令	是	否(在生成子进程执行调用fork函数时会有短暂阻塞)
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

配置自动生成rdb文件后台使用的是bgsave方式。

Laksanakan perintah flushall

flushall

Sebelum mengosongkan Redis, simpan syot kilat Redis semasa

Laksanakan induk -operasi Salin hamba (kali pertama)

Salinan tuan-hamba pertama perlu menjana fail rdb, dan petikan Redis semasa akan disimpan

Proses pelaksanaan RDB

• Analisis Proses

  • 1. Induk Redis proses terlebih dahulu menentukan: sama ada pada masa ini Dalam subproses yang melaksanakan save atau bgsave/bgrewriteaof (aof file rewriteaof command), jika ia dilaksanakan, arahan bgsave kembali secara langsung.
  • 2. Proses induk menjalankan operasi fork (memanggil fungsi sistem pengendalian untuk menyalin proses utama) untuk mencipta proses anak Semasa proses ini, proses induk adalah disekat, dan Redis tidak boleh melaksanakan permintaan daripada klien apa-apa arahan daripada terminal.
  • 3. Selepas proses induk berhenti, arahan bgsave mengembalikan mesej "Penyimpanan latar belakang dimulakan" dan tidak lagi menyekat proses induk dan boleh bertindak balas kepada arahan lain.
  • 4. Proses anak mencipta fail RDB, menjana fail syot kilat sementara berdasarkan syot kilat memori proses induk dan melaksanakan penggantian atom fail asal selepas selesai. (RDB sentiasa lengkap)
  • 5. Proses anak menghantar isyarat kepada proses induk untuk menunjukkan selesai dan proses induk mengemas kini statistik.
  • 6. Selepas proses ibu bapa menghentikan proses anak, ia terus berfungsi.

Struktur fail RDB

• 1 5 bait pertama ditetapkan sebagai rentetan "REDIS"
• 2 Nombor versi "RDB" 4-bait (bukan nombor versi Redis), pada masa ini 9, akan menjadi 0009 selepas. mengisi
• 3. Ruangan tambahan dalam bentuk kunci-nilai
• 4. Nombor pangkalan data storan
• 5 🎜>
7. Data utama disimpan dalam bentuk nilai kunci
• 8 Tanda tamat
• 9
• Kebaikan dan keburukan RDB

Kelebihan

RDB ialah binari Fail mampat mengambil sedikit ruang dan mudah untuk dihantar (luluskan kepada hamba)

• Proses utama memotong proses anak, yang boleh memaksimumkan prestasi Redis Proses utama tidak boleh terlalu besar , dan proses utama akan disekat semasa proses penyalinan

• Kelemahan

Integriti data tidak dijamin dan semua data berubah. selepas syot kilat terakhir akan hilang

• AOF

AOF (tambah fail sahaja) ialah satu lagi kaedah kegigihan Redis. Redis tidak didayakan secara lalai. Selepas menghidupkan kegigihan AOF, Redis merekodkan semua arahan (dan parameternya) (RESP) yang ditulis ke pangkalan data ke fail AOF untuk mencapai tujuan merekodkan status pangkalan data Dengan cara ini, apabila Redis memulakan semula Just mainkan semula arahan ini dengan teratur dan keadaan asal akan dipulihkan. AOF akan merekodkan proses dan RDB hanya mengambil berat tentang hasilnya

Pelaksanaan kegigihan AOF

Konfigurasikan redis.conf

Prinsip AOF

# 可以通过修改redis.conf配置文件中的appendonly参数开启 
appendonly yes

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

# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改 
appendfilename appendonly.aof

Fail AOF menyimpan arahan redis Keseluruhan proses penyegerakan arahan ke fail AOF boleh dibahagikan kepada tiga peringkat:

Penyebaran arahan: Redis menghantar arahan yang dilaksanakan, parameter arahan, nombor parameter arahan dan maklumat lain ke program AOF.

• Penambahan cache: Program AOF menukar arahan ke dalam format protokol komunikasi rangkaian berdasarkan data arahan yang diterima, dan kemudian menambahkan kandungan protokol ke cache AOF pelayan.

• Menulis dan menyimpan fail: Kandungan dalam cache AOF ditulis ke penghujung fail AOF Jika syarat simpanan AOF yang ditetapkan dipenuhi, fungsi fsync atau fungsi fdatasync akan menjadi dipanggil , sebenarnya menyimpan kandungan bertulis ke cakera.

Penyebaran arahan

Apabila pelanggan Redis perlu melaksanakan arahan, ia menyambung melalui rangkaian , Hantar teks protokol ke pelayan Redis. Selepas pelayan menerima permintaan pelanggan, ia akan memilih fungsi arahan yang sesuai berdasarkan kandungan teks protokol, dan menukar setiap parameter daripada teks rentetan kepada objek rentetan Redis (StringObject). Apabila fungsi arahan berjaya dilaksanakan, parameter arahan akan disebarkan ke program AOF.

Cache Append

Apabila arahan disebarkan ke program AOF, program akan menukar arahan daripada objek rentetan kembali kepada teks protokol asal berdasarkan arahan dan parameter arahan . Selepas teks protokol dijana, ia akan dilampirkan pada penghujung aof_buf struktur redis.h/redisServer.

Struktur redisServer mengekalkan status pelayan Redis, dan medan aof_buf menyimpan semua teks protokol (RESP) menunggu untuk ditulis ke fail AOF

Menulis dan menyimpan fail

每当服务器常规任务函数被执行、或者事件处理器被执行时，aof.c/flushAppendOnlyFile 函数都会被调用，这个函数执行以下两个工作:

• WRITE:根据条件将aof_buf中的缓存写入到AOF文件。

• SAVE:根据条件调用fsync或 fdatasync函数将AOF文件保存到磁盘中。

AOF保存模式

Redis 目前支持三种 AOF 保存模式，它们分别是:

• AOF_FSYNC_NO :不保存。

• AOF_FSYNC_EVERYSEC :每一秒钟保存一次。(默认)

• AOF_FSYNC_ALWAYS :每执行一个命令保存一次。(不推荐)

AOF_FSYNC_NO

从不fsync，将数据交给操作系统来处理。更快，也更不安全的选择。

SAVE只会在以下任意一种情况中被执行:

• Redis被关闭

• AOF功能被关闭

• 系统的写缓存被刷新(可能是缓存已经被写满，或者定期保存操作被执行)

这三种情况下的SAVE操作都会引起Redis主进程阻塞。

AOF_FSYNC_EVERYSEC

SAVE原则上每隔一秒钟就会执行一次，因为SAVE操作是由后台子线程(fork)调用的， 所以它不会引起服务器主进程阻塞，并且在故障时只会丢失1秒钟的数据。

AOF_FSYNC_ALWAYS

每次执行完一个命令之后，WRITE和SAVE都会被执行。每次有新命令追加到AOF文件时就执行一次fsync，非常慢，也非常安全。

因为SAVE是由Redis主进程执行的，所以在SAVE执行期间，主进程会被阻塞，不能接受命令请求。

AOF保存模式对性能和安全性的影响

三种模式的比较

AOF重写

AOF记录数据的变化过程，越来越大，需要重写“瘦身”

Redis可以在AOF体积变得过大时，自动地在后台（Fork子进程）对AOF进行重写。

重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。

所谓的“重写”其实是一个有歧义的词语，实际上，AOF重写并不需要对原有的AOF文件进行任何写入和读取，它针对的是数据库中键的当前值。

举例说明

set s1 11
set s1 22
set s1 33

lpush list1 1 2 3
lpush list1 4 5 6

AOF重写后

set s1 33

lpush list1 1 2 3 4 5 6

Redis不希望AOF重写造成服务器无法处理请求，所以Redis决定将AOF重写程序放到（后台）子进程里执行，

• 1、子进程进行AOF重写期间，主进程可以继续处理命令请求。

• 2、子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。

不过，使用子进程也有一个问题需要解决：因为子进程在进行AOF重写期间，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改，这会让当前数据库的数据和重写后的AOF文件中的数据不一致。

为了解决这个问题，Redis增加了一个AOF重写缓存，这个缓存在fork出子进程之后开始启用，Redis主进程在接到新的写命令之后，除了会将这个写命令的协议内容追加到现有的AOF文件之外，还会追加到这个缓存中。

重写过程分析

Redis在创建新AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。

当子进程在执行AOF重写时，主进程需要执行以下三个工作：

• 处理命令请求。
• 将写命令追加到现有的AOF文件中。
• 将写命令追加到AOF重写缓存中

。这样一来可以保证：现有的AOF功能会继续执行，即使在AOF重写期间发生停机，也不会有任何数据丢失。所有对数据库进行修改的命令都会被记录到AOF重写缓存中。

当子进程完成AOF重写之后，它会向父进程发送一个完成信号，父进程在接到完成信号之后，会调用一个信号处理函数，并完成以下工作：

• 将AOF重写缓存中的内容全部写入到新AOF文件中。
• 对新的AOF文件进行改名，覆盖原有的AOF文件。

Redis数据库里的+AOF重写过程中的命令------->新的AOF文件---->覆盖老的当步骤1执行完毕之后，现有AOF文件、新AOF文件和数据库三者的状态就完全一致了。

当步骤2执行完毕之后，程序就完成了新旧两个AOF文件的交替。这个信号处理函数执行完毕之后，主进程就可以继续像往常一样接受命令请求了

。在整个AOF后台重写过程中，只有最后的写入缓存和改名操作会造成主进程阻塞，在其他时候，AOF后台重写都不会对主进程造成阻塞，这将AOF重写对性能造成的影响降到了最低。

AOF重写触发方式

• 1、配置触发

#表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100

#限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb

• 2、执行bgrewriteaof命令

127.0.0.1:6379>bgrewriteaof‘
Backgroundappendonlyfilerewritingstarted

AOF重写总结

混合持久化

RDB和AOF各有优缺点，Redis 4.0开始支持rdb和aof的混合持久化。

如果把混合持久化打开，aofrewrite的时候就直接把rdb的内容写到aof文件开头。

RDB的头+AOF的身体---->appendonly.aof

开启混合持久化

aof-use-rdb-preambleyes

AOF文件的载入与数据还原

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

于是在Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放，因此重启效率大幅得到提升。

• 1、创建一个不带网络连接的伪客户端（fake client）

因为Redis的命令只能在客户端上下文中执行，而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，所以服务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令，伪客户端执行命令的效果和带网络连接的客户端执行命令的效果完全一样

• 2、从AOF文件中分析并读取出一条写命令

• 3、使用伪客户端执行被读出的写命令

• 4、一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止

Redis数据备份策略

• 1.写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份

• 2.每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份

• 3.每次copy备份的时候，都把太旧的备份给删了

• 4.每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏

RDB和AOF对比

• 1、RDB存某个时刻的数据快照，采用二进制压缩存储，AOF存操作命令，采用文本存储(混合)

• 2、RDB性能高、AOF性能较低

• 3、RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF设置为每秒保存一次，则最多丢2秒的数据

• 4、Redis以主服务器模式运行，RDB不会保存过期键值对数据，Redis以从服务器模式运行，RDB会保存过期键值对，当主服务器向从服务器同步时，再清空过期键值对。AOF写入文件时，对过期的key会追加一条del命令，当执行AOF重写时，会忽略过期key和del命令。

更多编程相关知识，请访问：编程视频！！

Atas ialah kandungan terperinci Analisis terperinci mengenai mekanisme kegigihan dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!