Redis配置、優化及相關命令

阿新 • • 發佈：2022-12-07

一、關係資料庫和非關係型資料庫

1.1關係型資料庫

關係型資料庫是一個結構化的資料庫，建立在關係模型（二維表格模型）基礎上，一般面向於記錄。
SQL語句（標準資料查詢語言）就是一種基於關係型資料庫的語言，用於執行對關係型資料庫中資料的檢索和操作。
主流的關係型資料庫包括 Oracle、MySQL、SQL Server、Microsoft Access、DB2、PostqreSQL 等。
以上資料庫在使用的時候必須先建庫建表設計表結構，然後儲存資料的時候按表結構去存，如果資料與表結構不匹配就會儲存失敗。
關係資料庫的儲存結構是二維表格，關係型資料庫大部分將資料存放到硬碟中，可以將有關係的表放在一個庫中

在每個二維表格中
每一行稱為一條記錄，用來描述一個物件的資訊
每一列稱為一個欄位，用來描述物件的一個屬性

1.2非關係型資料庫

NoSQL（NoSQL = Not Only SQL），意思是"不僅僅是 SQL"，是非關係型資料庫的總稱。除了主流的關係型資料庫外的資料庫，都認為是非關係型。
不需要預先建庫建表定義資料儲存表結構，每條記錄可以有不同的資料型別和欄位個數（比如微信群聊甲的文字、圖片、視訊、音樂等）
主流的 NoSQL資料庫有 Redis、MongBD、Hbase、Memcached 等。

二、關係型資料庫和非關係型資料庫區別

2.1資料儲存方式不同

關係型和非關係型資料庫的主要差異是資料儲存的方式。

（1）關係型資料

天然就是表格式的，因此儲存在資料表的行和列中。資料表可以彼此關聯協作儲存，也很容易提取資料。

（2）非關係型資料庫

與其相反，非關係型資料不適合儲存在資料表的行和列中，而是大塊組合在一起。非關係型資料通常儲存在資料集中，就像文件、鍵值對或者圖結構。資料及其特性是選擇資料儲存和提取方式的首要影響因素。

2.2擴充套件方式不同

SQL和NoSQL資料庫最大的差別可能是在擴充套件方式上，要支援日益增長的需求當然要擴充套件賴支援更多併發量。

（1）SQL資料庫

是縱向擴充套件，擴充套件CPU等效能磁碟空間空間，也就是提高處理能力，使用速度更快速的計算機，這樣處理相同的資料集就更快了。因為資料儲存在關係表中，操作的效能瓶頸可能涉及很多個表，這都需要通過提高計算機效能來克服。雖然SOL資料庫有很大擴充套件空間，但最終肯定會達到縱向擴充套件的上限。

（2）NoSQL資料庫

是橫向擴充套件的。因為非關係型資料儲存天然就是分散式的，NoSQL資料庫的擴充套件可以通過給資源池新增更多普通的資料庫伺服器（節點）來分擔負載。

2.3對事務性的支援不同

（1）SQL資料庫

如果資料操作需要高事務性或者複雜資料查詢需要控制執行計劃，那麼傳統的SQL資料庫從效能和穩定性方面考慮是最佳選擇。SQL，資料庫支援對事務原子性細粒度控制，並且易於回滾事務。

（2）NoSQL資料庫

雖然NoSQL資料庫也可以使用事務操作，但穩定性方面沒法和關係型資料庫比較，所以它們真正閃亮的價值是在操作的擴充套件性和大資料量處理方面。

關係型: 特別適合高事務性要求和需要控制執行計劃的任務
非關係型: 此處會稍顯弱勢，其價值點在於高擴充套件性和大資料量處理方面

2.4非關係型資料庫產生背景

可用於應對 Web2.0 純動態網站型別的三高問題。

Highperformance：對資料庫高併發讀寫需求
Huge Storage：對海量資料高效儲存與訪問需求
High Scalability && High Availability：對資料庫高可擴充套件性與高可用性需求

