一、Redis的五種數據類型

1.String（字符串）2.Hash（哈希）3.List（列表）4.Set（集合）5.SortedSet（有序集合）

具體用法網上比較多不詳細介紹

五種數據類型的使用場景：

1.String（字符串）

可以存儲序列化的對象
計數器：許多運用都會使用redis作爲計數的基礎工具，他可以實現快速計數、查詢緩存的功能，同時數據可以一步落地到其他的數據源。如：視頻播放數系統就是使用redis作爲視頻播放數計數的基礎組件。
共享session：出於負載均衡的考慮，分佈式服務會將用戶信息的訪問均衡到不同服務器上，用戶刷新一次訪問可能會需要重新登錄，爲避免這個問題可以用redis將用戶session集中管理，在這種模式下只要保證redis的高可用和擴展性的，每次獲取用戶更新或查詢登錄信息都直接從redis中集中獲取。
限速：處於安全考慮，每次進行登錄時讓用戶輸入手機驗證碼，爲了短信接口不被頻繁訪問，會限制用戶每分鐘獲取驗證碼的頻率

2.Hash（哈希）

存儲對象信息：如用戶信息等；此時的key（user:001）對應一個map{name:'peter',age:18,phone:18500000000}

3.List（列表）

常用命令：

lpush,rpush,lpop,rpop,lrange,BLPOP(阻塞版)等。

應用場景：

1.最新消息排行。

2.消息隊列。利用Lists的push的操作，將任務存儲在list中，然後工作線程再用pop操作將任務取出進行執行。

示例：

一個客戶端不停的往隊列裏塞值

另一個客戶端不停的取值：

brpop移出並獲取列表的最下面的元素，如果列表沒有元素會阻塞列表直到等待超時或發現可彈出元素爲止

4.Set（集合）

集合類型也是用來保存多個字符串的元素，但和列表不同的是集合中不允許有重複的元素，並且集合中的元素是
無序的，不能通過索引下標獲取元素，redis除了支持集合內的增刪改查，同時還支持多個集合取交集、並集、
差集，併合理的使用好集合類型，能在實際開發中解決很多實際問題。

比如在微博應用中，每個人的好友存在一個集合（set）中，這樣求兩個人的共同好友的操作，可能就只需要用求交集命令即可。

5.SortedSet（有序集合）

使用場景：

sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先級(score)的參數來爲成員排序，並且是插入有序的，即自動排序。

比如:twitter 的public timeline可以以發表時間作爲score來存儲，這樣獲取時就是自動按時間排好序的。

比如:全班同學成績的SortedSets，value可以是同學的學號，而score就可以是其考試得分，這樣數據插入集合的，就已經進行了天然的排序。

另外還可以用Sorted Sets來做帶權重的隊列，比如普通消息的score爲1，重要消息的score爲2，然後工作線程可以選擇按score的倒序來獲取工作任務。讓重要的任務優先執行。

需要精準設定過期時間的應用

比如你可以把上面說到的sorted set的score值設置成過期時間的時間戳，那麼就可以簡單地通過過期時間排序，定時清除過期數據了，不僅是清除Redis中的過期數據，你完全可以把Redis裏這個過期時間當成是對數據庫中數據的索引，用Redis來找出哪些數據需要過期刪除，然後再精準地從數據庫中刪除相應的記錄。

實現方式：

Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap裏放的是成員到score的映射，而跳躍表裏存放的是所有的成員，排序依據是HashMap裏存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

二、redis的應用場景

1、緩存

2、消息隊列

3、數據存儲

三、redis事務

3.1redis執行事務

Redis 事務可以一次執行多個命令，並且帶有以下三個重要的保證：

批量操作在發送 EXEC 命令前被放入隊列緩存。
收到 EXEC 命令後進入事務執行，事務中任意命令執行失敗，其餘的命令依然被執行。
在事務執行過程，其他客戶端提交的命令請求不會插入到事務執行命令序列中。

一個事務從開始到執行會經歷以下三個階段：

開始事務。
命令入隊。
執行事務

java示例：

@Test
public void test2Trans() { 
  Jedis jedis = new Jedis("localhost"); 
  long start = System.currentTimeMillis(); 
  Transaction tx = jedis.multi(); 
  for (int i = 0; i < 100000; i++) { 
    tx.set("t" + i, "t" + i); 
  } 
  List<Object> results = tx.exec(); 
  long end = System.currentTimeMillis(); 
  System.out.println("Transaction SET: " + ((end - start)/1000.0) + " seconds"); 
  jedis.disconnect(); 
}

