目錄： 1、關係型資料庫與非關係型　 　　關係型資料庫 　　非關係型資料庫 　　關係型與非關係型資料庫區別 2、Redis 　　概述 　　特性 　　優點 　　Redis安裝部署 　　Redis命令工具 　　Redis資料庫常用命令 　　Redis高可用 　　Redis持久化 　　　　RDB持久化 　　　　AOF持久化 　　小結 　　Redis效能管理 　　　　記憶體碎片率 　　　　記憶體使用率 　　　　回收key

關係型資料庫與非關係型：

非關係型資料庫產生的背景： High performance 對資料庫高併發讀寫需求 Huge Storrge 對海量資料高效儲存與訪問需求 HighScalability &&High Availability 對資料庫高可擴充套件性與高可用性需求   關係型資料庫和非關係型資料庫都有各自的特點與應用場景，兩者的緊密結合將會給Web2.0的資料庫發展帶來新的思路。讓關係資料庫關注在關係上，非關係型資料庫關注在儲存上。例如，在讀寫分離的MySQL資料庫環境中，可以把經常訪問的資料儲存在非關係型資料庫中，提升訪問速度。 Mysql 高熱資料——》redis web—》redis—》mysql CPU——》記憶體/快取—》磁碟   資料庫主要分為兩大類：關係型資料庫與 NoSQL 資料庫。 非關係型資料庫不需要手動建資料庫和集合(表)。  

關係型資料庫：

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

非關係型資料庫

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

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

(1)、資料儲存方式不同 關係型和非關係型資料庫的主要差異是資料儲存的方式。關係型資料天然就是表格式的，因此儲存在資料表的行和列中。資料表可以彼此關聯協作儲存，也很容易提取資料。 與其相反，非關係型資料不適合儲存在資料表的行和列中，而是大塊組合在一起。非關係型資料通常儲存在資料集中，就像文件、鍵值對或者圖結構。你的資料及其特性是選擇資料儲存和提取方式的首要影響因素。 ① 關係型：依賴於關係模型E-R圖，同時以表格式的方式儲存資料 ② 非關係型：除了以表格形式儲存之外，通常會以大塊的形式組合在一起進行儲存資料   (2)、擴充套件方式不同 SQL和NoSQL資料庫最大的差別可能是在擴充套件方式上，要支援日益增長的需求當然要擴充套件。 要支援更多併發量，SQL資料庫是縱向擴充套件，也就是說提高處理能力，使用速度更快速的計算機，這樣處理相同的資料集就更快了。因為資料儲存在關係表中，操作的效能瓶頸可能涉及很多個表，這都需要通過提高計算機效能來克服。雖然SQL資料庫有很大擴充套件空間，但最終肯定會達到縱向擴充套件的上限。 而NoSQL資料庫是橫向擴充套件的。因為非關係型資料儲存天然就是分散式的，NoSQL資料庫的擴充套件可以通過給資源池新增更多普通的資料庫伺服器 (節點) 來分擔負載。 ① 關係：縱向（天然表格式） ② 非關：橫向（天然分散式）   (3)、對事務性的支援不同 如果資料操作需要高事務性或者複雜資料查詢需要控制執行計劃，那麼傳統的SQL資料庫從效能和穩定性方面考慮是最佳選擇。SQL資料庫支援對事務原子性細粒度控制，並且易於回滾事務。 雖然NoSQL資料庫也可以使用事務操作，但穩定性方面沒法和關係型資料庫比較，所以它們真正閃亮的價值是在操作的擴充套件性和大資料量處理方面。 ① 關係型：特別適合高事務性要求和需要控制執行計劃的任務 ② 非關係：此處會稍顯弱勢，其價值點在於高擴充套件性和大資料量處理方面   關係型資料庫：例項–>資料庫–>表(table)–>記錄行(row)、資料欄位(column)——》儲存資料 非關係型資料庫：例項–>資料庫–>集合(collection) -->鍵值對(key-value) workdir=/usr/local/mysql   非關係資料庫 1、資料儲存在快取中，利於讀取速度/查詢資料 2、架構中位置靈活 3、分散式、擴充套件性高 關係資料庫 1、安全性高（持久化） 2、事務處理能力強 3、任務控制能力強 4、可以做日誌備份、恢復、容災的能力更強一點。  