關係型資料庫和非關係型資料庫都有各自的特點與應用場景，兩者的緊密結合將會給web2.0的資料庫發展帶來新的思略。讓關係資料庫關注在關係上，非關係型資料庫關注在儲存上。
例如，在讀寫分離的MySQL資料庫環境中，可以把經常訪問的資料儲存在非關係型資料庫中，提升訪問速度。

2.5SQL和NoSQL資料的儲存過程

（1）關係型資料庫

例項-->資料庫-->表（table）-->記錄行（row）、資料欄位（column）

（2）非關係型資料庫

例項-->資料庫-->集合（collection）-->鍵值對（key-value）、文件、圖結構
非關係型資料庫不需要手動建資料庫和集合（表）

三、Redis資料庫

3.1Redis資料庫的概述

Redis（遠端字典伺服器）是一個開源的、使用C語言編寫的NoSQL資料庫
Redis 基於記憶體執行並支援持久化，採用key-value（鍵值對）的儲存形式，是目前分散式架構中不可或缺的一環。
Redis伺服器程式是單程序模型，也就是在一臺伺服器上可以同時啟動多個Redis程序，Redis的實際處理速度則是完全依靠於主程序的執行效率。
若在伺服器上只執行一個Redis程序，當多個客戶端同時訪問時，伺服器的處理能力是會有一定程度的下降; 若在同一臺伺服器上開啟多個Redis程序，Redis在提高併發處理能力的同時會給伺服器的CPU造成很大壓力。
在實際生產環境中，需要根據實際的需求來決定開啟多少個Redis程序。若對高併發要求更高一些，可能會考慮在同一臺伺服器上開啟多個程序。若CPU資源比較緊張，採用單程序即可。

拓展：Redis6.0之前都是單執行緒，6.0版本之後支援多執行緒，但一般只針對網路，讀寫方面還是使用單執行緒

3.2Redis的特點

具有極高的資料讀寫速度∶資料讀取的速度最高可達到 110000 次/s，資料寫入速度最高可達到 81000 次/s。
支援豐富的資料型別∶使用key-value儲存模式，Strings、Lists、Hashes、Sets 及 Sorted Sets 等資料型別操作。
支援資料的持久化∶可以將記憶體中的資料儲存在磁碟中，重啟的時候可以再次載入進行使用。
原子性∶Redis所有操作都是原子性的。
支援資料備份∶即 master-salve 模式的資料備份。

Redis作為基於記憶體執行的資料庫，快取是其最常應用的場景之一。除此之外， Redis常見應用場景還包括獲取最新N個數據的操作、排行榜類應用、計數器應用、儲存關係、實時分析系統、日誌記錄（根據不同的資料型別實現不同場景的支援）。

3.3Redis五種資料型別

（1）String資料型別

概述：String是redis最基本的型別，最大能儲存512MB的資料，String型別是二進位制安全的，即可以儲存任何資料、比如數字、圖片、序列化物件等

（2）List資料型別

概述：列表的元素型別為string，按照插入順序排序，在列表的頭部或尾部新增元素

（3）Hash資料型別（雜湊型別）

概述：hash用於儲存物件。可以採用這樣的命名方式：物件類別和ID構成鍵名，使用欄位表示物件的屬性，而欄位值則儲存屬性值。如：儲存ID為2的汽車物件。
如果Hash中包含很少的欄位，那麼該型別的資料也將僅佔用很少的磁碟空間。每一個Hash可以儲存4294967295個鍵值對。

（4）Set資料型別（無序集合）

概述：無序集合，元素型別為String型別，元素具有唯一性，不允許存在重複的成員。多個集合型別之間可以進行並集、交集和差集運算。
應用範圍：

可以使用Redis的Set資料型別跟蹤一些唯一性資料，比如訪問某一部落格的唯一IP地址資訊。對於此場景，我們僅需在每次訪問該部落格時將訪問者的IP存入Redis中，Set資料型別會自動保證IP地址的唯一性。
充分利用Set型別的服務端聚合操作方便、高效的特性，可以用於維護資料物件之間的關聯關係。比如所有購買某一電子裝置的客戶ID被儲存在一個指定的Set中，而購買另外一種電子產品的客戶ID被儲存在另外一個Set中，如果此時我們想獲取有哪些客戶同時購買了這兩種商品時，Set的intersections命令就可以充分發揮它的方便和效率的優勢了。