3.2redis事務失敗處理機制

3.2.1語法錯誤

如下在執行過程中語法錯誤，所有命令都不執行

3.2.2執行過程中發生錯誤

單個 Redis 命令的執行是原子性的，但 Redis 沒有在事務上增加任何維持原子性的機制，所以 Redis 事務的執行並不是原子性的。事務可以理解爲一個打包的批量執行腳本，但批量指令並非原子化的操作，中間某條指令的失敗不會導致前面已做指令的回滾，也不會造成後續的指令不做。

Redis中的事務並沒有關係型數據庫中的事務回滾(rollback)功能，因此使用者必須自己收拾剩下的爛攤子。不過由於Redis不支持事務回滾功能，這也使得Redis的事務簡潔快速。

回顧上面兩種類型的錯誤，語法錯誤完全可以在開發的時候發現並作出處理，另外如果能很好地規劃Redis數據的鍵的使用，也是不會出現命令和鍵不匹配的問題的

四、redis持久化

4.1持久化方式

4.1.1rdb方式

4.1.1.1手動觸發

save命令

bgsave後臺運行

4.1.1.2自動觸發

save m n

自動觸發最常見的情況是在配置文件中通過save m n，指定當m秒內發生n次變化時，會觸發bgsave。

其中save 900 1的含義是：當時間到900秒時，如果Redis數據發生了至少1次變化，則執行bgsave；save 300 10和save 60 10000同理。當三個save條件滿足任意一個時，都會引起bgsave的調用。

save m n的實現原理

Redis的save m n，是通過serverCron函數、dirty計數器、和lastsave時間戳來實現的。

serverCron是Redis服務器的週期性操作函數，默認每隔100ms執行一次；該函數對服務器的狀態進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執行bgsave。

dirty計數器是Redis服務器維持的一個狀態，記錄了上一次執行bgsave/save命令後，服務器狀態進行了多少次修改(包括增刪改)；而當save/bgsave執行完成後，會將dirty重新置爲0。

例如，如果Redis執行了set mykey helloworld，則dirty值會+1；如果執行了sadd myset v1 v2 v3，則dirty值會+3；注意dirty記錄的是服務器進行了多少次修改，而不是客戶端執行了多少修改數據的命令。

lastsave時間戳也是Redis服務器維持的一個狀態，記錄的是上一次成功執行save/bgsave的時間。

save m n的原理如下：每隔100ms，執行serverCron函數；在serverCron函數中，遍歷save m n配置的保存條件，只要有一個條件滿足，就進行bgsave。對於每一個save m n條件，只有下面兩條同時滿足時纔算滿足：

當前時間-lastsave > m
dirty >= n

save m n 執行日誌

下圖是save m n觸發bgsave執行時，服務器打印日誌的情況：

其他自動觸發機制

除了save m n以外，還有一些其他情況會觸發bgsave：

在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb文件發送給從節點；
執行shutdown命令時，自動執行rdb持久化，如下圖所示：

執行流程

前面介紹了觸發bgsave的條件，下面將說明bgsave命令的執行流程，如下圖所示：

圖片來源：https://blog.csdn.net/a1007720052/article/details/79126253

圖片中的5個步驟所進行的操作如下：

Redis父進程首先判斷：當前是否在執行save，或bgsave/bgrewriteaof（後面會詳細介紹該命令）的子進程，如果在執行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進程不能同時執行，主要是基於性能方面的考慮：兩個併發的子進程同時執行大量的磁盤寫操作，可能引起嚴重的性能問題。
父進程執行fork操作創建子進程，這個過程中父進程是阻塞的，Redis不能執行來自客戶端的任何命令；
父進程fork後，bgsave命令返回”Background saving started”信息並不再阻塞父進程，並可以響應其他命令；
子進程創建RDB文件，根據父進程內存快照生成臨時快照文件，完成後對原有文件進行原子替換；
子進程發送信號給父進程表示完成，父進程更新統計信息。

存儲路徑

RDB文件的存儲路徑既可以在啓動前配置，也可以通過命令動態設定。

配置：dir配置指定目錄，dbfilename指定文件名。默認是Redis根目錄下的dump.rdb文件。