Redis

概述：

Redis是一個開源的、遵循BSD協議的、基於記憶體的而且目前比較流行的鍵值資料庫(key-value database)，是一個非關係型資料庫，redis 提供將記憶體通過網路遠端共享的一種服務，提供類似功能的 還有memcached，但相比memcached，redis還提供了易擴充套件、高效能、具備資料永續性等功能。   Redis（遠端字典伺服器） 是一個開源的、使用 C 語言編寫的 NoSQL 資料庫。 Redis 基於記憶體執行並支援持久化，採用key-value（鍵值對）的儲存形式，是目前分散式架構中不可或缺的一環。Redis伺服器程式是單程序模型，也就是在一臺伺服器上可以同時啟動多個Redis程序，Redis的實際處理速度則是完全依靠於主程序的執行效率。若在伺服器上只執行一個Redis程序，當多個客戶端同時訪問時，伺服器的處理能力是會有一定程度的下降；若在同一臺伺服器上開啟多個Redis程序，Redis在提高併發處理能力的同時會給伺服器的CPU造成很大壓力。即：在實際生產環境中，需要根據實際的需求來決定開啟多少個Redis程序。若對高併發要求更高一些，可能會考慮在同一臺伺服器上開啟多個程序。若CPU資源比較緊張，採用單程序即可。  

特性：

速度快: 10W QPS,基於記憶體,C語言實現 單執行緒 持久化 支援多種資料結構 支援多種程式語言 功能豐富: 支援Lua指令碼,釋出訂閱,事務,pipeline等功能 簡單: 程式碼短小精悍(單機核心程式碼只有23000行左右),單執行緒開發容易,不依賴外部庫,使用簡單 主從複製 支援高可用和分散式  

優點：

（1）具有極高的資料讀寫速度：資料讀取的速度最高可達到 110000 次/s，資料寫入速度最高可達到 81000 次/s。 （2）支援豐富的資料型別：支援 key-value、Strings、Lists、Hashes、Sets 及 Sorted Sets 等資料型別操作。 （3）支援資料的持久化：可以將記憶體中的資料儲存在磁碟中，重啟的時候可以再次載入進行使用。 （4）原子性：Redis 所有操作都是原子性的。 （5）支援資料備份：即 master-salve 模式的資料備份。 Redis作為基於記憶體執行的資料庫，快取是其最常應用的場景之一。除此之外，Redis常見應用場景還包括獲取最新N個數據的操作、排行榜類應用、計數器應用、儲存關係、實時分析系統、日誌記錄。   Redis為什麼這麼快 1、Redis是一款純記憶體結構，避免了磁碟I/o等耗時操作。 2、Redis命令處理的核心模組為單執行緒，減少了鎖競爭，以及頻繁建立執行緒和銷燬執行緒的代價，減少了執行緒上下文切換的消耗。 3、採用了 I/O 多路複用機制，大大提升了併發效率 注：在 Redis 6.0 中新增加的多執行緒也只是針對處理網路請求過程採用了多線性，而資料的讀寫命令，仍然是單執行緒處理的   // TSDB時序資料庫： //  

Redis 安裝部署

systemctl stop firewalld setenforce 0   yum install -y gcc gcc-c++ make   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 命令進行安裝。   #執行軟體包提供的 install_server.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 #客戶端命令工具 ----------------------------------------------------------------------------------------------------------   #把redis的可執行程式檔案放入路徑環境變數的目錄中便於系統識別 ln -s /usr/local/redis/bin/* /usr/local/bin/   #當 install_server.sh 指令碼執行完畢，Redis 服務就已經啟動，預設監聽埠為 6379 netstat -natp | grep redis   #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 #狀態   #修改配置 /etc/redis/6379.conf 引數 vim /etc/redis/6379.conf bind 127.0.0.1 192.168.63.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    

