一、關系型資料庫與非關系型資料庫概述

1、關系型資料庫

（1）關系型資料庫是一個結構化的資料庫，創建在關系模型（二維表格模型）基礎上，一般面向于記錄，
（2）SQL 陳述句（標準資料查詢語言）就是一種基于關系型資料庫的語言，用于執行對關系型資料庫中資料的檢索和操作，
注：主流的關系型資料庫包括 Oracle、MySQL、SQL Server、Microsoft Access、DB2 等，

2、非關系型資料庫

（1）NoSQL(NoSQL = Not Only SQL )，意思是“不僅僅是 SQL”，是非關系型資料庫的總稱，
（2）除了主流的關系型資料庫外的資料庫，都認為是非關系型，
注：主流的 NoSQL 資料庫有 Redis、MongBD、Hbase、CouhDB 等，

二、關系資料庫與非關系型資料庫區別

1、資料儲存方式不同

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

2、擴展方式不同

SQL和NoSQL資料庫最大的差別可能是在擴展方式上，要支持日益增長的需求當然要擴展，
要支持更多并發量，SQL資料庫是縱向擴展，也就是說提高處理能力，使用速度更快速的計算機，這樣處理相同的資料集就更快了，因為資料存盤在關系表中，操作的性能瓶頸可能涉及很多個表，這都需要通過提高計算機性能來客服，雖然SQL資料庫有很大擴展空間，但最終肯定會達到縱向擴展的上限，
而NoSQL資料庫是橫向擴展的，因為非關系型資料存盤天然就是分布式的，NoSQL資料庫的擴展可以通過給資源池添加更多普通的資料庫服務器(節點)來分擔負載，

3、對事務性的支持不同

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

三、非關系型資料庫

可用于應對 Web2.0 純動態網站型別的三高問題，
（1）High performance——對資料庫高并發讀寫需求
（2）Huge Storage——對海量資料高效存盤與訪問需求
（3）High Scalability && High Availability——對資料庫高可擴展性與高可用性需求
關系型資料庫和非關系型資料庫都有各自的特點與應用場景，兩者的緊密結合將會給Web2.0的資料庫發展帶來新的思路，讓關系資料庫關注在關系上，非關系型資料庫關注在存盤上，例如，在讀寫分離的MySQL資料庫環境中,可以把經常訪問的資料存盤在非關系型資料庫中，提升訪問速度，
總結：
關系型資料庫：
實體–>資料庫–>表(table)–>記錄行(row)、資料欄位(column)
非關系型資料庫：
實體–>資料庫–>集合(collection)–>鍵值對(key-value)
非關系型資料庫不需要手動建資料庫和集合（表），

四、Redis簡介

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

1、Redis 優點

（1）具有極高的資料讀寫速度：資料讀取的速度最高可達到 110000 次/s，資料寫入速度最高可達到 81000 次/s，
（2）支持豐富的資料型別：支持 key-value、Strings、Lists、Hashes、Sets 及 Ordered Sets 等資料型別操作，
（3）支持資料的持久化：可以將記憶體中的資料保存在磁盤中，重啟的時候可以再次加載進行使用，
（4）原子性：Redis 所有操作都是原子性的，
（5）支持資料備份：即 master-salve 模式的資料備份，
Redis作為基于記憶體運行的資料庫，快取是其最常應用的場景之一，除此之外，Redis常見應用場景還包括獲取最新N個資料的操作、排行榜類應用、計數器應用、存盤關系、實時分析系統、日志記錄，

五、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

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/bin/redis-cli			#客戶端命令工具

