一、Redis 高可用
1. Redis 高可用概述
在web伺服器中，高可用是指伺服器可以正常存取的時間，衡量的標準是在多長時間內可以提供正常服務（99.9%、99.99%、99.999%等等）。 【相關推薦：Redis影片教學】
但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務（如主從分離、快速容災技術），還需要考慮資料容量的擴展、資料安全不會遺失等。
2. Redis 高可用策略
在Redis中，實現高可用的技術主要包括持久化、主從分離、哨兵和叢集。
| 高可用策略 |
說明 |
|
|
|
|
|
|
|
持久化是最簡單的高可用方法（有時甚至不被歸類為高可用的手段），主要作用是資料備份，即將資料儲存在硬碟，保證資料不會因進程退出而遺失。 |
主從複製######主從複製是高可用Redis的基礎，哨兵和叢集都是在主從複製基礎上實現高可用的。主從複製主要實現了資料的多機備份，以及對於讀取操作的負載平衡和簡單的故障還原。缺陷：故障復原無法自動化，寫入操作無法負載平衡，儲存能力受到單機的限制。 ############哨兵######在主從複製的基礎上，哨兵實現了自動化的故障復原。缺陷：寫入操作無法負載平衡，儲存能力受到單機的限制。 ############集群######透過集群，Redis解決了寫入操作無法負載平衡，以及儲存能力受到單機限制的問題，實現了較為完善的高可用方案。 ############
二、Redis 持久化
1. Redis 持久化的功能
Redis是記憶體資料庫，資料都是儲存在記憶體中，為了避免伺服器斷電等原因導致Redis進程異常退出後資料的永久遺失，需要定期將Redis中的資料以某種形式（資料或命令）從記憶體保存到硬碟；當下次Redis重啟時，利用持久化檔案實現資料復原。另外，為了做好應對災害的備份工作，可以將持久化檔案複製到遠端位置。
2. Redis 持久化的兩種方式
3. RDB 持久化
RDB持久化是指在指定的時間間隔內將記憶體中目前進程中的資料產生快照儲存到硬碟（因此也稱為快照持久化），用二進制壓縮存儲，保存的文件後綴是rdb；當Redis重新啟動時，可以讀取快照文件恢復資料。
3.1 觸發條件
RDB持久化的觸發分為手動觸發和自動觸發兩種。
3.1.1 手動觸發
save指令和bgsave指令都可以產生RDB檔。
save指令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何指令請求。
bgsave指令會fork()一個子程序，由子程序來負責建立RDB文件，父行程（即Redis主行程）則會繼續處理請求。
bgsave指令執行過程中，只有fork子程序時會阻塞伺服器，而對於save指令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用。
3.1.2 自動觸發
3.2 設定方式
3.3 其他自動觸發機制
除了save m n以外，還有一些其他情況會觸發bgsave:
- 在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb檔案傳送給從節點。
- 執行shutdown指令時，自動執行rdb持久化。
3.4 執行流程
- #Redis父程式先判斷：目前是否在執行save，或bgsave /bgrewriteaof的子進程，如果在執行則bgsave指令直接回傳。 bgsave/bgrewriteaof的子程序不能同時執行，主要是基於效能方面的考量；兩個並發的子程序同時執行大量的磁碟寫入操作，可能會造成嚴重的效能問題。
- 在建立子進程時，父進程執行了fork操作，導致父進程被阻塞，在此期間Redis無法執行來自客戶端的任何命令。
- 父進程fork後，bgsave命令返回「Background saving started」訊息並不再阻塞父進程，並且可以回應其他命令
- 子程序創建RDB文件，根據父進程內存快照生成臨時快照文件，完成後對原有文件進行原子替換
- 子進程發送信號給父進程表示完成，父進程更新統計資料
3.5 啟動時載入
RDB檔案的載入工作是在伺服器啟動時自動執行的，並沒有專門的指令。但是由於AOF的優先順序較高，因此當AOF開啟時，Redis會優先載入AOF檔來恢復資料；只有當AOF關閉時，才會在Redis伺服器啟動時偵測RDB文件，並自動載入。伺服器載入RDB檔案期間處於阻塞狀態，直到載入完成為止。
Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。
4. AOF 持久化
RDB持久化是將進程資料寫入文件，而AOF持久化則是將Redis執行的每次寫、刪除命令記錄到單獨的日誌文件中，查詢操作不會記錄；當Redis重啟時再次執行AOF檔案中的命令來恢復資料。
與RDB相比，AOF的即時性較好，因此已成為主流的持久化方案。
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 文件重写的触发
文件重写分为手动触发和自动触发：
手動觸發：直接呼叫bfrewriteaof指令，該指令的執行與bgsave有些類似，都是fork進程進行具體的工作，且都只有在fork時阻塞。
自動觸發：透過設定auto-aof-rewrite-min-size選項和auto-aof-rewrite-percentage選項自動執行bgrewriteaof。只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個選項同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。
自動觸發的設定位於/etc/redis/6379.conf的771行和772行
父進程fork後，bgrewriteaof指令傳回「Background append only file rewrite started」訊息並不再阻塞父行程，並且可以回應其他指令。 Redis的所有寫入指令仍寫入AOF緩衝區，並依照appendfsync策略同步到硬碟，確保原有AOF機制的正確。
- 子程序只能共享fork操作時的記憶體數據，這是因為fork操作使用了寫入時複製技術。由於父進程仍在回應指令，Redis使用AOF重寫緩衝區（aof_rewrite_buf）保存這部分數據，防止新AOF檔案產生期間遺失這部分資料。也就是說，bgrewriteaof執行期間，Redis的寫指令同時追加到aof_buf和aof_rewrite_buf兩個緩衝區。
- 子程序根據記憶體快照，依照指令合併規則寫入到新的AOF檔。
子進程寫完新的AOF檔案後，向父進程發出訊號，父進程更新統計訊息，具體可以透過info persistence查看。
- 父程式把AOF重寫緩衝區的資料寫入到新的AOF文件，這樣就保證了新AOF文件所保存的資料庫狀態和伺服器目前狀態一致。
- 使用新的AOF檔取代舊文件，文成AOF重寫。
關於文件重寫的流程，有兩點需要特別注意：
重寫由父進程fork子程序進行
重寫期間Redis執行的寫入指令，需要追加到新的AOF檔中，為此Redis引進例如aof_rewrite_buf快取
#4.3 啟動時載入
當AOF開啟時，Redis啟動時會優先載入AOF檔來恢復資料；只有當AOF關閉時，才會載入RDB檔案復原數據。
當AOF開啟，但AOF檔案不存在時，即使RDB檔案存在也不會載入。 ############Redis載入AOF檔時，會對AOF檔進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。但如果是AOF檔結尾不完整（機器突然宕機等容易導致檔案尾部不完整），且aof_load_truncated參數開啟，則日誌中會輸出警告，Redis忽略掉AOF檔的尾部，啟動成功。 aof_load_truncated參數預設是開啟的。 ############5. RDB 和AOF 的優缺點##########RDB持久化#########優點：RDB檔案緊湊，體積小，網路傳輸快，適合全量複製；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。 ### 缺點：RDB檔案的知名缺點在於其資料快照的持久化方式決定了必然做不到即時持久化，而在資料越來越重要的今天，資料的大量遺失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB檔案需要滿足特定格式，相容性差（如舊版的Redis不相容新版本的RDB檔案）。 ### 對於RDB持久化，一方面是bgsave在進行fork操作時Redis主程序會阻塞，另一方面，子程序向硬碟寫入資料也會帶來IO壓力。 #########AOF持久化#########與RDB持久化相對應，AOF的優先於支援秒數持久化、相容性好，缺點是檔案大、復原速度慢，對性能影響大。 ######對於AOF持久化，向硬碟寫入資料的頻率大大提高（everysec策略下為秒級），IO壓力更大，甚至可能在成AOF追加阻塞問題。 ###
跟RDB的bgsave類似，AOF檔的重寫也會面臨fork阻塞和子程序IO負載的問題。 AOF向硬碟中寫入資料的頻率更高，相較之下，會對Redis主流程的效能產生更大的影響。
一般來說，建議關閉AOF的自動重寫功能，並在重寫操作設定計劃任務，放在凌晨業務量低的時候進行，以降低AOF對主進程性能的影響以及IO的讀寫壓力。
以上是redis中的高可用與持久化怎麼配置的詳細內容。更多資訊請關注PHP中文網其他相關文章！