動態設定：Redis啓動後也可以動態修改RDB存儲路徑，在磁盤損害或空間不足時非常有用；執行命令爲config set dir {newdir}和config set dbfilename {newFileName}。如下所示(Windows環境)：

加載

RDB文件的載入工作是在服務器啓動時自動執行的，並沒有專門的命令。但是由於AOF的優先級更高，因此當AOF開啓時，Redis會優先載入AOF文件來恢復數據；只有當AOF關閉時，纔會在Redis服務器啓動時檢測RDB文件，並自動載入。服務器載入RDB文件期間處於阻塞狀態，直到載入完成爲止。

Redis啓動日誌中可以看到自動載入的執行：

Redis載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日誌中會打印錯誤，Redis啓動失敗。

下面是RDB常用的配置項，以及默認值：

save m n：bgsave自動觸發的條件；如果沒有save m n配置，相當於自動的RDB持久化關閉，不過此時仍可以通過其他方式觸發。

stop-writes-on-bgsave-error yes：當bgsave出現錯誤時，Redis是否停止執行寫命令；設置爲yes，則當硬盤出現問題時，可以及時發現，避免數據的大量丟失；設置爲no，則Redis無視bgsave的錯誤繼續執行寫命令，當對Redis服務器的系統(尤其是硬盤)使用了監控時，該選項考慮設置爲no。

rdbcompression yes：是否開啓RDB文件壓縮。

rdbchecksum yes：是否開啓RDB文件的校驗，在寫入文件和讀取文件時都起作用；關閉checksum在寫入文件和啓動文件時大約能帶來10%的性能提升，但是數據損壞時無法發現。

dbfilename dump.rdb：RDB文件名。

dir ./：RDB文件和AOF文件所在目錄。

4.1.2aof方式

RDB持久化是將進程數據寫入文件，而AOF持久化(即Append Only File持久化)，則是將Redis執行的每次寫命令記錄到單獨的日誌文件中（有點像MySQL的binlog）；當Redis重啓時再次執行AOF文件中的命令來恢復數據。與RDB相比，AOF的實時性更好，因此已成爲主流的持久化方案。

redis.conf 開啓aof持久化方式

由於需要記錄Redis的每條寫命令，因此AOF不需要觸發，下面介紹AOF的執行流程。

AOF的執行流程包括：

命令追加(append)：將Redis的寫命令追加到緩衝區aof_buf；
文件寫入(write)和文件同步(sync)：根據不同的同步策略將aof_buf中的內容同步到硬盤；
文件重寫(rewrite)：定期重寫AOF文件，達到壓縮的目的。

1) 命令追加(append)

Redis先將寫命令追加到緩衝區，而不是直接寫入文件，主要是爲了避免每次有寫命令都直接寫入硬盤，導致硬盤IO成爲Redis負載的瓶頸。

命令追加的格式是Redis命令請求的協議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點；具體格式略。在AOF文件中，除了用於指定數據庫的select命令（如select 0 爲選中0號數據庫）是由Redis添加的，其他都是客戶端發送來的寫命令。

2) 文件寫入(write)和文件同步(sync)

Redis提供了多種AOF緩存區的同步文件策略，策略涉及到操作系統的write函數和fsync函數，說明如下：

爲了提高文件寫入效率，在現代操作系統中，當用戶調用write函數將數據寫入文件時，操作系統通常會將數據暫存到一個內存緩衝區裏，當緩衝區被填滿或超過了指定時限後，才真正將緩衝區的數據寫入到硬盤裏。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，內存緩衝區中的數據會丟失；因此係統同時提供了fsync、fdatasync等同步函數，可以強制操作系統立刻將緩衝區中的數據寫入到硬盤裏，從而確保數據的安全性。

AOF緩存區的同步文件策略由參數appendfsync控制，各個值的含義如下：

always：命令寫入aof_buf後立即調用系統fsync操作同步到AOF文件，fsync完成後線程返回。這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成爲性能瓶頸，Redis只能支持大約幾百TPS寫入，嚴重降低了Redis的性能；即便是使用固態硬盤（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。

no：命令寫入aof_buf後調用系統write操作，不對AOF文件做fsync同步；同步由操作系統負責，通常同步週期爲30秒。這種情況下，文件同步的時間不可控，且緩衝區中堆積的數據會很多，數據安全性無法保證。

