目錄

—、快取概念

　　  1.1系統快取

　　　　  1.1.1 buffer與cache

　　  1.2快取儲存位置及分層結構

　　　　  1.2.1 DNS快取

　　　　  1.2.2應用層快取

　　　　  1.2.3資料層快取

　　　　  1.2.4硬體快取

二、關係資料庫和非關係資料庫

　　  2.1什麼是關係型資料庫

　　  2.2什麼是非關係型資料庫

　　  2.3非關係型資料庫的產生背景

　　  2.4關係型資料庫和非關係型資料庫區別

　　  2.5總結

三、Redis介紹

四、Redis優點

五、單執行緒

六、redis 對比 memcached

七、Redis安裝部署

　　  7.1部署步驟

　　  7.2Redis命令工具

　　  7.3 redis-cli命令列工具(遠端登入)

　　  7.4 redis-benchmark測試工具

八、Redis資料庫常用命令

　　  8.1常用命令

　　  8.2示例

　　　　  8.2.1存放、獲取資料

　　　　  8.2.2獲取所有的key

　　　　  8.2.3以A開頭的資料、以B開頭後面包含任意—位的資料

　　　　  8.2.4判斷資料是否存在

　　　　  8.2.5刪除資料

　　　　  8.2.6對已有key進行重新命名rename

　　　　  8.2.7 renamenx

　　　　  8.2.8 dbsize命令——檢視當前資料庫中key的數目

　　　　  8.2.9 type獲取值型別

　　　　  8.2.10設定密碼

　　　　  8.2.11 刪除密碼

九、Redis多資料庫常用命令

　　  9.1多資料庫間切換

　　  9.2多資料庫間移動資料

　　  9.3清除資料庫內資料 

十、Redis高可用

十一、 Redis持久化

　　  11.1持久化的功能:

　　  11.2Redis提供兩種方式進行持久化

十二、RDB持久化

　　  12.1觸發條件

　　 　　  ①手動觸發

　　　　   ②自動觸發

　　　　   ③其他自動觸發機制

　　  12.2執行流程

　　  12.3啟動時載入

十三、AOF持久化

　　   13.1開啟AOF

　　   13.2執行流程

　　　　     1)命令追加(append)

　　　　　 2)檔案寫入(write)和檔案同步(sync)

　　　　     3)檔案重寫(rewrite)

　　　　　 4)檔案重寫能壓縮AOF檔案的原因

　　   13.3檔案重寫的觸發

　　   13.4檔案重寫的流程

　　   13.5重寫流程注意點

　　   13.6啟動時載入

十四、RDB和AOF的優缺點

　　   14.1 RDB持久化的優缺點

　　   14.2AOF持久化的優缺點

十五、Redis效能管理

　　   15.1、檢視Redis記憶體使用

　　   15.2、記憶體碎片率

　　   15.3、跟蹤記憶體碎片率

　　   15.4、記憶體使用率

　　   15.5、內回收key

 

 

 

—、快取概念

1.1系統快取

1.1.1 buffer與cache

• buffer：緩衝也叫寫緩衝，一般用於寫操作，可以將資料先寫入記憶體再寫入磁碟，buffer 一般用於寫緩衝，用於解決不同介質的速度不一致的緩衝，先將資料臨時寫入到裡自己最近的地方，以提高寫入速度，CPU會把資料先寫到記憶體的磁碟緩衝區，然後就認為資料已經寫入完成看，然後由核心在後續的時間在寫入磁碟，所以伺服器突然斷電會丟失記憶體中的部分資料。
• cache：快取也叫讀快取，一般用於讀操作，CPU讀檔案從記憶體讀，如果記憶體沒有就先從硬碟讀到記憶體再讀到CPU，將需要頻繁讀取的資料放在裡自己最近的快取區域，下次讀取的時候即可快速讀取。

 

1.2快取儲存位置及分層結構

網際網路應用領域,提到快取為王