Redis 命令工具

redis-server：用於啟動 Redis 的工具 redis-benchmark：用於檢測 Redis 在本機的執行效率 redis-check-aof：修復 AOF 持久化檔案 redis-check-rdb：修復 RDB 持久化檔案 redis-cli：Redis 命令列工具     redis-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.63.100 -p 6379   redis-benchmark 測試工具 redis-benchmark 是官方自帶的 Redis 效能測試工具，可以有效的測試 Redis 服務的效能。 基本的測試語法：redis-benchmark [選項] [選項值]。 -h ：指定伺服器主機名。 -p ：指定伺服器埠。 -s ：指定伺服器 socket -c ：指定併發連線數。  -n ：指定請求數。 -d ：以位元組的形式指定 SET/GET 值的資料大小。 -k ：1=keep alive 0=reconnect 。 -r ：SET/GET/INCR 使用隨機 key, SADD 使用隨機值。 -P ：通過管道傳輸請求。 -q ：強制退出 redis。僅顯示 query/sec 值。 --csv ：以 CSV 格式輸出。 -l ：生成迴圈，永久執行測試。 -t ：僅執行以逗號分隔的測試命令列表。 -I ：Idle 模式。僅開啟 N 個 idle 連線並等待。   #向 IP 地址為 192.168.63.100、埠為 6379 的 Redis 伺服器傳送 100 個併發連線與 100000 個請求測試效能 redis-benchmark -h 192.168.63.100 -p 6379 -c 100 -n 100000   #測試存取大小為 100 位元組的資料包的效能 redis-benchmark -h 192.168.63.100 -p 6379 -q -d 100   #測試本機上 Redis 服務在進行 set 與 lpush 操作時的效能 redis-benchmark -t set,lpush -n 100000 -q    

Redis 資料庫常用命令

