這篇文章我們來介紹Redis高可用相關的機制。Redis要想實現高可用，主要有以下方面來保證：
- 數據持久化
- 主從復制
- 自動故障恢復
- 集群化
這篇文章我們先介紹Redis的高可用保障的基礎：數據持久化。因為Redis的主從復制和自動故障恢復，都需要依賴Redis持久化相關的東西。同時，Redis的數據持久化也可以用來做數據備份，用來保障數據的安全性。
Redis是一個內存數據庫，它的數據都保存在內存中，如果實例宕機，那么數據則全部丟失。如何保證數據的完整性和安全性也是提高服務高可用的重要機制之一。
Redis提供了完善的持久化機制，可以把內存中的數據持久化到磁盤上，方便我們進行備份數據和快速恢復數據。
這篇文章我們就來分析Redis的數據持久化是如何實現的？我們經常聽的RDB和AOF有什么區別？以及它們不同的使用場景。
持久化方式
Redis提供的數據持久化方式主要有2種：
- RDB：產生一個數據快照文件
- AOF：實時追加命令的日志文件
它們分別對應了不同的使用場景，下面我們就來依次分析。
RDB
介紹
RDB全稱 Redis Database Backup file（Redis數據備份文件），也被叫做 Redis 數據快照。
我們可以通過執行save或bgsave命令讓 Redis 在本地生成RDB快照文件，這個RDB文件包含了整個實例接近完整的數據內容。
它的優點如下：
- RDB文件數據是被壓縮寫入的，因此RDB文件的體積要比整個實例內存要小
- 當實例宕機恢復時，加載RDB文件的速度很快，能夠在很短時間內迅速恢復文件中的數據
它的缺點也很明顯：
- 由于是某一時刻的數據快照，因此它的數據并不全
- 生成 RDB 文件的代價是比較大的，它會消耗大量的 CPU 和內存資源
因此RDB比較適用于以下場景：
- 主從全量同步數據
- 數據庫備份
- 對于丟失數據不敏感的業務場景，實例宕機后快速恢復數據
Redis主從全量同步數據就是使用RDB文件進行的，我們會在后面的文章詳細講到。
由此可以看出，RDB非常適合做數據備份，我們可以定時讓Redis生成RDB文件，然后備份這個快照文件即可。
定時生成RDB
Redis也提供了定時觸發生成RDB文件的配置項：
- # 最近15分鐘內 至少產生1次寫入
- save 900 1
- # 最近5分鐘內 至少產生10次寫入
- save 300 10
- # 最近1分鐘內 至少產生10000次寫入
- save 60 10000
如果達到以上任意條件，則Redis會自動生成新的RDB文件，降低RDB數據內容與實例數據的差異。
Copy On Write
在Redis上執行save和bgsave命令都可以生成RDB文件，但前者是在前臺執行的，也就是說在生成RDB文件時，會阻塞整個實例，在RDB未生成之前，任何請求都是無法處理的，對于內存很大的實例，生成RDB文件非常耗時，顯然這是我們不能接受的。
所以通常我們會選擇執行bgsave讓Redis在后臺生成RDB文件，這樣Redis依舊可以處理客戶端請求，不會阻塞整個實例。
但不是說后臺生成RDB就是沒有代價的，Redis為了實現后臺把內存數據的快照寫入文件，采用了操作系統提供的Copy On Write技術，也就是我們熟知的fork系統調用。
fork 系統調用會產生一個子進程，它與父進程共享相同的內存地址空間，這樣子進程在這一時刻就能擁有與父進程的相同的內存數據。
雖然子進程與父進程共享同一塊內存地址空間，但在fork子進程時，操作系統需要拷貝父進程的內存頁表給子進程，如果整個Redis實例內存占用很大，那么它的內存頁表也會很大，在拷貝時就會比較耗時，同時這個過程會消耗大量的CPU資源。在完成拷貝之前父進程也處于阻塞狀態，無法處理客戶端請求。
fork執行完之后，子進程就可以掃描自身所有的內存數據，然后把全部數據寫入到RDB文件中。
之后父進程依舊處理客戶端的請求，當在處理寫命令時，父進程會重新分配新的內存地址空間，從操作系統申請新的內存使用，不再與子進程共享，這個過程就是Copy On Write（寫實復制）名字的由來。這樣父子進程的內存就會逐漸分離，父進程申請新的內存空間并更改內存數據，子進程的內存數據不受影響。
由此可以看出，在生成RDB文件時，不僅消耗CPU資源，還有需要占用最多一倍的內存空間。
我們在 Redis 執行info命令，可以看到fork子進程的耗時，可以通過這個耗時來評估fork時間是否符合預期。同時我們應該保證Redis機器擁有足夠的CPU和內存資源，并合理設置生成RDB的時機。
AOF
介紹
AOF全稱為Append Only File（追加日志文件）。它與RDB不同的是，AOF中記錄的是每一個命令的詳細信息，包括完整的命令類型、參數等。只要產生寫命令，就會實時寫入到AOF文件中。
我們可以通過配置文件開啟AOF：
- # 開啟AOF
- appendonly yes
- # AOF文件名
- appendfilename "appendonly.aof"
- # 文件刷盤方式
- appendfsync everysec
刷盤方式
開啟AOF后，Redis會把每個寫操作的命令記錄到文件并持久化到磁盤中，為了保證數據文件的安全性，Redis還提供了文件刷盤的時機：
- appendfsync always：每次寫入都刷盤，對性能影響最大，占用磁盤IO比較高，數據安全性最高
- appendfsync everysec：1秒刷一次盤，對性能影響相對較小，節點宕機時最多丟失1秒的數據
- appendfsync no：按照操作系統的機制刷盤，對性能影響最小，數據安全性低，節點宕機丟失數據取決于操作系統刷盤機制
以上可以看出AOF相對于RDB的優點是，AOF數據文件更新比較及時，比RDB保存更完整的數據，這樣在數據恢復時能夠恢復盡量完整的數據，降低丟失數據的風險。
如果同時存在RDB文件和AOF文件，Redis會優先使用AOF文件進行數據恢復。
但它的缺點也很易見：
- 隨著時間增長，AOF文件會越來越大
- AOF文件刷盤會增加磁盤IO的負擔，可能影響Redis的性能（開啟每秒刷盤時）
AOF重寫
針對第一種情況，Redis提供了AOF瘦身的功能，可以設置在AOF文件很大時，自動觸發AOF重寫，Redis會掃描整個實例的數據，重新生成一個AOF文件達成瘦身的效果。但這個重寫過程也需要消耗大量的CPU資源。
- # AOF文件距離上次文件增長超過多少百分比則觸發重寫
- auto-aof-rewrite-percentage 100
- # AOF文件體積最小多大以上才觸發重寫
- auto-aof-rewrite-min-size 64mb
由于AOF可以最大可能降低丟失數據的風險，所以它一般適用于對丟失數據很敏感的業務場景，例如涉及金錢交易的業務。
性能影響
如果AOF的刷盤時機設置為每次寫入都刷盤，那么會大大降低Redis的寫入性能，因為每次寫命令都需要寫入文件并刷到磁盤中才會返回，當寫入量很大時，會增加磁盤IO的負擔。性能與數據安全不能兼得，雖然Redis提供了實時刷盤的機制，但是在真正場景中使用的不多。
通常我們會選擇每秒刷盤這種方式，既能保證良好的寫入性能，在實例宕機時最多丟失1秒的數據，做到性能和安全的平衡。
總結
我們對RDB和AOF的總結如下表。圖片我們需要針對不同的業務場景選擇合適的持久化方式，也可以根據RDB和AOF的優點配合使用，保證Redis數據的安全性，又可以兼顧它的性能。
原文鏈接：https://mp.weixin.qq.com/s/M11icEUWbUEZcOo7Ug3c_A
