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!
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.
Di Redis, teknologi untuk mencapai ketersediaan tinggi terutamanya termasuk kegigihan, pemisahan tuan-hamba, pengawal dan kelompok.
| 高可用策略 | 说明 |
|---|---|
| 持久化 | 持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。 |
| 主从复制 | 主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制。 |
| 哨兵 | 在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡，存储能力受到单机的限制。 |
| 集群 | 通过集群，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.
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.
Pencetusan kegigihan RDB dibahagikan kepada dua jenis: pencetus manual dan pencetus automatik.
[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
Selain menyelamatkan m n, terdapat beberapa situasi lain yang akan mencetuskan bgsave:
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.
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.
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...
Memandangkan setiap arahan tulis Redis perlu direkodkan, AOF tidak perlu dicetuskan Proses pelaksanaan AOF diperkenalkan di bawah.
Proses pelaksanaan AOF termasuk:
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.
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.
Terdapat tiga kaedah penyegerakan untuk strategi fail penyegerakan bagi cache AOF, yang dikonfigurasikan dengan mengubah suai baris 729 /etc/redis/6379.conf.
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.
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.
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.
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.
Sebab mengapa penulisan semula fail boleh memampatkan fail AOF ialah:
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.
Penulisan semula fail dibahagikan kepada pencetus manual dan pencetus automatik:
自动触发的配置位于/etc/redis/6379.conf的771行和772行
Proses penulisan semula fail adalah seperti berikut:
关于文件重写的流程，有两点需要特别注意：
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!
Perisian pangkalan data yang biasa digunakan
Apakah pangkalan data dalam memori?
Yang manakah mempunyai kelajuan bacaan yang lebih pantas, mongodb atau redis?
Cara menggunakan redis sebagai pelayan cache
Bagaimana redis menyelesaikan ketekalan data
Bagaimanakah mysql dan redis memastikan konsistensi penulisan dua kali?
Apakah data yang biasanya disimpan oleh redis cache?
Apakah 8 jenis data redis
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