（5）Sorted Set資料型別（zset、有序集合）

概述：有序集合，元素型別為Sting，元素具有唯一性，不能重複。
每個元素都會關聯一個double型別的分數score(表示權重)，可以通過權重的大小排序，元素的score可以相同。

應用範圍：

可以用於一個大型線上遊戲的積分排行榜。每當玩家的分數發生變化時，可以執行ZADD命令更新玩家的分數，此後再通過ZRANGE命令獲取積分TOP10的使用者資訊。當然我們也可以利用ZRANK命令通過username來獲取玩家的排行資訊。最後我們將組合使用ZRANGE和ZRANK命令快速的獲取和某個玩家積分相近的其他使用者的資訊。
Sorted-Set型別還可用於構建索引資料。

3.4Redis效率快的原因

Redis 是一款純記憶體結構，避免了磁碟I/O等耗時操作。
Redis 命令處理的核心模組為單執行緒，減少了鎖競爭，以及頻繁建立執行緒和銷燬執行緒的代價，減少了執行緒上下文切換的消耗。
採用了 I/O 多路複用機制，大大提升了併發效率。

I/O多路複用程式雖然會同時監聽多個 Socket 連線，但是其會將監聽的 Socket 都放到一個佇列裡面，然後通過這個佇列有序的，同步的將每個 Socket 對應的事件傳送給檔案事件分派器，再由檔案事件分派器分派給對應的事件處理器進行處理，只有當一個 Socket 所對應的事件被處理完畢之後，I/O多路複用程式才會繼續向檔案事件分派器傳送下一個 Socket所對應的事件，這也可以驗證上面的結論，處理客戶端的命令請求是單執行緒的方式逐個處理，但是事件處理器內並不是只有一個執行緒。

四、Redis 部署以及相關命令

4.1Redis安裝部署的操作步驟

（1）關閉防火牆和SElinux

systemctl stop firewalld
setenforce 0

（2）安裝gcc gcc-c++ 編譯器

yum install -y gcc gcc-c++ make

（3）將redis-5.0.7.tar.gz壓縮包上傳到/opt目錄中，解壓，並編譯安裝

tar zxvf redis-5.0.7.tar.gz -C /opt/
 
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install

由於Redis原始碼包中直接提供了Makefile檔案，所以在解壓完軟體包後，不用先執行./configure進行配置，可直接執行make與make install命令進行安裝

（4）執行軟體包提供的installserver.sh指令碼檔案設定Redis服務所需要的相關配置檔案

cd /opt/redis-5.0.7/utils
./install_server.sh
......
#一直回車.
Please select the redis executable path [/usr/local/bin/redis-server]
/usr/local/redis/bin/redis-server
#需要手動修改為/usr/local/redis/bin/redis-server 注意要一次性正確輸入
 
Selected config:
Port : 6379 #預設偵聽埠為6379
Config file : /etc/redis/6379.conf  #配置檔案路徑
Log file : /var/log/redis_6379.log  #日誌檔案路徑
Data dir : /var/lib/redis/6379  #資料檔案路徑
Executable : /usr/local/redis/bin/redis-server  #可執行檔案路徑
Cli Executable : /usr/local/bin/redis-cli   #客戶端命令工具

（5）把redis的可執行程式檔案放入路徑環境變數的目錄中便於系統識別