• 使用者層: 瀏覽器DNS快取,應用程式DNS快取,作業系統DNS快取客戶端
• 代理層: CDN,反向代理快取
• Web層: Web伺服器快取
• 應用層 : 頁面靜態化
• 資料層: 分散式快取,資料庫
• 系統層: 作業系統cache
• 物理層: 磁碟cache, Raid Cache

 

1.2.1 DNS快取

瀏覽器的DNS快取預設為60秒，即60秒之內在訪問同一個域名就不在進行DNS解析

1.2.2應用層快取

• Nginx、PHP等web服務可以設定應用快取以加速響應使用者請求，另外有些解釋性語言，比如：PHP/Python/Java不能直接執行，需要先編譯成位元組碼，但位元組碼需要直譯器解釋為機器碼之後才能執行，因此位元組碼也是一種快取，有時候還會出現程式程式碼上線後位元組碼沒有更新的現象。所以一般上線新版前,需要先將應用快取清理,再上線新版。
• 另外可以利用動態頁面靜態化技術,加速訪問,比如:將訪問資料庫的資料的動態頁面,提前用程式生成靜態頁面檔案html 電商網站的商品介紹,評論資訊非實時資料等皆可利用此技術實現。

 

1.2.3資料層快取

• 分散式快取服務

　　　　Redis

　　　　Memcached

• 資料庫

　　　　MySQL 查詢快取

　　　　innodb快取、MYISAM快取

1.2.4硬體快取

• CPU快取(L1的資料快取和L1的指令快取)、二級快取、三級快取

• 磁碟快取:Disk Cache

• 磁碟陣列快取: Raid Cache,可使用電池防止斷電丟失資料

二、關係資料庫和非關係資料庫

2.1什麼是關係型資料庫

• 一個結構化的資料庫，建立在關係模型基礎上 (二維表格模型)基礎上
• 一般面向於記錄
• SQL語句(標準資料查詢語言)
• 就是一種基於關係型資料庫的語言，用於執行對關係型資料庫中資料的檢索和操作。 包括：Oracle、MySQL、SQL Server、Microsoft Access、DB2等

 

2.2什麼是非關係型資料庫

• NoSQL (NoSQL=NotOnlySQL)， 意思是“不僅僅是SQL"，是非關係型資料庫的總稱。

• 除了主流的關係型資料庫外的資料庫，都認為是非關係型。

• 主流的NoSQL資料庫有Redis、MongBD、Hbase、Memcached等。

 

2.3非關係型資料庫的產生背景

• High performance——對資料庫高併發讀寫需求

• Huge Storage——對海量資料高效儲存與訪問需求

• High Scalability && High Availability——對資料庫高可擴充套件性與高可用性需求

 

2.4關係型資料庫和非關係型資料庫區別

1）資料儲存方式不同

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

• 關係型資料天然就是表格式的，因此儲存在資料表的行和列中。資料表可以彼此關聯協作儲存，也很容易提取資料。
• 非關係型與其相反，資料不適合儲存在資料表的行和列中，而是大塊組合在一起。非關係型資料通常儲存在資料集中，就像文件、鍵值對或者圖結構。你的資料及其特性是選擇資料儲存和提取方式的首要影響因素。

關係型:依賴於關係模型E-R圖，同時以表格式的方式儲存資料 非關係型:除了以表格形式儲存之外，通常會以大塊的形式組合在一一起進行儲存資料

2）擴充套件方式不同

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

• 要支援更多併發量，SQL資料庫是縱向擴充套件，也就是說提高處理能力，使用速度更快速的計算機，這樣處理相同的資料集就更快了。因為資料儲存在關係表中，操作的效能瓶頸可能涉及很多個表，這都需要通過提高計算機效能來客服。雖然SQL資料庫有很大擴充套件空間，但最終肯定會達到縱向擴充套件的上限。
• 而NoSQL資料庫是橫向擴充套件的。因為非關係型資料儲存天然就是分散式的，NoSQL資料庫的擴充套件可以通過給資源池新增更多普通的資料庫伺服器(節點) 來分擔負載。

關係:縱向(天然表格式) 非關:橫向(天然分散式)

3） 對事務性的支援不同

