redis學習——目錄

其餘更多java基礎文章：
java基礎學習(目錄)

---

這一系列主要是針對慕課網的redis實戰寫的一個覆盤文章，對視頻內容進行一次整理和輸出。在整理輸出找資料的過程當中，發現了一個也是慕課網系列的整理文章，以爲還挺不錯的。

高可用Redis(一)：通用命令，數據結構和內部編碼，單線程架構
高可用Redis(二)：字符串類型
高可用Redis(三)：Hash類型
高可用Redis(四)：列表，集合與有序集合
高可用Redis(五)：瑞士軍刀之慢查詢，Pipeline和發佈訂閱
高可用Redis(六)：瑞士軍刀之bitmap，HyperLoglog和GEO
高可用Redis(七)：Redis持久化
高可用Redis(八)：Redis主從複製
高可用Redis(九)：Redis Sentinel
高可用Redis(十)：Redis原生命令搭建集羣
高可用Redis(十一)：使用redis-trib.rb工具搭建集羣
高可用Redis(十二)：Redis Cluster
高可用Redis(十三)：Redis緩存的使用和設計

總結

RBD

RDB持久化功能能夠將Redis中全部數據生成快照並以二進行文件的形式保存到硬盤裏，文件名爲.RDB文件。

在Redis啓動時載入RDB文件，Redis讀取RDB文件內容，還原服務器原有的數據庫數據

RBD的三種方式

1. 使用SAVE命令手動同步建立RDB文件

客戶端向Redis服務端發送SAVE命令，服務端把當前全部的數據同步保存爲一個RDB文件 經過向服務器發送SAVE命令，Redis會建立一個新的RDB文件。在執行SAVE命令的過程當中(也就是即時建立RDB文件的過程當中),Redis服務端將被阻塞，沒法處理客戶端發送的其餘命令請求。

2. 使用BGSAVE命令異步建立RDB文件

BGSAVE不會形成redis服務器阻塞：在執行BGSAVE命令的過程當中，Redis服務端仍然能夠正常的處理其餘的命令請求。Redis服務端經過fork()來生成一個名叫redis-rdb-bgsave的進程，由redis-rdb-bgsave子進程來建立RDB文件，而Redis主進程則繼續處理客戶端的命令請求。

BGSAVE是一個異步命令，Redis客戶端向Redis服務端發送BGSAVE命令後會當即獲得回覆，而實際的操做在Redis服務端回覆以後纔開始

3. 自動建立RDB文件

打開Redis的配置文件/etc/redis.conf

save 900 1
save 300 10
save 60 10000
複製代碼

自動持久化配置解釋：

save 900 1表示：若是距離上一次建立RDB文件已通過去的900秒時間內，Redis中的數據發生了1次改動，則自動執行BGSAVE命令
save 300 10表示：若是距離上一次建立RDB文件已通過去的300秒時間內，Redis中的數據發生了10次改動，則自動執行BGSAVE命令
save 60 10000表示：若是距離上一次建立RDB文件已通過去了60秒時間內，Redis中的數據發生了10000次改動，則自動執行BGSAVE命令
複製代碼

當三個條件中的任意一個條件被知足時，Redis就會自動執行BGSAVE命令

RDB現存問題

1. 耗時耗性能

Redis把內存中的數據dump到硬盤中生成RDB文件，首先要把全部的數據都進行持久化，所須要的時間複雜度爲O(N)，同時把數據dump到文件中，也須要消耗CPU資源， 因爲BGSAVE命令有一個fork子進程的過程，雖然不是完整的內存拷貝，而是基於copy-on-write的策略，可是若是Redis中的數據很是多，佔用的內存頁也會很是大，fork子進程時消耗的內存資源也會不少 磁盤IO性能的消耗，生成RDB文件原本就是把內存中的數據保存到硬盤當中，若是生成的RDB文件很是大，保存到硬盤的過程當中消耗很是多的硬盤IO

2. 不可控，丟失數據

自動建立RDB文件的過程當中，在上一次建立RDB文件之後，又向Redis中寫入多條數據，若是此時Redis服務中止，則從上一次建立RDB文件到Redis服務掛機這個時間段內的數據就丟失了

AOF(AppendOnlyFile)方式

AOF持久化保存數據庫的方法是：每當有修改的數據庫的命令被執行時，服務器就會將執行的命令寫入到AOF文件的末尾。

由於AOF文件裏面儲存了服務器執行過的全部數據庫修改的命令，因此Redis只要從新執行一遍AOF文件裏面保存的命令，就能夠達到還原數據庫的目的

AOF三種策略

爲了控制Redis服務器在遇到意外停機時丟失的數據量，Redis爲AOF持久化提供了appendfsync選項，這個選項的值能夠是always,everysec或者no

• Always

Redis每寫入一個命令，always會把每條命令都刷新到硬盤的緩衝區當中而後將緩衝區裏的數據寫入到硬盤裏。 這種模式下，Redis即便用遭遇意外停機，也不會丟失任何本身已經成功執行的數據

• Everysec

Redis每一秒調用一次fdatasync,將緩衝區裏的命令寫入到硬盤裏， 這種模式下，當Redis的數據交換不少的時候能夠保護硬盤 即便Redis遭遇意外停機時，最多隻丟失一秒鐘內的執行的數據

• No

服務器不主動調用fdatasync,由操做系統決定任何將緩衝區裏面的命令寫入到硬盤裏，這種模式下，服務器遭遇意外停機時，丟失的命令的數量是不肯定的

AOF三種方式比較

運行速度：always的速度慢，everysec和no都很快

• always不丟失數據，可是硬盤IO開銷不少，通常的SATA硬盤一秒種只能寫入幾百次數據
• everysec每秒同步一次數據，若是Redis發生故障，可能會丟失1秒鐘的數據
• no則系統控制，不可控，不知道會丟失多少數據

AOF重寫功能簡介

隨着服務器的不斷運行，爲了記錄Redis中數據的變化，Redis會將愈來愈多的命令寫入到AOF文件中，使得AOF文件的體積來斷增大。 爲了讓AOF文件的大小控制在合理的範圍，redis提供了AOF重寫功能，經過這個功能，服務器能夠產生一個新的AOF文件。

新的AOF文件記錄的數據庫數據和原有AOF文件記錄的數據庫數據徹底同樣
新的AOF文件會使用盡量少的命令來記錄數據庫數據，所以新的AOF文件的體積一般會比原有AOF文件的體積要小得多
AOF重寫期間，服務器不會被阻塞，能夠正常處理客戶端發送的命令請求

經過配置選項自動執行BGREWRITEAOF命令

• auto-aof-rewrite-min-size

觸發AOF重寫所需的最小體積：只要在AOF文件的大小超過設定的size時，Redis會進行AOF重寫，這個選項用於避免對體積太小的AOF文件進行重寫

• auto-aof-rewrite-percentage

指定觸發重寫所需的AOF文件體積百分比：當AOF文件的體積大於auto-aof-rewrite-min-size指定的體積，而且超過上一次重寫以後的AOF文件體積的percent%時，就會觸發AOF重寫，若是服務器剛啓動不久，尚未進行過AOF重寫，那麼使用服務器啓動時載入的AOF文件的體積來做爲基準值。
將這個值設置爲0表示關閉自動AOF重寫功能

只有當上面兩個條件同時知足時纔會觸發Redis的AOF重寫功能