Bagaimana untuk melaksanakan kegigihan Redis

Redis ialah pangkalan data nilai kunci lanjutan. Ia serupa dengan memcached, tetapi data boleh dikekalkan dan menyokong pelbagai jenis data. Terdapat rentetan, senarai terpaut, set dan set diisih. Ia menyokong pengiraan kesatuan, persilangan dan pelengkap (perbezaan) set pada bahagian pelayan, dan juga menyokong pelbagai fungsi pengisihan.

Redis menyokong dua mekanisme kegigihan: RDB dan AOF boleh mengelakkan kehilangan data yang disebabkan oleh proses keluar atau masa henti yang tidak normal, dan boleh digunakan sebelum didayakan semula fail berterusan pemulihan data.

Kegigihan RDB

Kegigihan RDB ialah kaedah kegigihan yang menyimpan data lengkap pada masa tertentu dengan mencipta petikan fail binari termampat. Kegigihan RDB ialah kaedah kegigihan lalai Redis. Pencetusan kegigihan RDB termasuk pencetus manual dan pencetus automatik.

Cetuskan secara manual

simpan dan laksanakan arahan simpan pada baris arahan Fail rdb akan dibuat serentak untuk menyimpan syot kilat, yang akan menyekat proses utama pelayan bgsave dalam persekitaran pengeluaran Dalam perintah Melaksanakan perintah bgsave akan mencipta fail rdb secara tidak segerak dan menyimpan gambar dengan memotong sub-proses Kecuali untuk penyekatan semasa fork, apabila sub-proses mencipta fail rdb, proses utama boleh terus memproses permintaan

Pencetus secara automatik

Konfigurasikan save m n dalam redis.conf untuk dicetuskan dengan kerap Contohnya, simpan 900 1 bermakna apabila terdapat sekurang-kurangnya satu kemas kini dalam 900s, replikasi induk-hamba dicetuskan Jika nod hamba melakukan operasi salinan penuh, nod induk secara automatik melaksanakan bgsave untuk menjana fail RDB dan dihantar ke nod hamba untuk melaksanakan perintah muat semula nyahpepijat, penutupan akan dilaksanakan dan Kegigihan AOF tidak didayakan. Konfigurasi kegigihan RDB dalam redis.conf

# 只要满足下列条件之一，则会执行bgsave命令save 900 1 # 在900s内存在至少一次写操作save 300 10
save 60 10000# 禁用RBD持久化，可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作stop-writes-on-bgsave-error yes# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵rdbcompression no

Kegigihan AOF

Kegigihan AOF (Tambah-Sahaja-Fail) merekodkan semua arahan yang mengubah status pangkalan data dan menambahkannya ke fail AOF dalam bentuk lampiran. Satu cara untuk menulis semula ialah: Apabila pelayan dimulakan semula, anda boleh menggunakan arahan yang direkodkan dalam fail AOF untuk memulihkan keadaan pangkalan data apabila ia ditutup sebelum ini.

Konfigurasi kegigihan AOF dalam redis.conf adalah seperti berikut

# 默认关闭AOF，若要开启将no改为yesappendonly no# append文件的名字appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写auto-aof-rewrite-min-size 64mb

Pelaksanaan kegigihan AOF merangkumi 3 langkah:

Tambah perintah: Tambahkan perintah pada fail penimbal AOF untuk menulis Input: Kandungan penimbal ditulis ke fail AOF: Fail AOF disimpan ke cakera Kekerapan dua langkah terakhir dikonfigurasikan melalui appendfsync termasuk

selalu , yang disimpan sebaik sahaja setiap arahan dilaksanakan untuk keselamatan Paling tinggi, hanya satu data yang hilang, tetapi prestasinya juga adalah yang paling rendah (IO cakera kerap) setiap saat, disimpan sekali setiap saat, disyorkan, kompromi antara keselamatan dan. prestasi, tiada data hilang selama satu saat paling banyak, bergantung pada Sistem pengendalian melaksanakannya (biasanya sekali setiap 30 saat), dengan keselamatan terendah dan prestasi tertinggi Data selepas kali terakhir sistem pengendalian mencetuskan operasi SAVE pada Fail AOF hilang. AOF diteruskan melalui arahan simpan Seiring dengan berlalunya masa, fail AOF akan menjadi lebih besar dan lebih besar. pemulihan data). Prinsipnya adalah seperti berikut:

Panggilan garpu untuk mencipta Proses anak

Proses anak membaca status pangkalan data semasa untuk "menulis semula" fail AOF baharu (walaupun ia dipanggil "penulisan semula" di sini, ia sebenarnya tidak membaca fail lama, tetapi Borang arahan berdasarkan status semasa pangkalan data)

Proses utama terus menulis perubahan baharu pada penimbal tulis semula AOF dan yang asal Penampan AOF pada masa yang sama

Proses utama memperoleh penulisan semula sub-proses Tulis isyarat penyiapan AOF, panggil fungsi pemprosesan isyarat untuk menulis kandungan penimbal tulis semula AOF ke dalam fail AOF baharu, namakan semula fail baharu, tulis ganti fail AOF asal secara atom, dan lengkapkan penggantian fail lama dan baharu

Penulisan semula AOF juga dibahagikan kepada pencetus manual dan pencetus automatik

手动触发： 直接调用bgrewriteaof命令
自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

RDB vs AOF

RDB dan AOF mempunyai kelebihan dan kekurangan yang tersendiri.

Kelebihan RDB: Berbanding dengan AOF, fail RDB secara relatifnya lebih kecil dan pemulihan data lebih cepat (lihat bahagian pemulihan data atas sebab) Kelemahan RDB: Apabila pelayan tidak berfungsi, kaedah RBD akan kehilangan yang terakhir. Kegigihan RDB Data akhir menggunakan bgsave untuk menghentikan proses kanak-kanak akan menggunakan memori. Kelebihan AOF: AOF hanya menambahkan fail, mempunyai kesan yang kurang pada prestasi pelayan, lebih pantas daripada RDB, menggunakan kurang memori dan mempunyai kebolehbacaan yang tinggi. Menggunakan AOF akan membawa dua kelemahan: fail yang dihasilkan adalah agak besar, walaupun ia ditulis semula oleh AOF, ia akan tetap besar pada masa yang sama, kelajuan pemulihan data juga lebih perlahan daripada RDB. Pemulihan pangkalan data

Jika fungsi kegigihan AOF tidak dihidupkan, apabila pelayan bermula, proses utama akan disekat semasa fail RDB dimuatkan secara automatik. Jika fungsi kegigihan AOF dihidupkan, pelayan akan memberi keutamaan untuk menggunakan fail AOF untuk memulihkan keadaan pangkalan data, kerana kekerapan kemas kini fail AOF biasanya lebih tinggi daripada fail RDB, dan data yang disimpan adalah lebih lengkap.

Aliran pemprosesan pemulihan pangkalan data redis adalah seperti berikut,

Dari segi pemulihan data, masa permulaan RDB akan menjadi lebih pendek atas dua sebab:

Dalam RDB fail, setiap Terdapat hanya satu rekod untuk setiap item data, tidak seperti log AOF yang mungkin terdapat berbilang rekod operasi untuk satu item data. Jadi setiap sekeping data hanya perlu ditulis sekali, dan failnya agak kecil.

RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

但是在进行RDB持久化时，fork出来进行dump操作的子进程会占用与父进程一样的内存，采用的copy-on-write机制，对性能的影响和内存的消耗都是比较大的。比如16G内存，Redis已经使用了10G，这时save的话会再生成10G，变成20G，大于系统的16G。这时候会发生交换，要是虚拟内存不够则会崩溃，导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。这个方案的优势在于其充分利用了RDB加载速度快、备份体积小以及AOF记录数据丢失几率尽可能低的特点。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

开启混合持久化

aof-use-rdb-preamble yes

数据恢复加载过程就是先按照RDB进行加载，然后把AOF命令追加写入。

持久化方案的建议 如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。建议同时采用两种持久化方式，以提高数据的安全性。如果你可以容忍在灾难发生时数据丢失几分钟，那么可以仅使用RDB。一般的设计方法是 使用主从复制机制以解决持久化时所带来的性能影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

Atas ialah kandungan terperinci Bagaimana untuk melaksanakan kegigihan Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!