set：存放資料，命令格式為 set key value get：獲取資料，命令格式為 get key   127.0.0.1:6379> set teacher zhangsan OK 127.0.0.1:6379> get teacher "zhangsan"   # keys 命令可以取符合規則的鍵值列表，通常情況可以結合*、？等選項來使用。 127.0.0.1:6379> set k1 1 127.0.0.1:6379> set k2 2 127.0.0.1:6379> set k3 3 127.0.0.1:6379> set v1 4 127.0.0.1:6379> set v5 5 127.0.0.1:6379> set v22 5   127.0.0.1:6379> KEYS * #檢視當前資料庫中所有鍵   127.0.0.1:6379> KEYS v* #檢視當前資料庫中以 v 開頭的資料   127.0.0.1:6379> KEYS v? #檢視當前資料庫中以 v 開頭後面包含任意一位的資料   127.0.0.1:6379> KEYS v?? #檢視當前資料庫中以 v 開頭 v 開頭後面包含任意兩位的資料   # exists 命令可以判斷鍵值是否存在。 127.0.0.1:6379> exists teacher #判斷 teacher 鍵是否存在 (integer) 1 # 1 表示 teacher 鍵是存在 127.0.0.1:6379> exists tea (integer) 0 # 0 表示 tea 鍵不存在   # del 命令可以刪除當前資料庫的指定 key。 127.0.0.1:6379> keys * 127.0.0.1:6379> del v5 127.0.0.1:6379> get v5   # type 命令可以獲取 key 對應的 value 值型別。 127.0.0.1:6379> type k1 string   # rename 命令是對已有 key 進行重新命名。（覆蓋） 命令格式：rename 源key 目標key 使用rename命令進行重新命名時，無論目標key是否存在都進行重新命名，且源key的值會覆蓋目標key的值。在實際使用過程中，建議先用 exists 命令檢視目標 key 是否存在，然後再決定是否執行 rename 命令，以避免覆蓋重要資料。   127.0.0.1:6379> keys v* 1) "v1" 2) "v22" 127.0.0.1:6379> rename v22 v2 OK 127.0.0.1:6379> keys v* 1) "v1" 2) "v2" 127.0.0.1:6379> get v1 "4" 127.0.0.1:6379> get v2 "5" 127.0.0.1:6379> rename v1 v2 OK 127.0.0.1:6379> get v1 (nil) 127.0.0.1:6379> get v2 "4"   # renamenx 命令的作用是對已有 key 進行重新命名，並檢測新名是否存在，如果目標 key 存在則不進行重新命名。（不覆蓋） 命令格式：renamenx 源key 目標key 127.0.0.1:6379> keys * 127.0.0.1:6379> get teacher "zhangsan" 127.0.0.1:6379> get v2 "4" 127.0.0.1:6379> renamenx v2 teacher (integer) 0 127.0.0.1:6379> keys * 127.0.0.1:6379> get teacher "zhangsan" 127.0.0.1:6379> get v2 "4"   # dbsize 命令的作用是檢視當前資料庫中 key 的數目。 127.0.0.1:6379> dbsize     #使用config set requirepass yourpassword命令設定密碼 127.0.0.1:6379> config set requirepass 123456   #使用config get requirepass命令檢視密碼（一旦設定密碼，必須先驗證通過密碼，否則所有操作不可用） 127.0.0.1:6379> auth 123456 127.0.0.1:6379> config get requirepass     Redis 多資料庫常用命令 Redis 支援多資料庫，Redis 預設情況下包含 16 個數據庫，資料庫名稱是用數字 0-15 來依次命名的。 多資料庫相互獨立，互不干擾。   #多資料庫間切換 命令格式：select 序號 使用 redis-cli 連線 Redis 資料庫後，預設使用的是序號為 0 的資料庫。   127.0.0.1:6379> select 10 #切換至序號為 10 的資料庫   127.0.0.1:6379[10]> select 15 #切換至序號為 15 的資料庫   127.0.0.1:6379[15]> select 0 #切換至序號為 0 的資料庫   #多資料庫間移動資料 格式：move 鍵值 序號   127.0.0.1:6379> set k1 100 OK 127.0.0.1:6379> get k1 "100" 127.0.0.1:6379> select 1 OK 127.0.0.1:6379[1]> get k1 (nil) 127.0.0.1:6379[1]> select 0 #切換至目標資料庫 0 OK 127.0.0.1:6379> get k1 #檢視目標資料是否存在 "100" 127.0.0.1:6379> move k1 1 #將資料庫 0 中 k1 移動到資料庫 1 中 (integer) 1 127.0.0.1:6379> select 1 #切換至目標資料庫 1 OK 127.0.0.1:6379[1]> get k1 #檢視被移動資料 "100" 127.0.0.1:6379[1]> select 0 OK 127.0.0.1:6379> get k1 #在資料庫 0 中無法檢視到 k1 的值 (nil)   #清除資料庫內資料 FLUSHDB ：清空當前資料庫資料 FLUSHALL ：清空所有資料庫的資料，慎用！  

Redis高可用

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

Redis持久化

持久化的功能：Redis是記憶體資料庫，資料都是儲存在記憶體中，為了避免伺服器斷電等原因導致Redis程序異常退出後資料的永久丟失，需要定期將Redis中的資料以某種形式（資料或命令）從記憶體儲存到硬碟；當下次Redis重啟時，利用持久化檔案實現資料恢復。除此之外，為了進行災難備份，可以將持久化檔案拷貝到一個遠端位置。 Redis 提供兩種方式進行持久化： ●RDB 持久化：原理是將 Reids在記憶體中的資料庫記錄定時儲存到磁碟上。 ●AOF 持久化（append only file）：原理是將 Reids 的操作日誌以追加的方式寫入檔案，類似於MySQL的binlog。 由於AOF持久化的實時性更好，即當程序意外退出時丟失的資料更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地  

