Artikel ini akan membincangkan tentang ketersediaan tinggi dan ketekunan dalam redis, dan melihat fungsi kegigihan dan dua kaedah Redis (RDB dan AOF, saya harap ia akan membantu anda!

Penjelasan terperinci tentang ketersediaan tinggi dan kegigihan dalam redis

1. Redis High Availability

1 Gambaran Keseluruhan Redis High Availability

Dalam pelayan web, ketersediaan tinggi bermakna pelayan boleh. beroperasi secara normal Masa capaian diukur mengikut tempoh masa yang diperlukan untuk menyediakan perkhidmatan biasa (99.9%, 99.99%, 99.999%, dsb.). [Cadangan berkaitan: Tutorial video Redis]

Tetapi dalam konteks Redis, maksud ketersediaan tinggi nampaknya lebih luas, selain memastikan penyediaan perkhidmatan biasa (seperti master -pemisahan hamba, teknologi pemulihan bencana pesat), ia juga perlu untuk mempertimbangkan pengembangan kapasiti data, keselamatan data dan tiada kehilangan, dsb.

2. Strategi ketersediaan tinggi Redis

Di Redis, teknologi untuk mencapai ketersediaan tinggi terutamanya termasuk kegigihan, pemisahan tuan-hamba, pengawal dan kelompok.

高可用策略	说明
持久化	持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
主从复制	主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制。
哨兵	在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡，存储能力受到单机的限制。
集群	通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

2. Kegigihan Redis

1. Fungsi kegigihan Redis

Redis ialah pangkalan data dalam memori, dan data disimpan dalam memori untuk mengelakkan proses Redis yang disebabkan oleh kuasa pelayan gangguan dan sebab-sebab lain Untuk kehilangan data yang kekal selepas keluar yang tidak normal, data dalam Redis perlu disimpan secara tetap dari memori ke cakera keras dalam beberapa bentuk (data atau arahan apabila Redis dimulakan semula pada masa akan datang, fail berterusan digunakan untuk mencapainya); pemulihan data. Di samping itu, fail berterusan boleh disalin ke lokasi terpencil untuk tujuan sandaran bencana.

2. Dua cara kegigihan Redis

Kegigihan RDB
Prinsipnya adalah dengan kerap menyimpan rekod pangkalan data Redis dalam ingatan ke cakera.
Kegigihan AOF (lampirkan fail sahaja)
Prinsipnya adalah untuk menulis log operasi Redis ke fail dengan cara tambahan, serupa dengan binlog MySQL.
Memandangkan kegigihan AOF mempunyai prestasi masa nyata yang lebih baik, iaitu, kurang data yang hilang apabila proses keluar secara tidak dijangka, AOF kini merupakan kaedah kegigihan arus perdana, tetapi kegigihan RDB masih ada tempatnya.

3. Kegigihan RDB

Kegigihan RDB merujuk kepada menjana syot kilat data dalam proses semasa dalam ingatan dan menyimpannya ke cakera keras dalam selang masa yang ditentukan (jadi ia juga dipanggil snapshot Persistence), menggunakan storan mampatan binari, akhiran fail yang disimpan ialah rdb apabila Redis dimulakan semula, fail syot kilat boleh dibaca untuk memulihkan data.

3.1 Keadaan pencetus

Pencetusan kegigihan RDB dibahagikan kepada dua jenis: pencetus manual dan pencetus automatik.

3.1.1 Mencetuskan secara manual

Kedua-dua arahan save dan perintah bgsave boleh menjana fail RDB.
Arahan simpan akan menyekat proses pelayan Redis sehingga fail RDB dibuat Semasa pelayan Redis disekat, pelayan tidak boleh memproses sebarang permintaan arahan.
Arahan bgsave akan memotong() proses anak Proses anak akan bertanggungjawab untuk mencipta fail RDB, dan proses induk (iaitu proses utama Redis) akan terus memproses permintaan.
Semasa pelaksanaan perintah bgsave, hanya proses anak fork akan menyekat pelayan, manakala untuk arahan simpan, keseluruhan proses akan menyekat pelayan Oleh itu, simpan pada dasarnya telah ditinggalkan, dan penggunaan simpan mesti dihapuskan dalam persekitaran dalam talian.

3.1.2 Pencetusan automatik

Apabila kegigihan RDB dicetuskan secara automatik, Redis juga akan memilih bgsave dan bukannya simpan untuk kegigihan.

3.2 Kaedah konfigurasi

Tetapkan dengan mengubah suai fail konfigurasi: save m n
Situasi pencetus automatik yang paling biasa adalah melalui simpan dalam fail konfigurasi m n, menyatakan bahawa bgsave akan dicetuskan apabila n perubahan berlaku dalam m saat.

[root@localhost ~]# vim /etc/redis/6379.conf ##219行，以下三个save条件满足任意一个时，都会引起bgsave的调用save 900 1	##当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsavesave 300 10	##当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsavesave 60 10000	##当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave##254行，指定RDB文件名dbfilename dump.rdb##264行，指定RDB文件和AOF文件所在目录dir /var/lib/redis/6379##242行，是否开启RDB文件压缩rdbcompression yes

Salin selepas log masuk

3.3 Mekanisme pencetus automatik lain

Selain menyelamatkan m n, terdapat beberapa situasi lain yang akan mencetuskan bgsave:

Semasa master -replikasi hamba Dalam senario ini, jika nod hamba melakukan operasi salinan penuh, nod induk akan melaksanakan perintah bgsave dan menghantar fail rdb ke nod hamba.
Apabila melaksanakan arahan penutupan, kegigihan rdb dilakukan secara automatik.

3.4 Proses pelaksanaan

Penjelasan terperinci tentang ketersediaan tinggi dan kegigihan dalam redis

Proses induk Redis terlebih dahulu menentukan sama ada ia sedang melaksanakan save atau proses anak bgsave/ bgrewriteaof, Jika ia sedang dilaksanakan, arahan bgsave kembali secara langsung. Sub-proses bgsave/bgrewriteaof tidak boleh dilaksanakan pada masa yang sama, terutamanya disebabkan oleh pertimbangan prestasi; dua sub-proses serentak melaksanakan sejumlah besar operasi tulis cakera pada masa yang sama, yang boleh menyebabkan masalah prestasi yang serius.
Proses induk menjalankan operasi fork untuk mencipta proses anak Semasa proses ini, proses induk disekat dan Redis tidak boleh melaksanakan sebarang arahan daripada klien.
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
Proses anak mencipta fail RDB , yang dijana berdasarkan petikan memori proses induk Fail petikan sementara, penggantian atom fail asal selepas selesai
Proses anak menghantar isyarat kepada proses induk untuk menunjukkan selesai dan proses induk mengemas kini statistik

3.5 Memuatkan semasa permulaan

Pemuatan fail RDB dilaksanakan secara automatik apabila pelayan bermula, dan tiada arahan khas. Walau bagaimanapun, kerana AOF mempunyai keutamaan yang lebih tinggi, apabila AOF dihidupkan, Redis akan memberi keutamaan untuk memuatkan fail AOF untuk memulihkan data hanya apabila AOF dimatikan, fail RDB akan dikesan apabila pelayan Redis bermula dan dimuatkan secara automatik. Pelayan disekat semasa memuatkan fail RDB sehingga pemuatan selesai.
Apabila Redis memuatkan fail RDB, ia akan mengesahkan fail RDB Jika fail itu rosak, ralat akan dicetak dalam log dan Redis akan gagal dimulakan.

4. Kegigihan AOF

Kegigihan RDB menulis data proses ke fail, manakala kegigihan AOF merekodkan setiap arahan tulis dan padam yang dilaksanakan oleh Redis ke fail log yang berasingan, operasi pertanyaan tidak akan direkodkan; apabila Redis dimulakan semula, laksanakan arahan dalam fail AOF sekali lagi untuk memulihkan data.
Berbanding dengan RDB, AOF mempunyai prestasi masa nyata yang lebih baik, jadi ia telah menjadi penyelesaian kegigihan arus perdana.

4.1 Hidupkan AOF

Pelayan Redis menghidupkan RDB secara lalai dan mematikan AOF, untuk menghidupkan AOF, anda perlu mengkonfigurasinya dalam fail konfigurasi

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...

Salin selepas log masuk

4.2 Proses pelaksanaan

Memandangkan setiap arahan tulis Redis perlu direkodkan, AOF tidak perlu dicetuskan Proses pelaksanaan AOF diperkenalkan di bawah.

Proses pelaksanaan AOF termasuk:

Perintah tambah (tambah): tambahkan arahan tulis Redis pada penimbal aof_buf
Penulisan fail (tulis) dan penyegerakan fail (segerak): tambah aof_buf mengikut strategi penyegerakan yang berbeza Kandungannya adalah disegerakkan ke cakera keras;
Tulis semula fail (tulis semula): Tulis semula fail AOF dengan kerap untuk mencapai tujuan pemampatan.

4.2.1 Lampiran Perintah

Redis terlebih dahulu menambahkan arahan pada penimbal dan bukannya menulisnya terus ke fail, terutamanya untuk mengelakkan terus menulis arahan setiap kali Menulis ke hard cakera menyebabkan IO cakera keras menjadi hambatan beban Redis. Format yang dilampirkan oleh perintah

ialah format protokol yang diminta oleh arahan Redis Ia adalah format teks biasa dan mempunyai kelebihan keserasian yang baik, kebolehbacaan yang kuat, pemprosesan yang mudah, operasi mudah dan mengelakkan overhed sekunder. . Dalam fail AOF, kecuali untuk arahan pilih yang digunakan untuk menentukan pangkalan data (seperti pilih 0 untuk memilih pangkalan data No. 0), yang ditambahkan oleh Redis, yang lain adalah arahan tulis yang dihantar oleh klien.

4.2.2 Penulisan fail (tulis) dan penyegerakan fail (segerak)

Redis menyediakan pelbagai strategi fail penyegerakan penimbal AOF, yang melibatkan fungsi tulis dan fsync sistem pengendalian , penerangan adalah seperti berikut:
Untuk meningkatkan kecekapan penulisan fail, dalam sistem pengendalian moden, apabila pengguna memanggil fungsi tulis untuk menulis data ke fail, sistem pengendalian biasanya menyimpan data sementara ke dalam penimbal memori. Apabila penimbal Data dalam penimbal sebenarnya ditulis ke cakera keras hanya selepas ia diisi atau melebihi had masa yang ditetapkan. 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.

4.2.3 Tiga kaedah penyegerakan

Terdapat tiga kaedah penyegerakan untuk strategi fail penyegerakan bagi cache AOF, yang dikonfigurasikan dengan mengubah suai baris 729 /etc/redis/6379.conf.

4.2.3.1 appendfsync sentiasa

Sejurus selepas arahan ditulis ke aof_buf, operasi fsync sistem 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.

4.2.3.2 appendfsync no

Arahan memanggil operasi tulis sistem selepas menulis ke aof_buf, dan tidak melakukan penyegerakan fsync bagi fail AOF, 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.

4.2.3.3 appendfsync everysec (disyorkan)

Operasi tulis sistem dipanggil selepas arahan ditulis kepada aof_buf Selepas penulisan selesai, benang mengembalikan: operasi fail penyegerakan fsync dipanggil sekali sesaat oleh benang khusus. everysec ialah kompromi antara dua strategi yang disebutkan di atas, keseimbangan antara prestasi dan keselamatan data Ia adalah konfigurasi lalai Redis dan konfigurasi kami yang disyorkan.

4.2.4 Tulis semula fail (tulis semula)

Seiring dengan berlalunya masa, pelayan Redis melaksanakan lebih banyak arahan tulis, dan fail AOF akan menjadi lebih besar dan lebih besar; besar Fail bukan sahaja akan menjejaskan operasi biasa pelayan, tetapi juga menyebabkan pemulihan data mengambil masa terlalu lama.
Penulisan semula fail merujuk kepada penulisan semula fail AOF dengan kerap untuk mengurangkan saiz fail AOF. Perlu diingatkan bahawa penulisan semula AOF menukarkan data dalam proses Redis kepada arahan tulis dan menyegerakkannya ke fail AOF baharu tiada operasi membaca atau menulis dilakukan pada fail AOF lama.
Perkara lain yang perlu diberi perhatian tentang penulisan semula fail ialah: untuk kegigihan AOF, walaupun penulisan semula fail sangat disyorkan, ia tidak perlu walaupun tanpa penulisan semula fail, data boleh diteruskan dan disimpan dalam Redis diimport apabila ia bermula; realiti, penulisan semula fail automatik akan dimatikan, dan kemudian tugas yang dijadualkan akan dilaksanakan pada masa tertentu setiap hari.

4.2.4.1 Sebab untuk fungsi pemampatan

Sebab mengapa penulisan semula fail boleh memampatkan fail AOF ialah:

Data tamat tempoh tidak lagi ditulis pada fail .
Arahan tidak sah tidak lagi ditulis pada fail: contohnya, sesetengah data ditetapkan berulang kali (set mykey v1, set mykey v2), sesetengah data dipadamkan (set myset v1, del myset), dsb.
Berbilang arahan boleh digabungkan menjadi satu: seperti sadd myset v1, sadd myset v2, sadd myset v3 boleh digabungkan menjadi sadd myset v1 v2 v3.

Ia boleh dilihat daripada sebab di atas bahawa memandangkan AOF melaksanakan lebih sedikit arahan selepas menulis semula, penulisan semula fail bukan sahaja dapat mengurangkan ruang yang diduduki oleh fail, tetapi juga mempercepatkan kelajuan pemulihan.

4.2.4.2 Pencetusan penulisan semula fail

Penulisan semula fail dibahagikan kepada pencetus manual dan pencetus automatik:

Pencetus manual: Panggil terus perintah bfrewriteaof Perlaksanaan arahan ini agak serupa dengan bgsave kedua-dua proses fork melakukan kerja tertentu, dan mereka hanya menyekat apabila melakukan forking.
Citus secara automatik: bgrewriteaof dilaksanakan secara automatik dengan menetapkan pilihan auto-aof-rewrite-min-size dan pilihan auto-aof-rewrite-percentage. Hanya apabila dua pilihan auto-aof-rewrite-min-size dan auto-aof-rewrite-peratusan berpuas hati pada masa yang sama, AOF menulis semula, iaitu, operasi bgrewriteaof akan dicetuskan secara automatik.

自动触发的配置位于/etc/redis/6379.conf的771行和772行

auto-aof-rewrite-percentage 100
Saiz fail AOF semasa (iaitu aof_current_size) ialah saiz fail AOF apabila log terakhir telah ditulis semula (aof_base_size) dua kali, operasi bgrewriteaof berlaku
auto-aof-rewrite-min-size 64mb
Nilai minimum untuk melaksanakan perintah bgrewriteaof pada fail AOF semasa untuk mengelakkan saiz fail kecil apabila memulakan Redis. Membawa kepada bgrewriteaof yang kerap

4.2.4.3 Proses penulisan semula fail

Penjelasan terperinci tentang ketersediaan tinggi dan kegigihan dalam redis
Proses penulisan semula fail adalah seperti berikut:

Redis Proses induk terlebih dahulu menentukan sama ada terdapat proses anak yang sedang melaksanakan bgsave/bgrewriteaof jika wujud, arahan bgrewriteaof akan kembali secara langsung Jika perintah bgsave wujud, ia menunggu sehingga pelaksanaan bgsave selesai sebelum melaksanakannya.
Proses induk menjalankan operasi garpu untuk mencipta proses anak Semasa proses ini, proses induk disekat.
Selepas proses induk berhenti, perintah bgrewriteaof mengembalikan mesej "Latar belakang tambah hanya penulisan semula fail dimulakan" dan tidak lagi menyekat proses induk dan boleh bertindak balas kepada arahan lain. Semua arahan tulis Redis masih ditulis pada penimbal AOF dan disegerakkan ke cakera keras mengikut dasar appendfsync untuk memastikan ketepatan mekanisme AOF asal.
Memandangkan 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 data ini untuk mengelakkan bahagian data ini hilang semasa penjanaan fail AOF baharu. Dalam erti kata lain, semasa pelaksanaan bgrewriteaof, arahan tulis Redis dilampirkan pada kedua-dua penimbal aof_buf dan aof_rewrite_buf pada masa yang sama.
Proses anak menulis ke fail AOF baharu mengikut petikan memori dan peraturan penggabungan arahan.
Selepas proses anak menulis fail AOF baharu, ia menghantar isyarat kepada proses induk dan proses induk mengemas kini maklumat statistik, yang boleh dilihat melalui ketekunan maklumat.
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.
Ganti fail lama dengan fail AOF baharu dan tulis semula ke dalam AOF.

关于文件重写的流程，有两点需要特别注意：

Penulisan semula dilakukan oleh proses induk memotong proses anak
Arahan tulis yang dilaksanakan oleh Redis semasa penulisan semula perlu ditambahkan pada yang baharu Dalam fail AOF, Redis memperkenalkan contohnya cache aof_rewrite_buf

4.3 Memuatkan semasa permulaan

Apabila AOF dihidupkan, Redis akan memuatkan fail AOF terlebih dahulu untuk memulihkan data apabila ia bermula ;Hanya apabila AOF ditutup, fail RDB akan dimuatkan untuk memulihkan data.
Apabila AOF dihidupkan tetapi fail AOF tidak wujud, fail RDB tidak akan dimuatkan walaupun ia wujud.
Apabila Redis memuatkan fail AOF, ia akan mengesahkan fail AOF Jika fail itu rosak, ralat akan dicetak dalam log dan Redis akan gagal dimulakan. Walau bagaimanapun, jika penghujung fail AOF tidak lengkap (masa henti mesin secara tiba-tiba boleh menyebabkan penghujung fail tidak lengkap dengan mudah), dan parameter aof_load_truncated dihidupkan, amaran akan dikeluarkan dalam log, dan Redis akan mengabaikan penghujung fail AOF dan mulakan dengan jayanya. Parameter aof_load_truncated didayakan secara lalai.

5. Kelebihan dan kekurangan RDB dan AOF

Kegigihan RDB

Kebaikan: Fail RDB adalah padat, bersaiz kecil dan pantas dalam penghantaran rangkaian, sesuai untuk salinan penuh kelajuan pemulihan adalah lebih cepat daripada AOF. Sudah tentu, salah satu kelebihan RDB yang paling penting ialah ia mempunyai kesan yang agak kecil terhadap prestasi berbanding dengan AOF.
Kelemahan: Kelemahan fail RDB yang terkenal ialah kaedah ketekalan syot kilat data menentukan bahawa ketekunan masa nyata tidak dapat dicapai Hari ini, apabila data menjadi semakin penting, kehilangan data yang besar 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).
Untuk kegigihan RDB, dalam satu pihak, proses utama Redis akan disekat apabila bgsave melakukan operasi fork Sebaliknya, data penulisan sub-proses ke cakera keras juga akan membawa tekanan IO.

