Bagaimana untuk mengkonfigurasi ketersediaan tinggi dan ketekunan dalam redis

1. Ketersediaan Tinggi Redis

1 Gambaran Keseluruhan Ketersediaan Tinggi Redis

Dalam pelayan web, ketersediaan tinggi merujuk kepada masa semasa pelayan. boleh diakses seperti biasa , piawaian pengukuran ialah berapa lama ia boleh menyediakan perkhidmatan biasa (99.9%, 99.99%, 99.999%, dsb.). [Cadangan berkaitan: Tutorial video Redis]

  Walau bagaimanapun, dalam konteks Redis, maksud ketersediaan tinggi nampaknya lebih luas Selain memastikan penyediaan perkhidmatan biasa (seperti pemisahan tuan-hamba, cepat teknologi pemulihan bencana), kita juga perlu mempertimbangkan Pengembangan kapasiti data, keselamatan data tidak akan hilang, 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, untuk menyediakan sandaran bencana, fail berterusan boleh disalin ke lokasi terpencil.

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 masa yang ditetapkan selang (oleh itu juga Dipanggil kegigihan syot kilat), ia disimpan menggunakan pemampatan binari, dan 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 Pencetusan manual

• Kedua-dua arahan save dan perintah bgsave boleh menjana fail RDB.

• Arahan simpan akan menyekat proses pelayan Redis sehingga fail RDB dibuat Sepanjang tempoh pelayan Redis disekat, pelayan tidak boleh memproses sebarang permintaan arahan.

• Arahan bgsave akan memotong() proses anak, yang akan bertanggungjawab untuk mencipta fail RDB, manakala proses induk (iaitu proses utama Redis) akan terus memproses permintaan.

• Semasa pelaksanaan perintah bgsave, hanya proses anak fork yang akan menyekat pelayan Untuk arahan simpan, keseluruhan proses akan menyekat pelayan pada dasarnya dan mesti dihapuskan dalam persekitaran dalam talian Penggunaan simpan.

3.1.2 Pencetusan automatik

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

3.2 Kaedah konfigurasi

• Tetapkan dengan mengubah suai fail konfigurasi: simpan m n

• Secara automatik pencetus yang paling biasa ialah menghantar save m n dalam fail konfigurasi, yang menyatakan bahawa bgsave akan dicetuskan apabila n perubahan berlaku dalam masa 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

3.3 Mekanisme pencetus automatik lain

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

• Dalam senario replikasi induk-hamba, 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

• Proses induk Redis terlebih dahulu menentukan: sama ada ia sedang melaksanakan save atau bgsave Jika proses anak /bgrewriteaof sedang dilaksanakan, arahan bgsave akan kembali terus. 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.

• Apabila mencipta proses anak, proses induk melakukan operasi garpu, menyebabkan proses induk disekat dalam tempoh ini, Redis tidak dapat 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

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 perintah 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 开启 AOF

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置

[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...

4.2 执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。

AOF的执行流程包括：

• 命令追加（append）：将Redis的写命令追加到缓冲区aof_buf；

• 根据不同的同步策略，把aof_buf中的内容写入硬盘，并实现文件同步

• 文件重写（rewrite）：定期重写AOF文件，达到压缩的目的。

4.2.1 命令追加（append）

Redis先将命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO称为Redis负载的瓶颈。

命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单、避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

4.2.2 文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

4.2.3 三种同步方式

AOF缓存区的同步文件策略存在三种同步方式，通过对/etc/redis/6379.conf的729行的修改进行配置。

4.2.3.1 appendfsync always

将命令写入aof_buf后，立即进行系统fsync操作，将其同步到AOF文件，当fsync操作完成后，线程便会返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也就只能处理几万个命令，而且会大大降低SSD的寿命。

4.2.3.2 appendfsync no

命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负载，通常同步周期为30秒。文件同步时间不可预测，并且缓冲区中的数据会堆积很多，导致数据安全性无法保障。

4.2.3.3 appendfsync everysec（推荐）

命令写入aof_buf后调用系统write操作，write完成后线程返回：fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，一次是Redis的默认配置，也是我们推荐的配置。

4.2.4 文件重写（rewrite）

随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作。
关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些现实中，会关闭自动的文件重写，然后定时任务在每天的某一时刻定时执行。

4.2.4.1 具有压缩功能的原因

文件重写之所以能够压缩AOF文件，原因在于：

• 过期的数据不再写入文件。

• 无效的命令不再写入文件：如有些数据被重复设置（set mykey v1,set mykey v2）、有些数据被删除了（set myset v1,del myset）等。

• 多条命令可以合并为一个：如sadd myset v1,sadd myset v2,sadd myset v3可以合并为sadd myset v1 v2 v3。

通过上述原因可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。

4.2.4.2 文件重写的触发

文件重写分为手动触发和自动触发：

• Pencetusan manual: Panggil terus arahan bfrewriteaof Perlaksanaan arahan ini agak serupa dengan bgsave kedua-dua proses fork melakukan kerja tertentu, dan ia hanya disekat apabila melakukan fork.

• Pencetus 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 yang terakhir log Apabila saiz fail AOF (aof_base_size) digandakan semasa menulis semula, operasi bgrewriteaof berlaku

• auto-aof-rewrite-min-size 64mb
  Nilai minimum untuk melaksanakan bgrewriteaof arahan pada fail AOF semasa , untuk mengelakkan bgrewriteaof

4.2.4.3 Proses penulisan semula fail

penulisan semula fail kerana saiz fail yang kecil semasa mula-mula memulakan Redis Proses penulisan adalah seperti berikut:

• Proses induk Redis terlebih dahulu menentukan sama ada pada masa ini terdapat proses anak yang melaksanakan bgsave/bgrewriteaof jika wujud, arahan bgrewriteaof kembali terus, dan jika terdapat perintah bgsave, ia menunggu untuk bgsave Execute selepas pelaksanaan selesai.

• 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.

• Proses anak hanya boleh berkongsi data memori semasa operasi garpu Ini kerana operasi garpu menggunakan teknologi salin atas tulis. 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 selesai menulis fail AOF baharu, ia menghantar isyarat kepada proses induk dan proses induk mengemas kini 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 ibu bapa memotong proses anak

• Menulis Semula Dalam tempoh ini, arahan tulis yang dilaksanakan oleh Redis perlu dilampirkan pada fail AOF baharu Untuk tujuan ini, Redis memperkenalkan 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 dimatikan, 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 Kebaikan dan keburukan RDB dan AOF

Kegigihan RDB

Kebaikan: Fail RDB adalah padat dan kecil dalam saiz. Penghantaran rangkaian adalah pantas dan sesuai untuk salinan penuh; 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 kegigihan petikan data menentukan bahawa kegigihan 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 everysec), tekanan IO lebih tinggi, malah mungkin terdapat masalah penyekatan tambahan dalam AOF.

Sama seperti bgsave RDB, penulisan semula fail AOF juga akan menghadapi masalah sekatan garpu dan beban IO proses anak. AOF menulis data ke cakera keras dengan lebih kerap, yang 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 semasa operasi penulisan semula, dan melaksanakannya pada awal pagi apabila volum perniagaan rendah, untuk mengurangkan kesan AOF terhadap prestasi proses utama dan tekanan Literasi IO.

Atas ialah kandungan terperinci Bagaimana untuk mengkonfigurasi ketersediaan tinggi dan ketekunan dalam redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!