RDB持久化

RDB持久化是指在指定的時間間隔內將記憶體中當前程序中的資料生成快照儲存到硬碟(因此也稱作快照持久化)，用二進位制壓縮儲存，儲存的檔案字尾是rdb；當Redis重新啟動時，可以讀取快照檔案恢復資料。     1. 觸發條件 RDB持久化的觸發分為手動觸發和自動觸發兩種。   （1）手動觸發 save命令和bgsave命令都可以生成RDB檔案。 save命令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求。 而bgsave命令會建立一個子程序，由子程序來負責建立RDB檔案，父程序(即Redis主程序)則繼續處理請求。   bgsave命令執行過程中，只有fork子程序時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用。   （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 --254行--指定RDB檔名 dbfilename dump.rdb --264行--指定RDB檔案和AOF檔案所在目錄 dir /var/lib/redis/6379 --242行--是否開啟RDB檔案壓縮 rdbcompression yes   ##其他自動觸發機制## 除了save m n 以外，還有一些其他情況會觸發bgsave： ●在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb檔案傳送給從節點。 ●執行shutdown命令時，自動執行rdb持久化。     2. 執行流程   （1）Redis父程序首先判斷：當前是否在執行save，或bgsave/bgrewriteaof的子程序，如果在執行則bgsave命令直接返回。 bgsave/bgrewriteaof的子程序不能同時執行，主要是基於效能方面的考慮：兩個併發的子程序同時執行大量的磁碟寫操作，可能引起嚴重的效能問題。 （2）父程序執行fork操作建立子程序，這個過程中父程序是阻塞的，Redis不能執行來自客戶端的任何命令 （3）父程序fork後，bgsave命令返回”Background saving started”資訊並不再阻塞父程序，並可以響應其他命令 （4）子程序建立RDB檔案，根據父程序記憶體快照生成臨時快照檔案，完成後對原有檔案進行原子替換 （5）子程序傳送訊號給父程序表示完成，父程序更新統計資訊   3. 啟動時載入 RDB檔案的載入工作是在伺服器啟動時自動執行的，並沒有專門的命令。但是由於AOF的優先順序更高，因此當AOF開啟時，Redis會優先載入 AOF檔案來恢復資料；只有當AOF關閉時，才會在Redis伺服器啟動時檢測RDB檔案，並自動載入。伺服器載入RDB檔案期間處於阻塞狀態，直到載入完成為止。 Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。   RDB的優缺和優點： 缺點： 1、資料完成性不如aof 2、RDB類似於快照(完備) 3、在進行備份時，會阻塞程序 優勢： 1、持久化的速度快(因為儲存的是資料結果)，在寫入到*.rdb持久化檔案，會進行壓縮，來減小自身的體積 2、叢集中，redis主從服務，從→主伺服器進行同步，預設會優先使用RBD檔案進行恢復操作，所以同步性比較高  

AOF 持久化