everysec：命令寫入aof_buf後調用系統write操作，write完成後線程返回；fsync同步文件操作由專門的線程每秒調用一次。everysec是前述兩種策略的折中，是性能和數據安全性的平衡，因此是Redis的默認配置，也是我們推薦的配置。

3) 文件重寫(rewrite)

隨着時間流逝，Redis服務器執行的寫命令越來越多，AOF文件也會越來越大；過大的AOF文件不僅會影響服務器的正常運行，也會導致數據恢復需要的時間過長。

文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫是把Redis進程內的數據轉化爲寫命令，同步到新的AOF文件，不會對舊的AOF文件進行任何讀取、寫入操作。

關於文件重寫需要注意的另一點是：對於AOF持久化來說，文件重寫雖然是強烈推薦的，但並不是必須的。即使沒有文件重寫，數據也可以被持久化並在Redis啓動的時候導入。因此在一些實現中，會關閉自動的文件重寫，然後通過定時任務在每天的某一時刻定時執行。

文件重寫之所以能夠壓縮AOF文件，原因在於：

過期的數據不再寫入文件

無效的命令不再寫入文件：如有些數據被重複設值(set mykey v1, set mykey v2)、有些數據被刪除了(sadd myset v1, del myset)等等

多條命令可以合併爲一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合併爲sadd myset v1 v2 v3。不過爲了防止單條命令過大造成客戶端緩衝區溢出，對於list、set、hash、zset類型的key，並不一定只使用一條命令；而是以某個常量爲界將命令拆分爲多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。

通過上述內容可以看出，由於重寫後AOF執行的命令減少了，文件重寫既可以減少文件佔用的空間，也可以加快恢復速度。

文件重寫的觸發

文件重寫的觸發，分爲手動觸發和自動觸發：

手動觸發：直接調用bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子進程進行具體的工作，且都只有在fork時阻塞。

此時服務器執行日誌如下：

自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數，以及aof_current_size和aof_base_size狀態確定觸發時機。
auto-aof-rewrite-min-size：執行AOF重寫時，文件的最小體積，默認值爲64MB。
auto-aof-rewrite-percentage：執行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

其中，參數可以通過config get命令查看：

狀態可以通過info persistence查看：

只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數同時滿足時，纔會自動觸發AOF重寫，即bgrewriteaof操作。

自動觸發bgrewriteaof時，可以看到服務器日誌如下：

文件重寫的流程

文件重寫流程如下圖所示：

圖片來源：http://www.cnblogs.com/yangmingxianshen/p/8373205.html

關於文件重寫的流程，有兩點需要特別注意：

重寫由父進程fork子進程進行；
重寫期間Redis執行的寫命令，需要追加到新的AOF文件中，爲此Redis引入了aof_rewrite_buf緩存。

對照上圖，文件重寫的流程如下：

Redis父進程首先判斷當前是否存在正在執行 bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執行完成後再執行。前面曾介紹過，這個主要是基於性能方面的考慮。
父進程執行fork操作創建子進程，這個過程中父進程是阻塞的。
父進程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_rewirte_buf兩個緩衝區。
子進程根據內存快照，按照命令合併規則寫入到新的AOF文件。
子進程寫完新的AOF文件後，向父進程發信號，父進程更新統計信息，具體可以通過info persistence查看。父進程把AOF重寫緩衝區的數據寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數據庫狀態和服務器當前狀態一致。使用新的AOF文件替換老文件，完成AOF重寫。

加載

前面提到過，當AOF開啓時，Redis啓動時會優先載入AOF文件來恢復數據；只有當AOF關閉時，纔會載入RDB文件恢復數據。

當AOF開啓，且AOF文件存在時，Redis啓動日誌：

當AOF開啓，但AOF文件不存在時，即使RDB文件存在也不會加載(更早的一些版本可能會加載，但3.0不會)，Redis啓動日誌如下：

文件校驗

與載入RDB文件類似，Redis載入AOF文件時，會對AOF文件進行校驗，如果文件損壞，則日誌中會打印錯誤，Redis啓動失敗。但如果是AOF文件結尾不完整(機器突然宕機等容易導致文件尾部不完整)，且aof-load-truncated參數開啓，則日誌中會輸出警告，Redis忽略掉AOF文件的尾部，啓動成功。aof-load-truncated參數默認是開啓的：

僞客戶端

