Mari kita bincangkan tentang mekanisme kegigihan Redis Sekiranya kita menggunakan RDB atau AOF?

Artikel ini akan membawa anda memahami mekanisme kegigihan Redis (RDB dan AOF), dan membincangkan sama ada untuk menggunakan RDB atau AOF? Semoga ia membantu semua orang!

RDB

1 Apakah itu RDB

RDB: Sekali-sekala, letakkan data. dalam memori Data ditulis pada fail sementara pada cakera sebagai syot kilat, dan fail syot kilat dibaca ke dalam ingatan semasa pemulihan. Jika ia ranap dan dimulakan semula, data dalam memori pasti akan hilang Kemudian ia akan dipulihkan selepas memulakan semula. [Cadangan berkaitan: Tutorial video Redis]

2. Sandaran dan pemulihan

Sandaran memori --> Fail sementara cakera
Fail --> Pulihkan ke ingatan

3 kelebihan dan kekurangan RDB

• Kelebihan

  • Sandarkan setiap kali masuk seketika, Sandaran penuh

  • Pemulihan bencana adalah mudah dan boleh dihantar dari jauh

  • Apabila proses anak disandarkan, proses utama akan tidak mempunyai sebarang operasi io (tidak (menulis, mengubah suai atau memadam), memastikan integriti data sandaran

  • Berbanding dengan AOF, apabila terdapat fail yang lebih besar, anda boleh memulakan semula dan memulihkan dengan cepat mereka

• Kelemahan

  • Sekiranya berlaku kegagalan, data sandaran terakhir mungkin hilang

  • Memori yang diduduki oleh nisbah proses kanak-kanak Ia akan sama persis dengan proses induk Jika ia akan menyebabkan beban CPU

  • Memandangkan sandaran penuh berjadual adalah operasi berat, nyata-. sandaran masa tidak dapat diproses.

4. Konfigurasi RDB

• simpan lokasi, anda boleh menyesuaikannya dalam redis .conf Definisi:
  /user/local/redis/working/dump.rdb

• Mekanisme simpanan:

save 900 1
save 300 10
save 60 10000
save 10 3

* 如果1个缓存更新，则15分钟后备份
* 如果10个缓存更新，则5分钟后备份
* 如果10000个缓存更新，则1分钟后备份

• stop-writes-on-bgsave-error

  • ya: Jika ralat berlaku semasa proses simpan, hentikan operasi menulis
  • tidak: Boleh menyebabkan data tidak konsisten

• rdbcompression

  • ya: Hidupkan mod mampatan rdb
  • tidak: Matikannya, yang akan menjimatkan CPU penggunaan, tetapi fail akan menjadi besar, sebab yang sama nginx

• rdbchecksum

  • ya: Gunakan pengesahan algoritma CRC64 untuk melaksanakan pengesahan data pada rdb , dengan kehilangan prestasi 10%
  • tidak: Tiada pengesahan

Ringkasan

RDB sesuai untuk pemulihan sejumlah besar data, tetapi integriti dan konsistensi data mungkin tidak mencukupi.

AOF

Ciri AOF

• Operasi tulis rekod yang diminta oleh pengguna dalam bentuk log. Operasi baca tidak dilog, kerana hanya operasi tulis disimpan.

• Fail dilampirkan dan bukannya diubah suai.

• Redis' aof recovery sebenarnya membaca dan menulis fail yang dilampirkan dari awal hingga akhir.

Kelebihan

• AOF lebih tahan lama dan boleh disandarkan dalam beberapa saat, ia akan berlaku hanya Kehilangan detik terakhir data sangat meningkatkan kebolehpercayaan dan integriti data. Jadi AOF boleh disandarkan sekali setiap saat, menggunakan operasi fsync.

• Lampirkan dalam bentuk log log Jika cakera penuh, alat redis-check-aof akan dilaksanakan

• Apabila. data terlalu besar, Redis boleh menulis semula secara automatik di latar belakang. Apabila redis terus menambahkan log ke fail lama, penulisan semula juga sangat selamat dan tidak akan menjejaskan operasi baca dan tulis klien.

• Semua operasi tulis yang disertakan dalam log AOF akan memudahkan untuk menghuraikan dan memulihkan redis.

Kelemahan

• Data yang sama, data yang sama, AOF lebih besar daripada RDB

• Untuk mekanisme penyegerakan yang berbeza, AOF akan lebih perlahan daripada RDB, kerana AOF akan membuat sandaran dan melakukan operasi tulis setiap saat, yang lebih rendah sedikit daripada RDB. Tidak ada yang salah dengan sandaran fsync setiap saat, tetapi jika pelanggan melakukan sandaran fsync setiap kali ia menulis, prestasi redis akan berkurangan.

• AOF mempunyai pepijat, iaitu data tidak lengkap semasa pemulihan data Ini menjadikan AOF lebih rapuh dan terdedah kepada pepijat, kerana AOF tidak semudah RDB, tetapi teratur. untuk mengelakkan pepijat dijana, AOF tidak akan dibina semula berdasarkan arahan lama, tetapi akan dibina semula berdasarkan arahan data yang sedia ada dalam cache pada masa itu, yang menjadikannya lebih mantap dan boleh dipercayai.

Konfigurasi AOF

`# AOF 默认关闭，yes可以开启
appendonly no

# AOF 的文件名
appendfilename "appendonly.aof"

# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec

# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no

# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
# 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb`

Perlukah kita menggunakan RDB atau AOF?

• Jika anda boleh menerima kehilangan cache untuk satu tempoh masa, anda boleh menggunakan RDB

• Jika anda lebih berhati-hati tentang sebenar -data masa , kemudian gunakan AOF

• Gunakan RDB dan AOF bersama-sama untuk kegigihan RDB digunakan sebagai sandaran sejuk, yang boleh memulihkan versi berbeza pada masa yang berbeza, dan AOF digunakan sebagai sandaran panas, memastikan data hanya hilang selama 1. kedua. Apabila AOF rosak dan tidak tersedia, kemudian gunakan RDB untuk memulihkannya, supaya kedua-duanya digabungkan Maksudnya, pemulihan Redis akan memuatkan AOF terlebih dahulu, dan jika terdapat masalah dengan AOF, ia akan memuatkan RDB semula, dengan itu. mencapai tujuan sandaran panas dan sejuk.

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

Atas ialah kandungan terperinci Mari kita bincangkan tentang mekanisme kegigihan Redis Sekiranya kita menggunakan RDB atau AOF?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!