RDB持久化是將程序資料寫入檔案，而AOF持久化，則是將Redis執行的每次寫、刪除命令記錄到單獨的日誌檔案中，查詢操作不會記錄； 當Redis重啟時再次執行AOF檔案中的命令來恢復資料。 與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。   1. 開啟AOF Redis伺服器預設開啟RDB，關閉AOF；要開啟AOF，需要在配置檔案中配置： vim /etc/redis/6379.conf --700行--修改，開啟AOF appendonly yes --704行--指定AOF檔名稱 appendfilename "appendonly.aof" --796行--是否忽略最後一條可能存在問題的指令 aof-load-truncated yes     /etc/init.d/redis_6379 restart   2. 執行流程 由於需要記錄Redis的每條寫命令，因此AOF不需要觸發，下面介紹AOF的執行流程。 AOF的執行流程包括： ●命令追加(append)：將Redis的寫命令追加到緩衝區aof_buf； ●檔案寫入(write)和檔案同步(sync)：根據不同的同步策略將aof_buf中的內容同步到硬碟； ●檔案重寫(rewrite)：定期重寫AOF檔案，達到壓縮的目的。   （1）命令追加(append) abc qijiam 記憶體 Redis先將寫命令追加到緩衝區，而不是直接寫入檔案，主要是為了避免每次有寫命令都直接寫入硬碟，導致硬碟IO成為Redis負載的瓶頸。 命令追加的格式是Redis命令請求的協議格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點。在AOF檔案中，除了用於指定資料庫的select命令（如select 0為選中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秒。這種情況下，檔案同步的時間不可控，且緩衝區中堆積的資料會很多，資料安全性無法保證。   ●appendfsync 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)、有些資料被刪除了(set 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 ：當前AOF檔案執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由於檔案尺寸較小導致頻繁的BGREWRITEAOF     關於檔案重寫的流程，有兩點需要特別注意：(1)重寫由父程序fork子程序進行；(2)重寫期間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策略同步到硬碟，保證原有AOF機制的正確。 （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重寫。   3. 啟動時載入 當AOF開啟時，Redis啟動時會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會載入RDB檔案恢復資料。 當AOF開啟，但AOF檔案不存在時，即使RDB檔案存在也不會載入。 Redis載入AOF檔案時，會對AOF檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。但如果是AOF檔案結尾不完整(機器突然宕機等容易導致檔案尾部不完整)，且aof-load-truncated引數開啟，則日誌中會輸出警告，Redis忽略掉AOF檔案的尾部，啟動成功。aof-load-truncated引數預設是開啟的。     RDB和AOF的優缺點 ●RDB持久化 優點：RDB檔案緊湊，體積小，網路傳輸快，適合全量複製；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對效能的影響相對較小。   缺點：RDB檔案的致命缺點在於其資料快照的持久化方式決定了必然做不到實時持久化，而在資料越來越重要的今天，資料的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB檔案需要滿足特定格式，相容性差（如老版本的Redis不相容新版本的RDB檔案）。 對於RDB持久化，一方面是bgsave在進行fork操作時Redis主程序會阻塞，另一方面，子程序向硬碟寫資料也會帶來IO壓力。   ●AOF持久化 與RDB持久化相對應，AOF的優點在於支援秒級持久化、相容性好，缺點是檔案大、恢復速度慢、對效能影響大。 對於AOF持久化，向硬碟寫資料的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題。 AOF檔案的重寫與RDB的bgsave類似，會有fork時的阻塞和子程序的IO壓力問題。相對來說，由於AOF向硬碟中寫資料的頻率更高，因此對 Redis主程序效能的影響會更大。  

小結：

Redis的持久化 1、RDB和AOF的基本理解 ①RDB：週期性的把記憶體中的資料儲存在磁碟中 ②AOF：從redis的操作日誌記錄中執行的過程同步到磁碟中   2、RDB和AOF的持久化過程： RDB:1）記憶體中→寫入到磁碟中儲存方式 2）結果資料→寫入磁碟中儲存資料物件 3）記憶體→寫入磁碟後，會進行壓縮，來減少*.rdb的磁碟中佔用空間量 AOF:1)記憶體→append追加到快取中→呼叫CPU資源來寫入磁碟中 2）操作日誌記錄的執行語句→追加到緩衝區→呼叫CPU來寫入磁碟 3）記憶體→快取→磁碟，寫入後，會週期性的進行重寫，來跳過一些“無效操作”來儲存   3、RDB和AOF的觸發方式 RDB分為 ①手動觸發 ②自動觸發 save m n（save 900 60則表示900s內有60次操作，則觸發RDB持久化） ③特殊觸發：當手動關閉redis時，/etc/init.d/redis_6379 stop|start shutdown 關閉時 ##kill不會觸發 AOF①手動觸發 ②自動觸發 1）always 每條語句，同步執行持久化（有強一致性的要求場景） 2）NO 不進行持久化 3）every second每秒都進行一次AOF持久化（建議使用，均衡型的場景）   4、RDB和AOF的優先順序 前提①因為redis預設是將資料儲存在記憶體中，所以若reids重啟，關閉時記憶體中的資料會丟失 ②在redis每次啟動時，都會讀取持久化的檔案，來恢復資料到記憶體中，以保證reids資料的完整性   RDB和AOF的優先順序 AOF大於RDB 5、redis的配置檔案 6379.conf 課可以指定啟動 ./redis-server /etc/redis/6479.conf   注意1個問題 aof-load-truncated yes #是否忽略最後一條可能存在的 詳解：AOF每秒同步一次 比如我有三條資料 1、setname abc 2、qwe test 3、move qwe   every second每秒進行 也就是說在一秒鐘 執行三條語句，我在同步的到第二條語句的時候第三條資料沒有儲存進行，或者說儲存一半redis掛了，那我第三條資料是不是錯誤的資料，也就是我執行到2.5的資料就GG了，我的第三條資料是不是錯的，如果啟動會報錯，也就是終止  