ln -s /usr/local/redis/bin/* /usr/local/bin/

/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

70行，添加 監聽的主機地址
bind 127.0.0.1 192.168.177.11				

93行，Redis默認的監聽埠
port 6379									

137行，啟用守護行程
daemonize yes							

159行，指定 PID 檔案
pidfile /var/run/redis_6379.pid				

167行，日志級別
loglevel notice								

172行，指定日志檔案
logfile /var/log/redis_6379.log				

/etc/init.d/redis_6379 restart

六、Redis命令工具

1、redis-cli 命令列工具

redis-server		用于啟動 Redis 的工具
redis-benchmark		用于檢測 Redis 在本機的運行效率
redis-check-aof		修復 AOF 持久化檔案
redis-check-rdb		修復 RDB 持久化檔案
redis-cli	 		Redis命令列工具

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

2、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.177.8、埠為 6379 的 Redis 服務器發送 100 個并發連接與 100000 個請求測驗性能

redis-benchmark -h 192.168.177.8 -p 6379 -c 100 -n 100000

測驗存取大小為 100 位元組的資料包的性能

redis-benchmark -h 192.168.177.8 -p 6379 -q -d 100

測驗本機上 Redis 服務在進行 set 與 lpush 操作時的性能

redis-benchmark -t set,lpush -n 100000 -q

3、Redis 資料庫常用命令

set		存放資料，命令格式為 set key value
get		獲取資料，命令格式為 get key
keys 	命令可以取符合規則的鍵值串列，通常情況可以結合*、?等選項來使用，
exists 	命令可以判斷鍵值是否存在，
del 	命令可以洗掉當前資料庫的指定 key，
type 	命令可以獲取 key 對應的 value 值型別，

rename 命令是對已有 key 進行重命名，（覆寫）
命令格式：rename 源key 目標key

renamenx 命令的作用是對已有 key 進行重命名，并檢測新名是否存在，如果目標 key 存在則不進行重命名，（不覆寫）
命令格式：renamenx 源key 目標key

使用config set requirepass password命令設定密碼
使用config get requirepass命令查看密碼（一旦設定密碼，必須先驗證通過密碼，否則所有操作不可用）

4、Redis 多資料庫常用命令

Redis 支持多資料庫，Redis 默認情況下包含 16 個資料庫，資料庫名稱是用數字 0-15 來依次命名的，多資料庫相互獨立，互不干擾，
（1）多資料庫間切換
命令格式：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 的資料庫

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

格式：move 鍵值 序號
例：
set edg 17
get edg

select 5
get edg

select 0
move edg 5
get edg

select 5
get edg

清除資料庫內資料
FLUSHDB ：清空當前資料庫資料
FLUSHALL ：清空所有資料庫的資料

七、Redis高可用

1、在web服務器中，高可用是指服務器可以正常訪問的時間，衡量的標準是在多長時間內可以提供正常服務（99.9%、99.99%、99.999%等等），
但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務（如主從分離、快速容災技術），還需要考慮資料容量的擴展、資料安全不會丟失等，
2、在Redis中，實作高可用的技術主要包括持久化、主從復制、哨兵和集群
（1）持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是資料備份，即將資料存盤在硬碟，保證資料不會因行程退出而丟失，
（2）主從復制：主從復制是高可用Redis的基礎，哨兵和集群都是在主從復制基礎上實作高可用的，主從復制主要實作了資料的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復，缺陷：故障恢復無法自動化；寫操作無法負載均衡；存盤能力受到單機的限制，
（3）哨兵：在主從復制的基礎上，哨兵實作了自動化的故障恢復，缺陷：寫操作無法負載均衡；存盤能力受到單機的限制，
（4）集群：通過集群，Redis解決了寫操作無法負載均衡，以及存盤能力受到單機限制的問題，實作了較為完善的高可用方案，
注：持久化的功能：Redis是記憶體資料庫，資料都是存盤在記憶體中，為了避免服務器斷電等原因導致Redis行程例外退出后資料的永久丟失，需要定期將Redis中的資料以某種形式（資料或命令）從記憶體保存到硬碟；當下次Redis重啟時，利用持久化檔案實作資料恢復，除此之外，為了進行災難備份，可以將持久化檔案拷貝到一個遠程位置，

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

1、RDB 持久化

RDB持久化是指在指定的時間間隔內將記憶體中當前行程中的資料生成快照保存到硬碟(因此也稱作快照持久化)，用二進制壓縮存盤，保存的檔案后綴是rdb；當Redis重新啟動時，可以讀取快照檔案恢復資料，
（1）觸發方式
a、手動觸發
save命令和bgsave命令都可以生成RDB檔案，
save命令會阻塞Redis服務器行程，直到RDB檔案創建完畢為止，在Redis服務器阻塞期間，服務器不能處理任何命令請求，
而bgsave命令會創建一個子行程，由子行程來負責創建RDB檔案，父行程(即Redis主行程)則繼續處理請求，

bgsave命令執行程序中，只有fork子行程時會阻塞服務器，而對于save命令，整個程序都會阻塞服務器，因此save已基本被廢棄，線上環境要杜絕save的使用，
b、自動觸發
在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化，
自動觸發最常見的情況是在組態檔中通過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

（2）執行流程
a、Redis父行程首先判斷：當前是否在執行save，或bgsave/bgrewriteaof的子行程，如果在執行則bgsave命令直接回傳， bgsave/bgrewriteaof的子行程不能同時執行，主要是基于性能方面的考慮：兩個并發的子行程同時執行大量的磁盤寫操作，可能引起嚴重的性能問題，
b、父行程執行fork操作創建子行程，這個程序中父行程是阻塞的，Redis不能執行來自客戶端的任何命令
c、父行程fork后，bgsave命令回傳”Background saving started”資訊并不再阻塞父行程，并可以回應其他命令
d、子行程創建RDB檔案，根據父行程記憶體快照生成臨時快照檔案，完成后對原有檔案進行原子替換
e、子行程發送信號給父行程表示完成，父行程更新統計資訊
（3）啟動時加載
RDB檔案的載入作業是在服務器啟動時自動執行的，并沒有專門的命令，但是由于AOF的優先級更高，因此當AOF開啟時，Redis會優先載入 AOF檔案來恢復資料；只有當AOF關閉時，才會在Redis服務器啟動時檢測RDB檔案，并自動載入，服務器載入RDB檔案期間處于阻塞狀態，直到載入完成為止，
Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日志中會列印錯誤，Redis啟動失敗，

2、AOF持久化

（1）AOF與RDB區別：RDB持久化是將行程資料寫入檔案，而AOF持久化，則是將Redis執行的每次寫、洗掉命令記錄到單獨的日志檔案中，查詢操作不會記錄； 當Redis重啟時再次執行AOF檔案中的命令來恢復資料，
與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案，
（2）開啟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）執行流程
a、命令追加(append)
Redis先將寫命令追加到緩沖區，而不是直接寫入檔案，主要是為了避免每次有寫命令都直接寫入硬碟，導致硬碟IO成為Redis負載的瓶頸，
命令追加的格式是Redis命令請求的協議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點，在AOF檔案中，除了用于指定資料庫的select命令（如select 0為選中0號資料庫）是由Redis添加的，其他都是客戶端發送來的寫命令，
b、檔案寫入(write)和檔案同步(sync)
Redis提供了多種AOF快取區的同步檔案策略，策略涉及到作業系統的write函式和fsync函式，說明如下：
為了提高檔案寫入效率，在現代作業系統中，當用戶呼叫write函式將資料寫入檔案時，作業系統通常會將資料暫存到一個記憶體緩沖區里，當緩沖區被填滿或超過了指定時限后，才真正將緩沖區的資料寫入到硬碟里，這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，記憶體緩沖區中的資料會丟失；因此系統同時提供了fsync、fdatasync等同步函式，可以強制作業系統立刻將緩沖區中的資料寫入到硬碟里，從而確保資料的安全性，
注：AOF快取區的同步檔案策略存在三種同步方式
●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的默認配置，也是我們推薦的配置，
c、檔案重寫(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操作，
●auto-aof-rewrite-percentage 100 ：當前AOF檔案大小(即aof_current_size)是上次日志重寫時AOF檔案大小(aof_base_size)兩倍時，發生BGREWRITEAOF操作
●auto-aof-rewrite-min-size 64mb ：當前AOF檔案執行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由于檔案尺寸較小導致頻繁的BGREWRITEAOF
檔案重寫的流程如下
a、Redis父行程首先判斷當前是否存在正在執行bgsave/bgrewriteaof的子行程，如果存在則bgrewriteaof命令直接回傳，如果存在 bgsave命令則等bgsave執行完成后再執行，
b、父行程執行fork操作創建子行程，這個程序中父行程是阻塞的，
c1、父行程fork后，bgrewriteaof命令回傳”Background append only file rewrite started”資訊并不再阻塞父行程， 并可以回應其他命令，Redis的所有寫命令依然寫入AOF緩沖區，并根據appendfsync策略同步到硬碟，保證原有AOF機制的正確，
c2、由于fork操作使用寫時復制技術，子行程只能共享fork操作時的記憶體資料，由于父行程依然在回應命令，因此Redis使用AOF重寫緩沖區(aof_rewrite_buf)保存這部分資料，防止新AOF檔案生成期間丟失這部分資料，也就是說，bgrewriteaof執行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區，
d、子行程根據記憶體快照，按照命令合并規則寫入到新的AOF檔案，
e1、子行程寫完新的AOF檔案后，向父行程發信號，父行程更新統計資訊，具體可以通過info persistence查看，
e2、父行程把AOF重寫緩沖區的資料寫入到新的AOF檔案，這樣就保證了新AOF檔案所保存的資料庫狀態和服務器當前狀態一致，
e3、使用新的AOF檔案替換老檔案，完成AOF重寫
（3）啟動時加載
當AOF開啟時，Redis啟動時會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會載入RDB檔案恢復資料，
當AOF開啟，但AOF檔案不存在時，即使RDB檔案存在也不會加載，
Redis載入AOF檔案時，會對AOF檔案進行校驗，如果檔案損壞，則日志中會列印錯誤，Redis啟動失敗，但如果是AOF檔案結尾不完整(機器突然宕機等容易導致檔案尾部不完整)，且aof-load-truncated引數開啟，則日志中會輸出警告，Redis忽略掉AOF檔案的尾部，啟動成功，aof-load-truncated引數默認是開啟的，

3、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性能管理

查看Redis記憶體使用

redis-cli -h 192.168.177.8 -p 6379
192.168.177.8:6379> info memory

1、記憶體碎片率
●記憶體碎片率稍大于1是合理的，這個值表示記憶體碎片率比較低
●記憶體碎片率超過1.5，說明Redis消耗了實際需要物理記憶體的150%，其中50%是記憶體碎片率，需要在redis-cli工具上輸入shutdown save 命令，并重啟 Redis 服務器，
●記憶體碎片率低于1的，說明Redis記憶體分配超出了物理記憶體，作業系統正在進行記憶體交換，需要增加可用物理記憶體或減少 Redis 記憶體占用，
2、記憶體使用率
避免記憶體交換發生的方法
●針對快取資料大小選擇安裝 Redis 實體
●盡可能的使用Hash資料結構存盤
●設定key的過期時間
3、內回收key
保證合理分配redis有限的記憶體資源，
當達到設定的最大閥值時，需選擇一種key的回收策略，默認情況下回收策略是禁止洗掉，

vim /etc/redis/6379.conf

598取消注釋

maxmemory-policy noenviction

●volatile-lru 使用LRU演算法從已設定過期時間的資料集合中淘汰資料
●volatile-ttl 從已設定過期時間的資料集合中挑選即將過期的資料淘汰
●volatile-random 從已設定過期時間的資料集合中隨機挑選資料淘汰
●allkeys-lru 使用LRU演算法從所有資料集合中淘汰資料
●allkeys-random 從資料集合中任意選擇資料淘汰
●noenviction 禁止淘汰資料