ln -s /usr/local/redis/bin/* /usr/local/bin/
 
#當install_server.sh 指令碼執行完畢，Redis 服務就已經啟動，預設偵聽埠為6379
netstat -natp | grep redis

（6）Redis服務控制

/etc/init.d/redis_6379 stop
#停止
/etc/init.d/redis_6379 start
#啟動
/etc/init.d/redis_6379 restart
#重啟
/etc/init.d/redis_6379 status
#狀態　
chmod +x /etc/init.d/redis_6379                                #加入全域性系統環境，使用systemctl命令管理
 
chkconfig --add /etc/init.d/redis_6379    
 
systemctl start redis_6379.service

（7）修改配置/etc/redis/6379.conf引數

vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.10.100
#70行，新增監聽的主機地址
port 6379
#93行，Redis預設的監聽埠
daemonize yes
#137行，啟用守護程序
pidfile /var/run/redis_6379.pid
#159行，指定PID檔案
loglevel notice
#167行，日誌級別
logfile /var/log/redis_6379.log
#172行，指定日誌檔案
 
/etc/init.d/redis_6379 restart

4.2例項操作：Redis安裝部署

1、關閉防火牆和核心防護

2、安裝gcc gcc-c++ 編譯器

3、將redis包放到opt目錄下解壓，編譯按照

4、執行軟體包提供的installserver.sh指令碼檔案設定Redis服務所需要的相關配置檔案

5、把redis的可執行程式檔案放入路徑環境變數的目錄中便於系統識別

6、Redis服務控制

7、修改配置/etc/redis/6379.conf引數

4.3Redis命令工具

redis-server 用於啟動 Redis 的工具
redis-benchmark 用於檢測 Redis 在本機的執行效率
redis-check-aof 修復 AOF 持久化檔案
redis-check-rdb 修復 RDB 持久化檔案
redis-cli Redis命令列工具
rdb和aof是redis服務中持久化功能的兩種形式RDB AOF
redis-cli 常用於登陸至redis資料庫

4.4redis-cli命令列工具（遠端登入）

語法: redis-cli -h host -p port -a password
選項：
    -h :指定遠端主機
    -p :指定Redis 服務的埠號
    -a :指定密碼，未設定資料庫密碼可以省略-a選項
若不新增任何選項表示，則使用127.0.0.1:6379 連線本機上的 Redis 資料庫，
 
redis-cli -h 192.168.10.100 -p 6379

4.5redis-benchmark 測試工具

redis-benchmark 是官方自帶的 Redis 效能測試工具，可以有效的測試 Redis 服務的效能。

-h：指定伺服器主機名
-p：指定伺服器埠
-s：指定伺服器 socket
-c：指定併發連線數
-n：指定請求數
-d：以位元組的形式指定 SET/GET 值的資料大小
-k：1=keep alive 0=reconnect
-r: SET/GET/INCR 使用隨機 key, SADD 使用隨機值
-P：通過管道傳輸<numred>請求
-q：強制退出 redis。僅顯示 query/sec 值
–csv：以 CSV 格式輸出
-l：生成迴圈，永久執行測試
-t：僅執行以逗號分隔的測試命令列表
-I：Idle 模式。僅開啟 N 個 idle 連線並等待
 
 
#向 IP 地址為 192.168.10.100、埠為 6379 的 Redis 伺服器傳送 100 個併發連線與 100000 個請求測試效能
redis-benchmark -h 192.168.10.100 -p 6379 -c 100 -n 100000
 
#測試存取大小為 100 位元組的資料包的效能
redis-benchmark -h 192.168.10.100 -p 6379 -q -d 100
 
#測試本機上 Redis 服務在進行 set 與 lpush 操作時的效能
redis-benchmark -t set,lpush -n 100000 -q

1、向 IP 地址為 192.168.10.100、埠為 6379 的 Redis 伺服器傳送 100 個併發連線與 100000 個請求測試效能

2、測試存取大小為 100 位元組的資料包的效能

3、測試本機上 Redis 服務在進行 set 與 lpush 操作時的效能

4.6Redis資料庫常用命令

（1）常用命令

（2）set與get用法

set: 存放資料，命令格式為 set key value
get: 獲取資料，命令格式為 get key　

（3）keys 命令

keys 命令可以取符合規則的鍵值列表，通常情況可以結合*、?等選項來使用。

（4）exists 命令

可以判斷鍵值是否存在

（5）del 命令

可以刪除當前資料庫的指定key

（6）type 命令

可以獲取key對應的 value 值型別

（7）rename 命令

是對已有key進行重新命名。 (覆蓋)
命令格式: rename 源key 目標key
使用rename命令進行重新命名時，無論目標key是否存在都進行重新命名，且源key的值會覆蓋目標key的值。
在實際使用過程中，建議先用 exists命令檢視目標key是否存在，然後再決定是否執行rename命令，以避免覆蓋重要資料。

（8)renamenx 命令

作用是對已有key進行重新命名，並檢測新名是否存在
如果目標key存在則不進行重新命名。 (不覆蓋)
命令格式: renamenx 源key 目標key

（9）dbsize命令
作用是檢視當前資料庫中key的數目。

（10）使用config set requirepass 命令設定密碼

（11）使用config get requirepass 命令檢視密碼

注意：一旦設定密碼，必須先驗證通過密碼，否則所有操作不可用

（12）刪除密碼

4.7Redis 多資料庫常用命令

Redis支援多資料庫，Redis 預設情況下包含16個數據庫，資料庫名稱是用數字0-15 來依次命名的
多資料庫相互獨立，互不干擾

（1）多資料庫間切換

命令格式: select 序號
使用 redis-cli 連線Redis資料庫後，預設使用的是序號為 0 的資料庫。

（2）多資料庫間移動資料

格式: move 鍵值序號

（3）清除資料庫內資料

FLUSHDB :清空當前資料庫資料
FLUSHALL :清空所有資料庫的資料，慎用!!! 　

五、Redis 高可用

在web伺服器中，高可用是指伺服器可以正常訪問的時間，衡量的標準是在多長時間內可以提供正常服務(99.9%、99.99%、99.999%等等)。
但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(如主從分離、快速容災技術)，還需要考慮資料容量的擴充套件，資料安全不會丟失等。
在Redis中，實現高可用的技術主要包括持久化、主從複製、哨兵和叢集，作用如下：
（1）持久化 :持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是資料備份，即將資料儲存在硬碟，保證資料不會因程序退出而丟失。
（2）主從複製 :主從複製是高可用Redis的基礎，哨兵和叢集都是在主從複製基礎上實現高可用的。主從複製主要實現了資料的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復。
缺陷:故障恢復無法自動化;寫操作無法負載均衡;儲存能力受到單機的限制。
（3）哨兵 :在主從複製的基礎上，哨兵實現了自動化的故障恢復。缺陷 :寫操作無法負載均衡;儲存能力受到單機的限制。
叢集 : 通過叢集， Redis解決了寫操作無法負載均衡，以及儲存能力受到單機限制的問題，實現了較為完善的高可用方案。

六、Redis持久化

6.1持久化的功能

Redis是記憶體資料庫，資料都是儲存在記憶體中，為了避免伺服器斷電等原因導致Redis程序異常退出後資料的永久丟失，需要定期將Redis中的資料以某種形式( 資料或命令)從記憶體儲存到硬碟;當下次Redis重啟時，利用持久化檔案實現資料恢復。
除此之外，為了進行災難備份，可以將持久化檔案拷貝到一個遠端位置（NFS）

6.2Redis提供兩種方式持久化

RDB持久化 : 原理是將Reids在記憶體中的資料庫記錄定時儲存到磁碟上
AOF持久化(append only file) : 原理是將Reids的操作日誌以追加的方式寫入檔案，類似於MySQL的binlog
由於AOF持久化的實時性更好，即當程序意外退出時丟失的資料更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地

七、RDB持久化

RDB持久化是指在指定的時間間隔內將記憶體中當前程序中的資料生成快照儲存到硬碟(因此也稱作快照持久化)，用二進位制壓縮儲存，儲存的檔案字尾是rdb；當Redis重新啟動時，可以讀取快照檔案恢復資料

7.1觸發條件

RDB持久化的觸發分為手動觸發和自動觸發兩種

（1）手動觸發

save命令和bgsave命令都可以生成RDB檔案
save命令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求
而bgsave命令會建立一個子程序，由子程序來負責建立RDB檔案，父程序 (即Redis主程序) 則繼續處理請求
bgsave命令執行過程中，只有fork 子程序時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用！！！

往往生產環境 bgsave 依然不允許輕易使用

（2）自動觸發

在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化
save m n：自動觸發最常見的情況是在配置檔案中通過save m n，指定當m秒內發生n次變化時，會觸發bgsave

vim /etc/redis/6379.conf
--219行--以下三個save條件滿足任意一個時，都會引起bgsave的呼叫
save 900 1 :當時間到900秒時，如果redis資料發生了至少1次變化，則執行bgsave
save 300 10 :當時間到300秒時， 如果redis資料發生了至少10次變化，則執行bgsave
save 60 10000 :當時間到60秒時，如果redis資料發生了至少10000次變化， 則執行bgsave
--242行--是否開啟RDB檔案壓縮
rdbcompression yes
--254行--指定RDB檔名
dbfilename dump.rdb
--264行--指定RDB檔案和AOF檔案所在目錄
dir /var/lib/redis/6379

（3）其他自動觸發機制

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

在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb檔案傳送給從節點
執行shutdown命令時，自動執行rdb持久化

執行流程：

Redis父程序首先判斷 :當前是否在執行save，或bgsave/bgrewriteaof的子程序，如果在執行，則bgsave命令直接返回bgsave/bgrewriteaof 的子程序不能同時執行，主要是基於效能方面的考慮:兩個併發的子程序同時執行大量的磁碟寫操作，可能引起嚴重的效能問題
父程序執行fork操作建立子程序，這個過程中父程序是阻塞的，Redis不能執行來自客戶端的任何命令
父程序fork後，bgsave 命令返回”Background saving started" 資訊並不再阻塞父程序，並可以響應其他命令
子程序建立RDB檔案，根據父程序記憶體快照生成臨時快照檔案，完成後對原有檔案進行原子替換
子程序傳送訊號給父程序表示完成，父程序更新統計資訊

啟動時載入：

RDB檔案的載入工作是在伺服器啟動時自動執行的，並沒有專門的命令。但是由於A0F的優先順序更高，因此當AOF開啟時，Redis會優先載入AOF檔案來恢復資料;只有當A0F關閉時，才會在Redis伺服器啟動時檢測RDB檔案，並自動載入。伺服器載入RDB檔案期間處於阻塞狀態，直到載入完成為止
Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗

八、AOF持久化

RDB持久化是將程序資料寫入檔案，而AOF持久化，則是將Redis執行的每次寫、刪除命令記錄到單獨的日誌檔案中，查詢操作不會記錄; 當Redis重啟時再次執行AOF檔案中的命令來恢復資料。
與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案

8.1開啟AOF

Redis伺服器預設開啟RDB，關閉AOF: 要開啟AOF，需要在配置檔案中配置:

vim /etc/redis/6379.conf
- 700行--修改， 開啟AOF
appendonly yes
--704行--指定A0F檔名稱
appendfilename "appendonly.aof"
--796行--是否忽略最後一條可能存在問題的指令
aof-load-truncated yes
 
/etc/init.d/redis_6379 restart

8.2執行流程

由於需要記錄Redis的每條寫命令，因此A0F不需要觸發，AOF的執行流程如下：

（1）AOF的執行流程包括

• 命令追加(append): 將Redis的寫命令追加到緩衝區aof_ buf;
• 檔案寫入(write)和檔案同步(sync):根據不同的同步策略將aof_buf中的內容同步到硬碟;
• 檔案重寫(rewrite): 定期重寫AOF檔案，達到壓縮的目的。
① 命令追加 (append)
Redis先將寫命令追加到緩衝區，而不是直接寫入檔案，主要是為了避免每次有寫命令都直接寫入硬碟，導致硬碟IO成為Redis負載的瓶頸。
命令追加的格式是Redis命令請求的協議格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點。在A0F檔案中，除了用於指定資料庫的select命令 (如select0為選中0號資料庫) 是由Redis新增的，其他都是客戶端傳送來的寫命令
② 檔案寫入(write) 和檔案同步 (sync)
Redis 提供了多種AOF快取區的同步檔案策略，策略涉及到作業系統的write函式和fsync函式，說明如下:
為了提高檔案寫入效率，在現代作業系統中，當用戶呼叫write函式將資料寫入檔案時，作業系統通常會將資料暫存到一個記憶體緩衝區裡，當緩衝區被填滿或超過了指定時限後，才真正將緩衝區的資料寫入到硬盤裡。這樣的操作雖然提高了效率，但也帶來了安全問題:如果計算機停機，記憶體緩衝區中的資料會丟失;因此係統同時提供了fsync、fdatasync等同步函式，可以強制作業系統立刻將緩衝區中的資料寫入到硬盤裡，從而確保資料的安全性
AOF快取區的同步檔案策略存在三種同步方式，它們分別是：

vim ``/etc/redis/6379``.conf``---729---``
● appendfsync always:``命令寫入aof_buf後立即呼叫系統fsync操作同步到AOF檔案，fsync完成後執行緒返回。這種情況下，每次有寫命令都要同步到AOF檔案，硬碟IO成為效能瓶頸，Redis只能支援大約幾百TPS寫入，嚴重降低了Redis的效能；即便是使用固態硬碟(SSD)，每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
● appendfsync no:``命令寫入aof_buf後呼叫系統write操作，不對AOF檔案做fsync同步;同步由作業系統負責，通常同步週期為30秒。這種情況下，檔案同步的時間不可控，且緩衝區中堆積的資料會很多，資料安全性無法保證。
● appendfsynceverysec:``命令寫入aof_buf後呼叫系統write操作，write完成後執行緒返回; fsync同步檔案操作由專門的執行緒每秒呼叫一次。everysec是前述兩種策略的折中，是效能和資料安全性的平衡，因此是Redis的預設配置，也是我們推薦的配置。

③ 檔案重寫 (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。
通過上述內容可以看出，由於重寫後AOF執行的命令減少了，檔案重寫既可以減少檔案佔用的空間，也可以加快恢復速度
• 手動觸發：直接呼叫bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子程序進行具體的工作，且都只有在fork時阻塞
• 自動觸發：通過設定auto-aof - rewrite-min-size選項和auto- aof - rewrite- percentage選項來自動執行BGREWRITEAOF
只有當auto-aof- rewrite- -min-size和auto-aof -rewrite-percentage兩個選項同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作

vim /etc/redis/ 6379. conf
----729----
● auto-aof- rewrite-percentage 100
：當前AOF檔案大小(即aof_current_size)是上次日誌重寫時AOF檔案大小(aof_base_size)兩倍時，發生BGREWRITEAOF操作
● auto-aof - rewrite-min-size 64mb
：當前A0F檔案執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由於檔案尺寸較小導致頻繁的BGREWRITEAOF

關於檔案重寫的流程，有兩點需要特別注意：
♢ 重寫由父程序fork子程序進行;
♢ 重寫期間Redis執行的寫命令，需要追加到新的AOF檔案中，為此Redis引入了aof_ rewrite_buf快取

檔案重寫的流程如下：
(1) Redis父程序首先判斷當前是否存在正在執行bgsave/bgrewriteaof的子程序，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執行完成後再執行
(2) 父程序執行fork操作建立子程序，這個過程中父程序是阻塞的
(3.1) 父程序fork後，bgrewriteaof 命令返回"Background append only file rewrite started" 資訊並不再阻塞父程序，並可以響應其他命令。Redis的所有寫命令依然寫入AOF緩衝區，並根據appendfsync策略同步到硬碟，保證原有A0F機制的正確
(3.2) 由於fork操作使用寫時複製技術，子程序只能共享fork操作時的記憶體資料。由於父程序依然在響應命令，因此Redis使用AOF重寫緩衝區(aof_ rewrite_buf) 儲存這部分資料，防止新AOF檔案生成期間丟失這部分資料。也就是說，bgrewriteaof執行期間，Redis的寫命令同時追加到aof_ buf和aof_ rewirte_ buf兩個緩衝區
(4) 子程序根據記憶體快照，按照命令合併規則寫入到新的AOF檔案
(5.1) 子程序寫完新的AOF檔案後，向父程序發訊號，父程序更新統計資訊，具體可以通過info persistence檢視
(5.2) 父程序把AOF重寫緩衝區的資料寫入到新的AOF檔案，這樣就保證了新AOF檔案所儲存的資料庫狀態和伺服器當前狀態一致
(5.3) 使用新的AOF檔案替換老檔案，完成AOF重寫

8.3啟動時載入

當AOF開啟時，Redis啟動時會優先載入AOF檔案來恢復資料;只有當AOF關閉時，才會載入RDB檔案恢復資料
當AOF開啟，但AOF檔案不存在時，即使RDB檔案存在也不會載入
Redis載入AOF檔案時，會對AOF檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。但如果是AOF檔案結尾不完整 (機器突然宕機等容易導致檔案尾部不完整)，且aof-load- truncated引數開啟，則日誌中會輸出警告，Redis 忽略掉AOF檔案的尾部，啟動成功
aof-load-truncated引數預設是開啟的

九、RDB和AOF的優缺點

9.1RDB持久化

優點：

vRDB檔案緊湊，體積小，網路傳輸快，適合全量複製;恢復速度比AOF快很多。當然，與AOF相比， RDB最重要的優點之一是對效能的影響相對較小

缺點：

RDB檔案的致命缺點在於其資料快照的持久化方式決定了必然做不到實時持久化，而在資料越來越重要的今天，資料的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB檔案需要滿足特定格式，相容性差(如老版本的Redis不相容新版本的RDB檔案)
對於RDB持久化，一方面是bgsave在進行fork操作時Redis主程序會阻塞，另一方面，子程序向硬碟寫資料也會帶來IO壓力

9.2AOF持久化

與RDB持久化相對應，AOF的優點在於支援秒級持久化、相容性好，缺點是檔案大、恢復速度慢、對效能影響大
對於AOF持久化，向硬碟寫資料的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題
AOF檔案的重寫與RDB的bgsave類似，會有fork時的阻塞和子程序的I0壓力問題。相對來說，由於AOF向硬碟中寫資料的頻率更高，因此對Redis主程序效能的影響會更大

十、Redis效能管理

10.1檢視Redis記憶體使用

127.0.0.1:6379> info memory

10.2記憶體碎片率

作業系統分配的記憶體值used_ memory_ rss除以Redis使用的記憶體值used_ memory計算得出記憶體碎片是由
作業系統低效的分配/回收物理記憶體導致的 (不連續的實體記憶體分配)

跟蹤記憶體碎片率對理解Redis例項的資源效能是非常重要的:

記憶體碎片率稍大於1是合理的，這個值表示記憶體碎片率比較低
記憶體碎片率超過1.5，說明Redis消耗了實際需要實體記憶體的150號，其中50號是記憶體碎片率。需要在redis-cli工具.上輸入shutdown save命令，並重啟Redis 伺服器
記憶體碎片率低於1的，說明Redis記憶體分配超出了實體記憶體，作業系統正在進行記憶體交換。需要增加可用實體記憶體或減少Redis記憶體佔用

10.3記憶體使用率

redis例項的記憶體使用率超過可用最大記憶體，作業系統將開始進行記憶體與swap空間交換

避免記憶體交換髮生的方法：

針對快取資料大小選擇安裝Redis 例項
儘可能的使用Hash資料結構儲存
設定key的過期時間

10.4內回收key

保證合理分配redis有限的記憶體資源
當達到設定的最大閥值時，需選擇一種key的回收策略，預設情況下回收策略是禁止刪除

配置檔案中修改maxmemory- policy屬性值：

vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
●volatile-lru :使用LRU演算法從已設定過期時間的資料集合中淘汰資料
●volatile-ttl :從已設定過期時間的資料集合中挑選即將過期的資料淘汰
●volatile-random :從已設定過期時間的資料集合中隨機挑選資料淘汰
●allkeys-lru :使用LRU演算法從所有資料集合中淘汰資料
●allkeys-random :從資料集合中任意選擇資料淘汰
●noenviction :禁止淘汰資料