Reids效能管理

檢視Redis記憶體使用 192.168.9.236:7001> info memory  

記憶體碎片率

作業系統分配的記憶體值 used_memory_rss 除以 Redis 使用的記憶體總量值 used_memory 計算得出。 記憶體值 used_memory_rss 表示該程序所佔實體記憶體的大小，即為作業系統分配給 Redis 例項的記憶體大小。 除了使用者定義的資料和內部開銷以外，used_memory_rss 指標還包含了記憶體碎片的開銷， 記憶體碎片是由作業系統低效的分配/回收物理記憶體導致的（不連續的實體記憶體分配）。 舉例來說：Redis 需要分配連續記憶體塊來儲存 1G 的資料集。如果實體記憶體上沒有超過 1G 的連續記憶體塊， 那作業系統就不得不使用多個不連續的小記憶體塊來分配並存儲這 1G 資料，該操作就會導致記憶體碎片的產生。 #跟蹤記憶體碎片率對理解Redis例項的資源效能是非常重要的： ●記憶體碎片率稍大於1是合理的，這個值表示記憶體碎片率比較低，也說明 Redis 沒有發生記憶體交換。 ●記憶體碎片率超過1.5，說明Redis消耗了實際需要實體記憶體的150%，其中50%是記憶體碎片率。需要在redis-cli工具上輸入shutdown save 命令，讓 Redis 資料庫執行儲存操作並關閉 Redis 服務，再重啟伺服器。 ●記憶體碎片率低於1的，說明Redis記憶體分配超出了實體記憶體，作業系統正在進行記憶體交換。需要增加可用實體記憶體或減少 Redis 記憶體佔用。  

記憶體使用率

redis例項的記憶體使用率超過可用最大記憶體，作業系統將開始進行記憶體與swap空間交換。 #避免記憶體交換髮生的方法： ●針對快取資料大小選擇安裝 Redis 例項 ●儘可能的使用Hash資料結構儲存 ●設定key的過期時間  

回收key

記憶體清理策略，保證合理分配redis有限的記憶體資源。 當達到設定的最大閥值時，需選擇一種key的回收策略，預設情況下回收策略是禁止刪除。 配置檔案中修改 maxmemory-policy 屬性值： vim /etc/redis/6379.conf 598 maxmemory-policy noenviction ●volatile-lru：使用LRU演算法從已設定過期時間的資料集合中淘汰資料(移除最近最少使用的key，針對設定了TTL的key) ●volatile-ttl：從已設定過期時間的資料集合中挑選即將過期的資料淘汰（移除最近過期的key） ●volatile-random：從已設定過期時間的資料集合中隨機挑選資料淘汰（在設定了TTL的key裡隨機移除） ●allkeys-lru：使用LRU演算法從所有資料集合中淘汰資料（移除最少使用的key，針對所有的key） ●allkeys-random：從資料集合中任意選擇資料淘汰（隨機移除key） ●noenviction：禁止淘汰資料（不刪除直到寫滿時報錯）