Redis中的多路復用模型
Redis6用到了多線程？那多線程應用在哪些地方，引入多線程后，又改如何保證線程安全性呢？
同時，如何在性能和線程安全性方面做好平衡？
關於Redis的單線程模型
在Redis6.0之前，我們一直說Redis是單線程，所以並不會存在線程安全問題，而這個單線程，實際上就是在做數據IO處理中，是用的主線程來串行執行，如圖4-7所示。
Redis基於Reactor模式設計開發了自己的一套高效事件處理模型，這個事件處理模型對應的就是Redis中的文件事件處理器，這個文件事件處理器是單線程運行的，這也是為什么我們一直強調Redis是線程安全的。
既然Redis是基於Reactor模型實現，那它必然用了I/O多路復用機制來監聽多個客戶端連接，然后把感興趣的事件（READ/ACCEPT/CLOSE/WRITE）注冊到多路復用器中。
文件事件處理器中使用I/O多路復用模型同時監聽多個客戶端連接，並且根據當前連接執行的任務類型關聯不同的事件處理器（連接應答處理器、命令請求處理器、命令回復處理器）來處理這些事件。
這樣設計的好處：
- 文件事件處理器實現了高性能的網絡IO通信模型
- 通過單線程的方式執行指令，避免同步機制的性能開銷、避免過多的上下文切換、整體實現比較簡單，不需要考慮多線程場景中的各種數據結構的線程安全問題。
其實嚴格意義上來說，在Redis4.x版本就支持了多線程，只是，負責客戶端請求的IO處理使用的是單線程。但是針對那些非常耗時的命令，Redis4.x提供了異步化的指令來處理，避免因為IO時間過長影響到客戶端請求IO處理的線程。比如在 Redis v4.0 之后增加了一些的非阻塞命令如 UNLINK（del命令的異步版本）、FLUSHALL ASYNC、FLUSHDB ASYNC。
Redis6.0之后的多線程？
在Redis6.0中引入了多線程，可能很多同學會誤以為redis原本的單線程數據IO變成了多線程IO，那作者不就是在打自己的臉嗎？
對於Redis來說，CPU通常不是瓶頸，因為大多數請求不是屬於CPU密集型，而是I/O密集型。而在Redis中除了數據的持久化方案之外，它是完全的純內存操作，因此執行速度是非常快的，所以數據的IO並不是Redis的性能瓶頸，Redis真正的性能瓶頸是在網絡I/O，也就是客戶端和服務端之間的網絡傳輸延遲，所以Redis選擇了單線程的IO多路復用來實現它的核心網絡模型。
前面我們說過，單線程設計對於Redis來說有很多好處。
- 避免過多的上上下文切換開銷
- 避免同步機制的開銷，涉及到數據同步和事務操作時，避免多線程影響所以必然需要加同步機制保證線程安全性。但是加鎖同時也會影響到程序的執行性能。
- 維護簡單，引入多線程之后，不管是對數據結構的設計，還是在程序代碼的維護上，都會變得很復雜。
所以既然Redis的數據I/O不是瓶頸，同時單線程又有這么多好處，那Redis自然就采用單線程了。既然是這樣，那么Redis 6.0引入多線程，一定不是優化數據IO性能，那么我們先來分析一下Redis性能瓶頸主要體現在哪些方面，無非就是三個方面。
- 網絡IO
- CPU核心數
- 內存
由於CPU核心數並不是redis的瓶頸，所以影響Redis性能的因素只有網絡IO和內存，而內存屬於硬件范疇，比如采用容量更大、吞吐量更高的內存進行優化就行，因此也不是屬於Redis可優化的空間，所以最終我們發現Redis的性能瓶頸還是在網絡IO上。
而在Redis6.0之前，使用的是單線程Reactor模型，單線程模型是指對於客戶端的請求，主線程需要負責對這個請求的完整IO過程進行處理，如圖4-8所示，從socket中讀取數據和往socket中寫數據都是比較耗時的網絡IO操作，解析請求和內存交互耗時可能遠小於這個網絡IO操作。
按照前面我們對多Reactor多線程的理解，那我們能不能改成主從多Reactor多線程模型呢？主Reactor負責接收客戶端連接，然后分發給多個Reactor進行網絡IO操作。很顯然，這樣做就會導致Redis編程了一個多線程模型，這對Redis的影響較大，因為多線程帶來的線程安全問題和底層復雜的數據結構的操作都非常棘手，所以Redis 6.0並沒有這么做。
Redis 6.0中將處理過程中最耗時的Socket讀取、請求解析、單獨用一個線程來處理，剩下的命令執行操作仍然由單線程來完成和內存的數據交互，這樣一來，網絡IO操作就變成了多線程了，但是核心部分仍然是線程安全的，如圖4-9所示。
為什么說Redis6.0是一個特殊的多線程，原因就在這里，Redis主要針對網絡IO這塊引入了多線程的方式來提升了網絡IO性能，但是真正執行命令的操作仍然是由主線程來完成。因此，總的來說，我們仍然可以說Redis是單線程模型。
Redis 6.0如何開啟多線程
Redis 6.0默認多線程是禁止的，也就是仍然只是使用主線程來完成網絡IO，如果需要開啟，則修改redis.conf配置文件中的如下屬性
# 默認是關閉，設置為yes打開
io-threads-do-reads no
#默認線程數量是4，官方建議是4核機器上設置為2~3個，8核機器上設置6個
io-threads 4
引入多線程之后的性能提升
圖4-20是美團技術團隊使用阿里雲服務器壓測GET/SET命令在4個線程IO時性能上的對比結果，可以明顯的看到，Redis 在使用多線程模式之后性能大幅提升，達到了一倍。
- Redis Server 阿里雲 Ubuntu 18.04 ， 8CPU 2.5GHZ，8G內存，主機型號： ecs.ic5.2xlarge
- Redis Benchmark client: 阿里雲 Unbuntu 18.04 , 8CPU 2.5GHZ，8G內存，主機型號：ecs.ic5.2xlarge
內存回收策略
很多同學了解了Redis的好處之后，於是把任何數據都往Redis中放，如果使用不合理很容易導致數據超過Redis的內存，這種情況會出現什么問題呢？
- Redis中有很多無效的緩存，這些緩存數據會降低數據IO的性能，因為不同的數據類型時間復雜度算法不同，數據越多可能會造成性能下降
- 隨着系統的運行，redis的數據越來越多，會導致物理內存不足。通過使用虛擬內存（VM），將很少訪問的數據交換到磁盤上，騰出內存空間的方法來解決物理內存不足的情況。雖然能夠解決物理內存不足導致的問題，但是由於這部分數據是存儲在磁盤上，如果在高並發場景中，頻繁訪問虛擬內存空間會嚴重降低系統性能。
所以遇到這類問題的時候，我們一般有幾種方法。
- 對每個存儲到redis中的key設置過期時間，這個根據實際業務場景來決定。否則，再大的內存都會雖則系統運行被消耗完。
- 增加內存
- 使用內存淘汰策略。
設置Redis能夠使用的最大內存
在實際生產環境中，服務器不僅僅只有Redis，為了避免Redis內存使用過多對其他程序造成影響，我們一般會設置最大內存。
Redis默認的最大內存maxmemory=0，表示不限制Redis內存的使用。我們可以修改redis.conf文件，設置Redis最大使用的內存。
# 單位為byte
maxmemory <bytes> 2147483648（2G）
如何查看當前Redis最大內存設置呢，進入到Redis-Cli控制台，輸入下面這個命令。
config get maxmemory
當Redis中存儲的內存超過maxmemory時，會怎么樣呢？下面我們做一個實驗
-
在redis-cli控制台輸入下面這個命令，把最大內存設置為1個字節。
config set maxmemory 1 -
通過下面的命令存儲一個string類型的數據
set name mic -
此時，控制台會得到下面這個錯誤信息
(error) OOM command not allowed when used memory > 'maxmemory'.
使用內存淘汰策略釋放內存
設置了maxmemory的選項，redis內存使用達到上限。可以通過設置LRU算法來刪除部分key，釋放空間。默認是按照過期時間的，如果set時候沒有加上過期時間就會導致數據寫滿maxmemory。
Redis中提供了一種內存淘汰策略，當內存不足時，Redis會根據相應的淘汰規則對key數據進行淘汰。 Redis一共提供了8種淘汰策略，默認的策略為noeviction，當內存使用達到閾值的時候，
所有引起申請內存的命令會報錯。
- volatile-lru，針對設置了過期時間的key，使用lru算法進行淘汰。
- allkeys-lru，針對所有key使用lru算法進行淘汰。
- volatile-lfu，針對設置了過期時間的key，使用lfu算法進行淘汰。
- allkeys-lfu，針對所有key使用lfu算法進行淘汰。
- volatile-random，從所有設置了過期時間的key中使用隨機淘汰的方式進行淘汰。
- allkeys-random，針對所有的key使用隨機淘汰機制進行淘汰。
- volatile-ttl，刪除生存時間最近的一個鍵。
- noeviction，不刪除鍵，值返回錯誤。
前綴為volatile-和allkeys-的區別在於二者選擇要清除的鍵時的字典不同，volatile-前綴的策略代表從redisDb中的expire字典中選擇鍵進行清除；allkeys-開頭的策略代表從dict字典中選擇鍵進行清除。
內存淘汰算法的具體工作原理是：
- 客戶端執行一條新命令，導致數據庫需要增加數據（比如set key value）
- Redis會檢查內存使用，如果內存使用超過 maxmemory，就會按照置換策略刪除一些 key
- 新的命令執行成功
了解並手寫LRU算法
LRU是Least Recently Used的縮寫，也就是表示最近很少使用，也可以理解成最久沒有使用。也就是說當內存不夠的時候，每次添加一條數據，都需要拋棄一條最久時間沒有使用的舊數據。
標准的LRU算法為了降低查找和刪除元素的時間復雜度，一般采用Hash表和雙向鏈表結合的數據結構，hash表可以賦予鏈表快速查找到某個key是否存在鏈表中，同時可以快速刪除、添加節點，如圖4-21所示。
雙向鏈表的查找時間復雜度是O(n)，刪除和插入是O(1)，借助HashMap結構，可以使得查找的時間復雜度變成O(1)
Hash表用來查詢在鏈表中的數據位置，鏈表負責數據的插入，當新數據插入到鏈表頭部時有兩種情況。
- 鏈表滿了，把鏈表尾部的數據丟棄掉，新加入的緩存直接加入到鏈表頭中。
- 當鏈表中的某個緩存被命中時，直接把數據移到鏈表頭部，原本在頭節點的緩存就向鏈表尾部移動
這樣，經過多次Cache操作之后，最近被命中的緩存，都會存在鏈表頭部的方向，沒有命中的，都會在鏈表尾部方向，當需要替換內容時，由於鏈表尾部是最少被命中的，我們只需要淘汰鏈表尾部的數據即可。
下面我們通過一段代碼實現一個簡單的LRU算法，加深大家對於LRU算法的理解。
public class LRUCache {
private Node head;
private Node tail;
private final HashMap<String,Node> nodeHashMap;
private int capacity;
public LRUCache(int capacity){
this.capacity=capacity;
nodeHashMap=new HashMap<>();
head=new Node();
tail=new Node();
head.next=tail;
tail.prev=head;
}
private void removeNode(Node node){
if(node==tail){
tail=tail.prev;
tail.next=null;
}else if(node==head){
head=head.next;
head.prev=null;
}else {
node.prev.next=node.next;
node.next.prev=node.prev;
}
}
private void addNodeToHead(Node node){
node.next=head.next;
head.next.prev=node;
node.prev=head;
head.next=node;
}
private void addNodeToTail(Node node){
node.prev=tail.prev;
node.prev.next=node;
node.next=tail;
tail.prev=node;
}
//當鏈表中的某個緩存被命中時，直接把數據移到鏈表頭部，原本在頭節點的緩存就向鏈表尾部移動
public void moveNodeToHead(Node node){
removeNode(node);
addNodeToHead(node);
}
public String get(String key){
Node node=nodeHashMap.get(key);
if(node==null){
return null;
}
//刷新當前節點的位置
moveNodeToHead(node);
//返回value值
return node.value;
}
public void put(String key,String value){
Node node=nodeHashMap.get(key);
if(node==null){ //不存在
//如果當前存儲的數據量達到了閾值，則需要淘汰掉訪問較少的數據
if(nodeHashMap.size()>=capacity){
removeNode(tail); //移除尾部節點
nodeHashMap.remove(tail.key);
}
node=new Node(key,value);
nodeHashMap.put(key,node);
addNodeToTail(node);
}else{
node.value=value;
//刷新當前節點的位置
moveNodeToHead(node);
}
}
public static void main(String[] args) {
LRUCache lruCache=new LRUCache(3);
lruCache.put("1","1");
lruCache.put("2","2");
lruCache.put("3","3");
// lruCache.get("3"); // 增加一個訪問次數之后，被清理的元素就會發生變化
System.out.println(lruCache.nodeHashMap);
lruCache.put("4","4");
System.out.println(lruCache.nodeHashMap);
}
}
class Node{
//雙向鏈表中的節點類，存儲key是因為我們在雙向鏈表刪除表尾的值時，只是返回了一個節點，
//所以這個節點要包括key值，這樣我們的哈希表才可以刪除對應key值的映射
public String key;
public String value;
Node prev;
Node next;
public Node(){}
public Node(String key, String value) {
this.key = key;
this.value = value;
}
}
Redis中的LRU算法
實際上，Redis使用的LRU算法其實是一種不可靠的LRU算法，它實際淘汰的鍵並不一定是真正最少使用的數據，它的工作機制是：
- 隨機采集淘汰的key，每次隨機選出5個key
- 然后淘汰這5個key中最少使用的key
這5個key是默認的個數，具體的數值可以在redis.conf中配置
maxmemory-samples 5
當近似LRU算法取值越大的時候就會越接近真實的LRU算法，因為取值越大獲取的數據越完整，淘汰中的數據就更加接近最少使用的數據。這里其實涉及一個權衡問題，
如果需要在所有的數據中搜索最符合條件的數據，那么一定會增加系統的開銷，Redis是單線程的，所以耗時的操作會謹慎一些。
為了在一定成本內實現相對的LRU，早期的Redis版本是基於采樣的LRU，也就是放棄了從所有數據中搜索解改為采樣空間搜索最優解。Redis3.0版本之后，Redis作者對於基於采樣的LRU進行了一些優化：
- Redis中維護一個大小為16的候選池，當第一次隨機選取采用數據時，會把數據放入到候選池中，並且候選池中的數據會更具時間進行排序。
- 當第二次以后選取數據時，只有小於候選池內最小時間的才會被放進候選池。
- 當候選池的數據滿了之后，那么時間最大的key就會被擠出候選池。當執行淘汰時，直接從候選池中選取最近訪問時間小的key進行淘汰。
如圖4-22所示，首先從目標字典中采集出maxmemory-samples個鍵，緩存在一個samples數組中，然后從samples數組中一個個取出來，和回收池中以后的鍵進行鍵的空閑時間，從而更新回收池。
在更新過程中，首先利用遍歷找到的每個鍵的實際插入位置x，然后根據不同情況進行處理。
- 回收池滿了，並且當前插入的key的空閑時間最小（也就是回收池中的所有key都比當前插入的key的空閑時間都要大），則不作任何操作。
- 回收池未滿，並且插入的位置x沒有鍵，則直接插入即可
- 回收池未滿，且插入的位置x原本已經存在要淘汰的鍵，則把第x個以后的元素都往后挪一個位置，然后再執行插入操作。
- 回收池滿了，將當前第x個以前的元素往前挪一個位置（實際就是淘汰了），然后執行插入操作。
這樣做的目的是能夠選出最真實的最少被訪問的key，能夠正確不常使用的key。因為在Redis3.0之前是隨機選取樣本，這樣的方式很有可能不是真正意義上的最少訪問的key。
LRU算法有一個弊端，加入一個key值訪問頻率很低，但是最近一次被訪問到了，那LRU會認為它是熱點數據，不會被淘汰。同樣，
經常被訪問的數據，最近一段時間沒有被訪問，這樣會導致這些數據被淘汰掉，導致誤判而淘汰掉熱點數據，於是在Redis 4.0中，新加了一種LFU算法。
LFU算法
LFU（Least Frequently Used），表示最近最少使用，它和key的使用次數有關，其思想是：根據key最近被訪問的頻率進行淘汰，比較少訪問的key優先淘汰，反之則保留。
LRU的原理是使用計數器來對key進行排序，每次key被訪問時，計數器會增大，當計數器越大，意味着當前key的訪問越頻繁，也就是意味着它是熱點數據。 它很好的解決了LRU算法的缺陷：一個很久沒有被訪問的key，偶爾被訪問一次，導致被誤認為是熱點數據的問題。
LFU的實現原理如圖4-23所示，LFU維護了兩個鏈表，橫向組成的鏈表用來存儲訪問頻率，每個訪問頻率的節點下存儲另外一個具有相同訪問頻率的緩存數據。具體的工作原理是：
- 當添加元素時，找到相同訪問頻次的節點，然后添加到該節點的數據鏈表的頭部。如果該數據鏈表滿了，則移除鏈表尾部的節點
- 當獲取元素或者修改元素是，都會增加對應key的訪問頻次，並把當前節點移動到下一個頻次節點。
添加元素時，訪問頻率默認為1，隨着訪問次數的增加，頻率不斷遞增。而當前被訪問的元素也會隨着頻率增加進行移動。
持久化機制的實現及原理
Redis的強勁性能很大程度上是由於它所有的數據都存儲在內存中，當然如果redis重啟或者服務器故障導致redis重啟，所有存儲在內存中的數據就會丟失。但是在某些情況下，我們希望Redis在重啟后能夠保證數據不會丟失。
-
將redis作為nosql數據庫使用。
-
將Redis作為高效緩存服務器，緩存被擊穿后對后端數據庫層面的瞬時壓力是特別大的，所有緩存同時失效可能會導致雪崩。
這時我們希望Redis能將數據從內存中以某種形式同步到硬盤上，使得重啟后可以根據硬盤中的記錄來恢復數據。
Redis支持兩種方式的持久化，一種是RDB方式、另一種是AOF（append-only-file）方式，兩種持久化方式可以單獨使用其中一種，也可以將這兩種方式結合使用。
- RDB：根據指定的規則“定時”將內存中的數據存儲在硬盤上，
- AOF：每次執行命令后將命令本身記錄下來。
4.3.1 RDB模式
RDB的持久化方式是通過快照（snapshotting）完成的，它是Redis默認的持久化方式，配置如下。
# save 3600 1
# save 300 100
# save 60 10000
Redis允許用戶自定義快照條件，當符合快照條件時，Redis會自動執行快照操作。快照的條件可以由用戶在配置文件中配置。配置格式如下
save <seconds> <changes>
第一個參數是時間窗口，第二個是鍵的個數，也就是說，在第一個時間參數配置范圍內被更改的鍵的個數大於后面的changes時，即符合快照條件。當觸發條件時，Redis會自動將內存中的數據生成一份副本並存儲在磁盤上，這個過程稱之為“快照”，除了上述規則之外，還有以下幾種方式生成快照。
- 根據配置規則進行自動快照
- 用戶執行SAVE或者GBSAVE命令
- 執行FLUSHALL命令
- 執行復制(replication)時
根據配置規則進行自動快照
- 修改redis.conf文件，表示5秒內，有一個key發生變化，就會生成rdb文件。
save 5 1 # 表示3600s以內至少發生1個key變化（新增、修改、刪除），則重寫rdb文件
save 300 100
save 60 10000
-
修改文件存儲路徑
dir /data/program/redis/bin -
其他參數配置說明
參數 說明 dir rdb文件默認在啟動目錄下（相對路徑） config get dir獲取dbfilename 文件名稱 rdbcompression 開啟壓縮可以節省存儲空間，但是會消耗一些CPU的計算時間，默認開啟 rdbchecksum 使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能。
如果需要關閉RDB的持久化機制，可以參考如下配置，開啟save，並注釋其他規則即可
save ""
#save 900 1
#save 300 10
#save 60 10000
用戶執行SAVE或者GBSAVE命令
除了讓Redis自動進行快照以外，當我們對服務進行重啟或者服務器遷移我們需要人工去干預備份。redis提供了兩條命令來完成這個任務
-
save命令
如圖4-24所示，當執行save命令時，Redis同步做快照操作，在快照執行過程中會阻塞所有來自客戶端的請求。當redis內存中的數據較多時，通過該命令將導致Redis較長時間的不響應。所以不建議在生產環境上使用這個命令，而是推薦使用bgsave命令
圖4-24 -
bgsave命令
如圖4-25所示，bgsave命令可以在后台異步地進行快照操作，快照的同時服務器還可以繼續響應來自客戶端的請求。執行BGSAVE后，Redis會立即返回ok表示開始執行快照操作，在redis-cli終端，通過下面這個命令可以獲取最近一次成功執行快照的時間（以 UNIX 時間戳格式表示）。
LASTSAVE
1：redis使用fork函數復制一份當前進程的副本(子進程)
2：父進程繼續接收並處理客戶端發來的命令，而子進程開始將內存中的數據寫入硬盤中的臨時文件
3：當子進程寫入完所有數據后會用該臨時文件替換舊的RDB文件，至此，一次快照操作完成。
注意：redis在進行快照的過程中不會修改RDB文件，只有快照結束后才會將舊的文件替換成新的，也就是說任何時候RDB文件都是完整的。 這就使得我們可以通過定時備份RDB文件來實現redis數據庫的備份， RDB文件是經過壓縮的二進制文件，占用的空間會小於內存中的數據，更加利於傳輸。
bgsave是異步執行快照的，bgsave寫入的數據就是for進程時redis的數據狀態，一旦完成fork，后續執行的新的客戶端命令對數據產生的變更都不會反應到本次快照
Redis啟動后會讀取RDB快照文件，並將數據從硬盤載入到內存。根據數據量大小以及服務器性能不同，這個載入的時間也不同。
執行FLUSHALL命令
該命令在前面講過，會清除redis在內存中的所有數據。執行該命令后，只要redis中配置的快照規則不為空，也就是save 的規則存在。redis就會執行一次快照操作。不管規則是什么樣的都會執行。如果沒有定義快照規則，就不會執行快照操作。
執行復制(replication)時
該操作主要是在主從模式下，redis會在復制初始化時進行自動快照。這個會在后面講到；
這里只需要了解當執行復制操作時，即時沒有定義自動快照規則，並且沒有手動執行過快照操作，它仍然會生成RDB快照文件。
RDB數據恢復演示
- 准備初始數據
redis> set k1 1
redis> set k2 2
redis> set k3 3
redis> set k4 4
redis> set k5 5
-
通過shutdown命令關閉觸發save
redis> shutdown -
備份dump.rdb文件(用來后續恢復)
cp dump.rdb dump.rdb.bak -
接着再啟動redis-server(systemctl restart redis_6379)，通過keys命令查看，發現數據還在
keys *
模擬數據丟失
-
執行flushall
redis> flushall -
shutdown(重新生成沒有數據的快照，用來模擬后續的數據恢復)
redis> shutdown -
再次啟動redis, 通過keys 命令查看，此時rdb中沒有任何數據。
-
恢復之前備份的rdb文件（之前保存了數據的rdb快照）
mv dump.rdb.bak dump.rdb -
再次重啟redis，可以看到之前快照保存的數據
keys *
RDB文件的優勢和劣勢
一、優勢
1.RDB是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點上的數據集，這種文件非常適合用於進行備份和災難恢復。
2.生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。
3.RDB 在恢復大數據集時的速度比AOF的恢復速度要快。
二、劣勢
-
1、RDB方式數據沒辦法做到實時持久化/秒級持久化。因為bgsave每次運行都要執行fork操作創建子進程，頻繁執行成本過高
-
2、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照之后的所有修改（數據有丟失）。
如果數據相對來說比較重要，希望將損失降到最小，則可以使用AOF方式進行持久化。
4.3.2 AOF模式
AOF(Append Only File)：Redis 默認不開啟。AOF采用日志的形式來記錄每個寫操作，並追加到文件中。開啟后，執行更改Redis數據的命令時，就會把命令寫入到AOF文件中。
Redis 重啟時會根據日志文件的內容把寫指令從前到后執行一次以完成數據的恢復工作。
AOF配置開關
# 開關
appendonly no /yes
# 文件名
appendfilename "appendonly.aof"
通過修改redis.conf重啟redis之后：systemctl restart redis_6379。
再次運行redis的相關操作命令，會發現在指定的dir目錄下生成appendonly.aof文件，通過vim查看該文件內容如下
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$3
mic
*3
$3
set
$4
name
$3
123
AOF配置相關問題解答
問題1：數據都是實時持久化到磁盤嗎？
雖然每次執行更改Redis數據庫內容的操作時，AOF都會將命令記錄在AOF文件中，但是事實上，由於操作系統的緩存機制，數據並沒有真正地寫入硬盤，而是進入了系統的硬盤緩存。在默認情況下系統每30秒會執行一次同步操作。以便將硬盤緩存中的內容真正地寫入硬盤。
在這30秒的過程中如果系統異常退出則會導致硬盤緩存中的數據丟失。一般來說能夠啟用AOF的前提是業務場景不能容忍這樣的數據損失，這個時候就需要Redis在寫入AOF文件后主動要求系統將緩存內容同步到硬盤中。在redis.conf中通過如下配置來設置同步機制。
| 參數 | 說明 |
|---|---|
| appendfsync everysec | AOF持久化策略（硬盤緩存到磁盤），默認everysec 1 no 表示不執行fsync，由操作系統保證數據同步到磁盤，速度最快，但是不太安全； 2 always 表示每次寫入都執行fsync，以保證數據同步到磁盤，效率很低； 3 everysec表示每秒執行一次fsync，可能會導致丟失這1s數據。通常選擇 everysec ，兼顧安全性和效率。 |
問題2：文件越來越大，怎么辦？
由於AOF持久化是Redis不斷將寫命令記錄到 AOF 文件中，隨着Redis不斷的運行，AOF 的文件會越來越大，文件越大，占用服務器內存越大以及 AOF 恢復要求時間越長。
例如set gupao 666，執行1000次，結果都是gupao=666。
為了解決這個問題，Redis新增了重寫機制，當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。
可以使用命令下面這個命令主動觸發重寫
redis> bgrewriteaof
AOF 文件重寫並不是對原文件進行重新整理，而是直接讀取服務器現有的鍵值對，然后用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的文件后去替換原來的 AOF 文件。
重寫觸發機制如下
| 參數 | 說明 |
|---|---|
| auto-aof-rewrite-percentage | 默認值為100。表示的是當目前的AOF文件大小超過上一次重寫時的AOF文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啟動時AOF文件大小為依據 |
| auto-aof-rewrite-min-size | 默認64M。表示限制了允許重寫的最小AOF文件大小，通常在AOF文件很小的情況下即使其中有很多冗余的命令我們也並不太關心 |
在啟動時，Redis會逐個執行AOF文件中的命令來將硬盤中的數據載入到內存中，載入的速度相對於RDB會慢一些
問題：重寫過程中，AOF文件被更改了怎么辦？
Redis 可以在 AOF 文件體積變得過大時，自動地在后台對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。
重寫的流程是這樣，
- 主進程會fork一個子進程出來進行AOF重寫，這個重寫過程並不是基於原有的aof文件來做的，而是有點類似於快照的方式，全量遍歷內存中的數據，然后逐個序列到aof文件中。
- 在fork子進程這個過程中，服務端仍然可以對外提供服務，那這個時候重寫的aof文件的數據和redis內存數據不一致了怎么辦？不用擔心，這個過程中，主進程的數據更新操作，會緩存到aof_rewrite_buf中，也就是單獨開辟一塊緩存來存儲重寫期間收到的命令，當子進程重寫完以后再把緩存中的數據追加到新的aof文件。
- 當所有的數據全部追加到新的aof文件中后，把新的aof文件重命名正式的文件名字，此后所有的操作都會被寫入新的aof文件。
- 如果在rewrite過程中出現故障，不會影響原來aof文件的正常工作，只有當rewrite完成后才會切換文件。因此這個rewrite過程是比較可靠的。
Redis允許同時開啟AOF和RDB，既保證了數據安全又使得進行備份等操作十分容易。如果同時開啟后，Redis重啟會使用AOF文件來恢復數據，因為AOF方式的持久化可能丟失的數據更少。
AOF的優劣勢
優點：
1、AOF 持久化的方法提供了多種的同步頻率，即使使用默認的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數據而已。
缺點：
1、對於具有相同數據的的Redis，AOF 文件通常會比 RDB 文件體積更大（RDB存的是數據快照）。
2、雖然 AOF 提供了多種同步的頻率，默認情況下，每秒同步一次的頻率也具有較高的性能。在高並發的情況下，RDB 比 AOF 具好更好的性能保證。
關注[跟着Mic學架構]公眾號，獲取更多精品原創