Kegigihan AOF

Sejajar dengan kegigihan RDB, keutamaan AOF adalah untuk menyokong kegigihan peringkat kedua dan keserasian yang baik. Kelemahannya ialah fail besar dan kelajuan pemulihan yang perlahan. , yang mempunyai kesan yang besar terhadap prestasi.

Untuk kegigihan AOF, kekerapan menulis data ke cakera keras sangat meningkat (tahap kedua di bawah dasar setiap detik), tekanan IO lebih tinggi, malah mungkin terdapat masalah penyekatan tambahan dalam AOF.

Penulisan semula fail AOF adalah serupa dengan bgsave RDB, dan akan terdapat masalah dengan penyekatan semasa fork dan tekanan IO pada proses anak. Secara relatifnya, kerana AOF menulis data ke cakera keras dengan lebih kerap, ia akan memberi kesan yang lebih besar terhadap prestasi proses utama Redis.

Secara umumnya, adalah disyorkan untuk mematikan fungsi penulisan semula automatik AOF, dan menetapkan tugas berjadual untuk operasi penulisan semula, dan melaksanakannya pada awal pagi apabila volum perniagaan rendah, untuk mengurangkan kesan daripada AOF pada prestasi proses utama dan tekanan baca dan tulis IO .

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

Atas ialah kandungan terperinci Penjelasan terperinci tentang ketersediaan tinggi dan kegigihan dalam redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!