如果資料操作需要高事務性或者複雜資料查詢需要控制執行計劃，那麼傳統的SQL資料庫從效能和穩定性方面考慮是最佳選擇。SQL資料庫支援對事務原子性細粒度控制，並且易於回滾事務。雖然NoSQL資料庫也可以使用事務操作，但穩定性方面沒法和關係型資料庫比較，所以它們真正閃亮的價值是在操作的擴充套件性和大資料量處理方面。

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

2.5總結

• 關係型資料庫: 例項->資料庫->表(table)->記錄行(row)、資料欄位(column)

• 非關係型資料庫: 例項->資料庫->集合(collection)–>鍵值對(key-value) 非關係型資料庫不需要手動建資料庫和集合(表)。

 

三、Redis介紹

• Redis是一個開源的、使用C語言編寫的NoSOL資料庫，Redis伺服器程式是單程序模型。
• Redis基於記憶體執行並支援持久化（支援儲存在磁碟），採用key-value（鍵值對）的儲存形式，是目前分散式架構中不可或缺的一環。
• Redis服務在一臺伺服器上可以同時啟動多個Redis程序，Redis的實際處理速度則是完全依靠於主程序的執行效率。

　　　　若在伺服器上只執行一個Redis程序， 當多個客戶端同時訪問時， 伺服器的處理能力是會有一定程度的下降;

　　　　若在同一臺伺服器上開啟 多個Redis程序， Redis在提高併發處理能力的同時會給伺服器的CPU造成很大壓力。 即在實際生產環境中， 需要根據實際的需求來決定開啟多少個Redis程序。 （一般建議開啟2個，用作備份和抗高併發）

• 若對高併發要求更高一些， 可能會考慮在同一臺伺服器上開啟多個程序。 若CPU資源比較緊張，採用單程序即可。

 

四、Redis優點

• 具有極高的資料讀寫速度：資料讀取的速度最高可達到110000次/s，資料寫入速度最高可達到81000次/s。、
• 支援豐富的資料型別:支援key-value、 Strings、Lists、Hashes ( 雜湊值)、Sets及OrderedSets等資料型別操作。 pS : string 字串(可以為整形、浮點和字元型，統稱為元素) list列表:(實現佇列，元素不唯一，先入先出原則) set 集合:(各不相同的元素) hash hash雜湊值:( hash的key必須是唯一的) set /ordered sets集合/有序集合
• 支援資料的持久化:可以將記憶體中的資料儲存在磁碟中，重啟的時候可以再次載入進行使用。
• 原子性: Redis所有 操作都是原子性的。
• 支援資料備份:即master-salve 模式的資料備份。

 

五、單執行緒

Redis 6.0版本前一直是單執行緒方式處理使用者的請求

單執行緒為何如此快?

• 純記憶體

• 非阻塞

• 避免執行緒切換和競態消耗

 

六、redis 對比 memcached

• 支援資料的持久化：可以將記憶體中的資料保持在磁碟中，重啟redis服務或者伺服器之後可以從備份檔案中恢復資料到記憶體繼續使用
• 支援更多的資料型別：支援string(字串)、hash(雜湊資料)、list(列表)、set(集合)、zset(有序集合)
• 支援資料的備份：可以實現類似於資料的master-slave模式的資料備份，另外也支援使用快照+AOF
• 支援更大的value資料：memcache單個key value最大隻支援1MB，而redis最大支援512MB(生產不建議超過2M,效能受影響)
• 在Redis6版本前,Redis 是單執行緒，而memcached是多執行緒，所以單機情況下沒有memcached 併發高,效能更好,但redis 支援分散式叢集以實現更高的併發，單Redis例項可以實現數萬併發
• 支援叢集橫向擴充套件：基於redis cluster的橫向擴充套件，可以實現分散式叢集，大幅提升效能和資料安全性
• 都是基於 C 語言開發

 

七、Redis安裝部署

7.1部署步驟

1）# 關閉防火牆和SElinux 
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
 
2）#安裝gcc gcc-c++ 編譯器
yum install -y gcc gcc-c++ make
 