因爲Redis的命令只能在客戶端上下文中執行，而載入AOF文件時命令是直接從文件中讀取的，並不是由客戶端發送；因此Redis服務器在載入AOF文件之前，會創建一個沒有網絡連接的客戶端，之後用它來執行AOF文件中的命令，命令執行的效果與帶網絡連接的客戶端完全一樣。

aof常用配置

下面是AOF常用的配置項，以及默認值；前面介紹過的這裏不再詳細介紹。

appendonly no：是否開啓AOF
appendfilename "appendonly.aof"：AOF文件名
dir ./：RDB文件和AOF文件所在目錄
appendfsync everysec：fsync持久化策略
no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啓該選項，可以減輕文件重寫時CPU和硬盤的負載（尤其是硬盤），但是可能會丟失AOF重寫期間的數據；需要在負載和安全性之間進行平衡
auto-aof-rewrite-percentage 100：文件重寫觸發條件之一
auto-aof-rewrite-min-size 64mb：文件重寫觸發提交之一
aof-load-truncated yes：如果AOF文件結尾損壞，Redis啓動時是否仍載入AOF文件

4.1.3RDB-AOF 混合持久化

RDB-AOF 混合持久化：這種持久化能夠通過 AOF 重寫操作創建出一個同時包含 RDB 數據和 AOF 數據的 AOF 文件，其中 RDB 數據位於 AOF 文件的開頭，它們儲存了服務器開始執行重寫操作時的數據庫狀態：至於那些在重寫操作執行之後執行的 Redis 命令，則會繼續以 AOF 格式追加到 AOF 文件的末尾，也即是 RDB 數據之後

AOF在進行文件重寫(aof文件裏可能有太多沒用指令，所以aof會定期根據內存的最新數據生成aof文件)

時將重寫這一刻之前的內存rdb快照文件的內容和增量的AOF修改內存數據的命令日誌文件存在一起，

都寫入新的aof文件，新的文件一開始不叫appendonly.aof，等到重寫完新的AOF文件纔會進行改名，

原子的覆蓋原有的AOF文件，完成新舊兩個AOF文件的替換。

混合持久化文件結構：

2、混合持久化配置
開啓混合持久化：

aof-use-rdb-preamble yes

重啓Redis服務。

3、bgrewriteaof重寫AOF
AOF根據配置規則在後臺自動重寫aof文件，也可以人爲執行命令bgrewriteaof重寫AOF。於是在Redis重啓的時候，

可以先加載rdb的內容，然後再執行aof指令部分達到Redis數據重放的目的，重啓效率因此大幅得到提升。

4、實例驗證
通過bgrewriteaof手動重寫aof。

查看appendonly.aof文件內容，看到rdb格式的二進制文件。

再執行一條set命令。

然後再看appendonly.aof文件內容。

從文件格式可以看到，混合持久化appendonly.aof文件由rdb格式和aof指令格式兩大部分組成。

Redis在重啓時，先重寫rdb到內存，然後在重寫aof到內存，重啓效率高，還能減少數據的丟失。

4.2如何選擇持久化方式

RDB和AOF各有優缺點：

RDB持久化

優點：RDB文件緊湊，體積小，網絡傳輸快，適合全量複製；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對性能的影響相對較小。

缺點：RDB文件的致命缺點在於其數據快照的持久化方式決定了必然做不到實時持久化，而在數據越來越重要的今天，數據的大量丟失很多時候是無法接受的，因此AOF持久化成爲主流。此外，RDB文件需要滿足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

與RDB持久化相對應，AOF的優點在於支持秒級持久化、兼容性好，

缺點是文件大、恢復速度慢、對性能影響大。

策略選擇