3）#切換至/opt目錄，把下載好的安裝包上傳進來並解壓
cd /opt/
tar zxvf redis-5.0.7.tar.gz 
 
4）#進入目錄然後編譯安裝
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
 
#由於Redis原始碼包中直接提供了Makefile 檔案，所以在解壓完軟體包後，不用先執行./configure 進行配置，可直接執行make與make install命令進行安裝
 
5）#執行install_server.sh指令碼
cd /opt/redis-5.0.7/utils 
./install_server.sh  #一路回車，指導讓你輸入路徑這一步
#路徑需要手動輸入
Please select the redis executable path [] /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/redis/bin/redis-cli     #客戶端命令工具
 
6)#優化路徑並查埠是否開啟
#把redis的可執行程式檔案放入路徑環境變數的目錄中便於系統識別
ln -s /usr/local/redis/bin/* /usr/local/bin/
 
#當install_server.sh 指令碼執行完畢，Redis 服務就已經啟動，預設偵聽埠為6379
netstat -natp | grep redis
 
7)#修改配置檔案
vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.239.3                #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行，指定日誌文
 
8) #重啟redis檢視監聽的地址
/etc/init.d/redis_6379 restart    #重啟
ss -antp|grep redis
 
9)##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     #狀態

 

7.2Redis命令工具

1 rdb 和 aof 是redis服務中持久化功能的兩種形式
2 redis-cli常用於登陸至redis資料庫

 

7.3 redis-cli命令列工具(遠端登入)

 1 #語法: 
 2 redis-cli -h host -p port -a password
 3  
 4 #選項：
 5     -h :指定遠端主機
 6     -p :指定Redis 服務的埠號
 7     -a :指定密碼，未設定資料庫密碼可以省略-a選項
 8     -n :指定進入庫的序列號
 9 若不新增任何選項表示，則使用127.0.0.1:6379 連線本機上的 Redis 資料庫，
10  
11 #示例
12 redis-cli -h 192.168.239.3 -p 6379

 

7.4 redis-benchmark測試工具

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

1 #語法
2 redis-benchmark [選項] [選項值]

 

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

1 redis-benchmark -h 192.168.239.7 -p 6379 -c 100 -n 100000

 

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

1 redis-benchmark -h 192.168.239.7 -p 6379 -q -d 100

 

八、Redis資料庫常用命令

8.1常用命令

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

 

8.2示例

8.2.1存放、獲取資料

 

8.2.2獲取所有的key

 

8.2.3以k開頭的資料、以k開頭後面匹配—位的字元、兩位字元

 

8.2.4判斷資料是否存在

 

8.2.5刪除資料

 

8.2.6對已有key進行重新命名rename

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

 

8.2.7 renamenx

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

 

8.2.8 dbsize命令——檢視當前資料庫中key的數目

 

8.2.9 type獲取值型別

 

8.2.10設定密碼

 1 #使用config set requi repass yourpassword 命令設定密碼
 2 127.0.0.1:6379> config set requirepass 123456
 3 #使用config get requi repass命令檢視密碼(一旦設定密碼，必須先驗證通過密碼，否則所有操作不可用)
 4 127.0.0.1:6379> config get requirepass
 5 (error) NOAUTH Authentication required.
 6 127.0.0.1:6379> auth 123456
 7 OK
 8 127.0.0.1:6379> config get requirepass
 9 1) "requirepass"
10 2) "123456"

 

8.2.11 刪除密碼

1 127.0.0.1:6379> config set requirepass ''
2 #以上不設定，無法重啟redis

 

九、Redis多資料庫常用命令

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

9.1多資料庫間切換

1 命令格式: select 序號
2 使用redis-cli連線Redis資料庫後，預設使用的是序號為0的資料庫。
3 select 1            #切換至序號為10的資料庫
4 select 15             #切換至序號為15的資料庫
5 select 0            #切換至序號為0的資料庫

 

9.2多資料庫間移動資料

 1 格式:move 鍵值 序號
 2 127.0.0.1:6379> set yxp 100
 3 OK
 4 127.0.0.1:6379> get yxp
 5 "100"
 6 127 .0.0.1:6379> select 1
 7 OK
 8 127 .0.0.1:6379[1]> get yxp
 9 (nil)
10 127.0.0.1:6379[1]> select 0                    #切換至目標資料庫0
11 OK
12 127 .0.0.1:6379> move yxp 1                    #將資料庫0中A移動到資料庫1中
13 (integer) 1
14 127.0.0.1:6379> get yxp                        #在資料庫0中無法檢視到A的值
15 (nil)
16 127.0.0.1:6379> select 1                    #切換至目標資料庫1
17 OK
18 127.0.0.1:6379[1]> get yxp                    #檢視被移動資料
19 "100"

 

9.3清除資料庫內資料

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

 

十、Redis高可用

在web伺服器中，高可用是指伺服器可以正常訪問的時間，衡量的標準是在多長時間內可以提供正常服務(99.9%、 99.99%、 99.999%等等)。但是在Redis語境中， 高可用的含義似乎要寬泛一些，除了保證提供正常服務(如主從分離、快速容災技術)，還需要考慮資料容量的擴充套件，資料安全不會丟失等。

• 在Redis中，實現高可用的技術主要包括持久化、主從複製、哨兵和叢集，作用如下：
• 持久化: 持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是資料備份，即將資料儲存在硬碟，保證資料不會因程序退出而丟失。
• 主從複製 :主從複製是高可用Redis的基礎，哨兵和叢集都是在主從複製基礎上實現高可用的。主從複製主要實現了資料的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復。缺陷:故障恢復無法自動化;寫操作無法負載均衡;儲存能力受到單機的限制。
• 哨兵 :在主從複製的基礎上，哨兵實現了自動化的故障恢復。缺陷 :寫操作無法負載均衡;儲存能力受到單機的限制。
• 叢集 : 通過叢集， Redis解決了寫操作無法負載均衡，以及儲存能力受到單機限制的問題，實現了較為完善 的高可用方案。

 

十一、 Redis持久化

11.1持久化的功能:

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

11.2Redis提供兩種方式進行持久化

• RDB持久化（Redis DataBase） :原理是將Reids在記憶體中的資料庫記錄定時儲存到磁碟上。
• AOF持久化(append only file) :原理是將Reids的操作日誌以追加的方式寫入檔案，類似於MySQL的binlog。

總結：由於AOF持久化的實時性更好，即當程序意外退出時丟失的資料更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地 。

十二、RDB持久化

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

12.1觸發條件

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

①手動觸發

save命令和bgsave命令都可以生成RDB檔案。

save命令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求。

bgsave命令會建立一個子程序，由子程序來負責建立RDB檔案，父程序 (即Redis主程序) 則繼續處理請求。

bgsave命令執行過程中，只有fork 子程序時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用！！！

②自動觸發

在自動觸發RDB持久化時，Redis也 會選擇bgsave而不是save來進行持久化。

 1 #通過配置設定觸發
 2 save m n
 3 #自動觸發最常見的情況是在配置檔案中通過save m n，指定當m秒內發生n次變化時，會觸發bgsave。
 4 vim /etc/redis/6379.conf
 5  
 6 -----219行--以下三個save條件滿足任意一個時，都會引起bgsave的呼叫
 7 save 900 1 :當時間到900秒時，如果redis資料發生了至少1次變化，則執行bgsave
 8 save 300 10 :當時間到300秒時， 如果redis資料發生了至少10次變化，則執行bgsave
 9 save 60 10000 :當時間到60秒時，如果redis資料發生了至少10000次變化， 則執行bgsave
10  
11 -----242行--是否開啟RDB檔案壓縮
12 rdbcompression yes
13  
14 -----254行--指定RDB檔名
15 dbfilename dump.rdb
16  
17 -----264行--指定RDB檔案和AOF檔案所在目錄
18 dir /var/lib/redis/6379

③其他自動觸發機制

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

• 在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb檔案傳送給從節點。

• 執行shutdown命令時，自動執行rdb持久化。

 

12.2執行流程

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

 

12.3啟動時載入

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

 

十三、AOF持久化

• RDB持久化是將程序資料寫入檔案，而AOF持久化，則是將Redis執行的每次寫、刪除命令記錄到單獨的日誌檔案中，查詢操作不會記錄; 當Redis重啟時再次執行AOF檔案中的命令來恢復資料。

• 與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。

 

13.1開啟AOF

Redis伺服器預設開啟RDB，關閉AOF的， 要開啟AOF，需要在/etc/ redis/6379.conf配置檔案中配置。

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

 

重啟服務/etc/init.d/redis_6379 resstart

 

13.2執行流程

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

• 命令追加(append): 將Redis的寫命令追加到緩衝區aof_ buf;
• 檔案寫入(write)和檔案同步(sync):根據不同的同步策略將aof_buf中的內容同步到硬碟;
• 檔案重寫(rewrite): 定期重寫AOF檔案，達到壓縮的目的。

1)命令追加(append)

• Redis先將寫命令追加到緩衝區，而不是直接寫入檔案，主要是為了避免每次有寫命令都直接寫入硬碟，導致硬碟IO成為Redis負載的瓶頸。
• 命令追加的格式是Redis命令請求的協議格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點。在A0F檔案中，除了用於指定資料庫的select命令 (如select0為選中0號資料庫) 是由Redis新增的，其他都是客戶端傳送來的寫命令。

2)檔案寫入(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的預設配置，也是我們推薦的配置。

3)檔案重寫(rewrite)

• 隨著時間流逝，Redis伺服器執行的寫命令越來越多，AOF檔案也會越來越大：過大的AOF檔案不僅會影響伺服器的正常執行，也會導致資料恢復需要的時間過長。
• 檔案重寫是指定期重寫AOF檔案，減小AOF檔案的體積。需要注意的是，AOF重寫是把Redis程序內的資料轉化為寫命令，同步到新的AOF檔案；不會對舊的AOF檔案進行任何讀取、寫入操作!
• 關於檔案重寫需要注意的另一點是：對於AOF持久化來說，檔案重寫雖然是強烈推薦的，但並不是必須的；即使沒有檔案重寫，資料也可以被持久化並在Redis啟動的時候匯入：因此在一些實現中，會關閉自動的檔案重寫，然後通過定時任務在每天的某一時刻定時執行。

4)檔案重寫能壓縮AOF檔案的原因

過期的資料不再寫入檔案；

無效的命令不再寫入檔案：如有些資料被重複設值(set mykey test1, set mykey test2)、有些資料被刪除了(sadd myset vtest, del myset) 等。

多條命令可以合併為一個：如sadd myset test1, sadd myset test2， sadd myset test3可以合併為sadd myset test1 test2 test3

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

13.3檔案重寫的觸發

檔案重寫的觸發，分為手動觸發和自動觸發

①手動觸發:直接呼叫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操作。

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

 

13.4檔案重寫的流程

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

 

13.5重寫流程注意點

• 重寫由父程序fork子程序進行;

• 重寫期間Redis執行的寫命令，需要追加到新的AOF檔案中，為此Redis引入了aof_ rewrite_buf快取。

 

13.6啟動時載入

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

 

十四、RDB和AOF的優缺點

14.1 RDB持久化的優缺點

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

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

14.2AOF持久化的優缺點

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

 

十五、Redis效能管理

15.1、檢視Redis記憶體使用

 

15.2、記憶體碎片率

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

 

15.3、跟蹤記憶體碎片率

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

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

 

15.4、記憶體使用率

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

避免記憶體交換髮生的方法： ● 針對快取資料大小選擇安裝Redis 例項 ● 儘可能的使用Hash資料結構儲存 ● 設定key的過期時間

 

15.5、內回收key

保證合理分配redis有限的記憶體資源。

當達到設定的最大閥值時，需選擇一種key的回收策略，預設情況下回收策略是禁止刪除。 配置檔案中修改maxmemory- policy屬性值：

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