在介紹持久化策略之前，首先要明白無論是RDB還是AOF，持久化的開啓都是要付出性能方面代價的：對於RDB持久化，一方面是bgsave在進行fork操作時Redis主進程會阻塞，另一方面，子進程向硬盤寫數據也會帶來IO壓力；對於AOF持久化，向硬盤寫數據的頻率大大提高(everysec策略下爲秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題（後面會詳細介紹這種阻塞），此外，AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進程的IO壓力問題。相對來說，由於AOF向硬盤中寫數據的頻率更高，因此對Redis主進程性能的影響會更大。

在實際生產環境中，根據數據量、應用對數據的安全要求、預算限制等不同情況，會有各種各樣的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一種，或同時開啓RDB和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一起考慮，因爲主從複製與持久化同樣具有數據備份的功能，而且主機master和從機slave可以獨立的選擇持久化方案。

下面分場景來討論持久化策略的選擇，下面的討論也只是作爲參考，實際方案可能更復雜更具多樣性。

1）如果Redis中的數據完全丟棄也沒有關係（如Redis完全用作DB層數據的cache），那麼無論是單機，還是主從架構，都可以不進行任何持久化。

2）在單機環境下（對於個人開發者，這種情況可能比較常見），如果可以接受十幾分鍾或更多的數據丟失，選擇RDB對Redis的性能更加有利；如果只能接受秒級別的數據丟失，應該選擇AOF。

3）但在多數情況下，我們都會配置主從環境，slave的存在既可以實現數據的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。

在這種情況下，一種可行的做法是：

master：完全關閉持久化（包括RDB和AOF），這樣可以讓master的性能達到最好；slave：關閉RDB，開啓AOF（如果對數據安全要求不高，開啓RDB關閉AOF也可以），並定時對持久化文件進行備份（如備份到其他文件夾，並標記好備份的時間）；然後關閉AOF的自動重寫，然後添加定時任務，在每天Redis閒時（如凌晨12點）調用bgrewriteaof。

這裏需要解釋一下，爲什麼開啓了主從複製，可以實現數據的熱備份，還需要設置持久化呢？因爲在一些特殊情況下，主從複製仍然不足以保證數據的安全，例如：

master和slave進程同時停止：考慮這樣一種場景，如果master和slave在同一棟大樓或同一個機房，則一次停電事故就可能導致master和slave機器同時關機，Redis進程停止；如果沒有持久化，則面臨的是數據的完全丟失。master誤重啓：考慮這樣一種場景，master服務因爲故障宕掉了，如果系統中有自動拉起機制（即檢測到服務停止後重啓該服務）將master自動重啓，由於沒有持久化文件，那麼master重啓後數據是空的，slave同步數據也變成了空的；如果master和slave都沒有持久化，同樣會面臨數據的完全丟失。需要注意的是，即便是使用了哨兵（關於哨兵後面會有文章介紹）進行自動的主從切換，也有可能在哨兵輪詢到master之前，便被自動拉起機制重啓了。因此，應儘量避免“自動拉起機制”和“不做持久化”同時出現。

4）異地災備：上述討論的幾種持久化策略，針對的都是一般的系統故障，如進程異常退出、宕機、斷電等，這些故障不會損壞硬盤。但是對於一些可能導致硬盤損壞的災難情況，如火災地震，就需要進行異地災備。

例如對於單機的情形，可以定時將RDB文件或重寫後的AOF文件，通過scp拷貝到遠程機器，如阿里雲、AWS等；對於主從的情形，可以定時在master上執行bgsave，然後將RDB文件拷貝到遠程機器，或者在slave上執行bgrewriteaof重寫AOF文件後，將AOF文件拷貝到遠程機器上。

一般來說，由於RDB文件文件小、恢復快，因此災難恢復常用RDB文件；異地備份的頻率根據數據安全性的需要及其它條件來確定，但最好不要低於一天一次。

fork阻塞：CPU的阻塞

在Redis的實踐中，衆多因素限制了Redis單機的內存不能過大，例如：

當面對請求的暴增，需要從庫擴容時，Redis內存過大會導致擴容時間太長；
當主機宕機時，切換主機後需要掛載從庫，Redis內存過大導致掛載速度過慢；
以及持久化過程中的fork操作，下面詳細說明。

首先說明一下fork操作：

父進程通過fork操作可以創建子進程；子進程創建後，父子進程共享代碼段，不共享進程的數據空間，但是子進程會獲得父進程的數據空間的副本。在操作系統fork的實際實現中，基本都採用了寫時複製技術，即在父/子進程試圖修改數據空間之前，父子進程實際上共享數據空間；但是當父/子進程的任何一個試圖修改數據空間時，操作系統會爲修改的那一部分(內存的一頁)製作一個副本。

雖然fork時，子進程不會複製父進程的數據空間，但是會複製內存頁表（頁表相當於內存的索引、目錄）；父進程的數據空間越大，內存頁表越大，fork時複製耗時也會越多。

在Redis中，無論是RDB持久化的bgsave，還是AOF重寫的bgrewriteaof，都需要fork出子進程來進行操作。如果Redis內存過大，會導致fork操作時複製內存頁表耗時過多；而Redis主進程在進行fork時，是完全阻塞的，也就意味着無法響應客戶端的請求，會造成請求延遲過大。

對於不同的硬件、不同的操作系統，fork操作的耗時會有所差別，一般來說，如果Redis單機內存達到了10GB，fork時耗時可能會達到百毫秒級別（如果使用Xen虛擬機，這個耗時可能達到秒級別）。因此，一般來說Redis單機內存一般要限制在10GB以內；不過這個數據並不是絕對的，可以通過觀察線上環境fork的耗時來進行調整。觀察的方法如下：執行命令info stats，查看latest_fork_usec的值，單位爲微秒。

爲了減輕fork操作帶來的阻塞問題，除了控制Redis單機內存的大小以外，還可以適度放寬AOF重寫的觸發條件、選用物理機或高效支持fork操作的虛擬化技術等，例如使用Vmware或KVM虛擬機，不要使用Xen虛擬機。

硬盤的阻塞

前面提到過，在AOF中，如果AOF緩衝區的文件同步策略爲everysec，則：在主線程中，命令寫入aof_buf後調用系統write操作，write完成後主線程返回；fsync同步文件操作由專門的文件同步線程每秒調用一次。

這種做法的問題在於，如果硬盤負載過高，那麼fsync操作可能會超過1s；如果Redis主線程持續高速向aof_buf寫入命令，硬盤的負載可能會越來越大，IO資源消耗更快；如果此時Redis進程異常退出，丟失的數據也會越來越多，可能遠超過1s。

爲此，Redis的處理策略是這樣的：主線程每次進行AOF會對比上次fsync成功的時間；如果距上次不到2s，主線程直接返回；如果超過2s，則主線程阻塞直到fsync同步完成。因此，如果系統硬盤負載過大導致fsync速度太慢，會導致Redis主線程的阻塞；此外，使用everysec配置，AOF最多可能丟失2s的數據，而不是1s。

AOF追加阻塞問題定位的方法：

1）監控info Persistence中的aof_delayed_fsync：當AOF追加阻塞發生時（即主線程等待fsync而阻塞），該指標累加。

2）AOF阻塞時的Redis日誌：

Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

3）如果AOF追加阻塞頻繁發生，說明系統的硬盤負載太大；可以考慮更換IO速度更快的硬盤，或者通過IO監控分析工具對系統的IO負載進行分析，如iostat（系統級io）、iotop（io版的top）、pidstat等。

info命令與持久化

前面提到了一些通過info命令查看持久化相關狀態的方法，下面來總結一下。

1）info Persistence

執行結果如下：

其中比較重要的包括：

rdb_last_bgsave_status:上次bgsave 執行結果，可以用於發現bgsave錯誤
rdb_last_bgsave_time_sec:上次bgsave執行時間（單位是s），可以用於發現bgsave是否耗時過長aof_enabled:AOF是否開啓aof_last_rewrite_time_sec: 上次文件重寫執行時間（單位是s），可以用於發現文件重寫是否耗時過長aof_last_bgrewrite_status: 上次bgrewrite執行結果，可以用於發現bgrewrite錯誤
aof_buffer_length和aof_rewrite_buffer_length:aof緩存區大小和aof重寫緩衝區大小
aof_delayed_fsync:AOF追加阻塞情況的統計

2）info stats

其中與持久化關係較大的是：latest_fork_usec，代表上次fork耗時，可以參見前面的討論。

參考文獻：

https://blog.csdn.net/yhl_jxy/article/details/91879874

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650769300&idx=1&sn=49a11efa1a6ee605fceaddf240a55c40&chksm=f3f93201c48ebb175fa76053d95e315b621485b0e65e42d8b41fe91b8f859c9278f3adec7ca9&mpshare=1&scene=23&srcid=0731SR4C94CRM0Mljym0oEI3%23rd

Redis常見知識彙總（一）

一、Redis的五種數據類型

二、redis的應用場景

三、redis事務

3.1redis執行事務

3.2redis事務失敗處理機制

3.2.1語法錯誤

3.2.2執行過程中發生錯誤

四、redis持久化

4.1持久化方式

4.1.1rdb方式

4.1.2aof方式

4.1.3RDB-AOF 混合持久化

4.2如何選擇持久化方式

centos安裝jdk、node

elastisearch 安裝

SpringCloud學習筆記（一）--Eureka

Redis常見知識彙總（一）

MongoDB學習（一）--搭建

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結