關(guān)系數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫

1.關(guān)系型數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫是一個(gè)結(jié)構(gòu)化的數(shù)據(jù)庫，創(chuàng)建在關(guān)系模型（二維表格模型）基礎(chǔ)上，一般面向于記錄。

SQL語句（標(biāo)準(zhǔn)數(shù)據(jù)查詢語言）就是一種基于關(guān)系型數(shù)據(jù)庫的語言，用于執(zhí)行對(duì)關(guān)系型數(shù)據(jù)庫中數(shù)據(jù)的檢索和操作。

關(guān)系型數(shù)據(jù)庫 SQL
Oracle 銀行用的多
MySQL 開源免費(fèi) 功能多（pgDB）
SQL Server 微軟
DB2 性能穩(wěn)定老數(shù)據(jù)庫

以上數(shù)據(jù)庫在使用的時(shí)候必須先建庫建表設(shè)計(jì)表結(jié)構(gòu)，然后存儲(chǔ)數(shù)據(jù)的時(shí)候按表結(jié)構(gòu)去存，如果數(shù)據(jù)與表結(jié)構(gòu)不匹配就會(huì)存儲(chǔ)失敗。

在每個(gè)二維表格中
每一行稱為一條記錄，用來描述一個(gè)對(duì)象的信息
每一列稱為一個(gè)字段，用來描述對(duì)象的一個(gè)屬性

2.非關(guān)系型數(shù)據(jù)庫

NoSQL（NoSQL = Not Only SQL），意思是"不僅僅是 SQL"，是非關(guān)系型數(shù)據(jù)庫的總稱。除了主流的關(guān)系型數(shù)據(jù)庫外的數(shù)據(jù)庫，都認(rèn)為是非關(guān)系型。
不需要預(yù)先建庫建表定義數(shù)據(jù)存儲(chǔ)表結(jié)構(gòu)，每條記錄可以有不同的數(shù)據(jù)類型和字段個(gè)數(shù) （比如微信群聊甲的文字、圖片、視頻、音樂等）

非關(guān)系型數(shù)據(jù)庫 No SQL

Hbase 分布式數(shù)據(jù)庫（大數(shù)據(jù)用）
ES 檢索型的數(shù)據(jù)庫有強(qiáng)大的檢索能力
普羅米修斯監(jiān)控系統(tǒng) 時(shí)序型數(shù)據(jù)庫（TSDB）
DNS 數(shù)據(jù)庫存放域名和ip 的數(shù)據(jù)庫

阿里云的云服務(wù)器：ECS 負(fù)載均衡：SLB 防火墻：安全組對(duì)象存儲(chǔ) OSS web緩存加速：CDN 數(shù)據(jù)庫：RDB-Redis

關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫區(qū)別

1、數(shù)據(jù)存儲(chǔ)方式不同
關(guān)系型和非關(guān)系型數(shù)據(jù)庫的主要差異是數(shù)據(jù)存儲(chǔ)的方式。

關(guān)系型數(shù)據(jù) 天然就是表格式的，因此存儲(chǔ)在數(shù)據(jù)表的行和列中。數(shù)據(jù)表可以彼此關(guān)聯(lián)協(xié)作存儲(chǔ)，也很容易提取數(shù)據(jù)。

非關(guān)系型數(shù)據(jù)庫與其相反，非關(guān)系型數(shù)據(jù)不適合存儲(chǔ)在數(shù)據(jù)表的行和列中，而是大塊組合在一起。非關(guān)系型數(shù)據(jù)通常存儲(chǔ)在數(shù)據(jù)集中，就像文檔、鍵值對(duì)或者圖結(jié)構(gòu)。數(shù)據(jù)及其特性是選擇數(shù)據(jù)存儲(chǔ)和提取方式的首要影響因素。

2、擴(kuò)展方式不同
SQL和NoSQL數(shù)據(jù)庫最大的差別可能是在擴(kuò)展方式上，要支持日益增長(zhǎng)的需求當(dāng)然要擴(kuò)展賴支持更多并發(fā)量。

SQL數(shù)據(jù)庫是縱向擴(kuò)展，擴(kuò)展CPU等性能磁盤空間空間，也就是提高處理能力，使用速度更快速的計(jì)算機(jī)，這樣處理相同的數(shù)據(jù)集就更快了。因?yàn)閿?shù)據(jù)存儲(chǔ)在關(guān)系表中，操作的性能瓶頸可能涉及很多個(gè)表，這都需要通過提高計(jì)算機(jī)性能來克服。雖然SOL數(shù)據(jù)庫有很大擴(kuò)展空間，但最終肯定會(huì)達(dá)到縱向擴(kuò)展的上限。

NoSQL數(shù)據(jù)庫是橫向擴(kuò)展的。因?yàn)榉顷P(guān)系型數(shù)據(jù)存儲(chǔ)天然就是分布式的，NoSQL數(shù)據(jù)庫的擴(kuò)展可以通過給資源池添加更多普通的數(shù)據(jù)庫服務(wù)器（節(jié)點(diǎn)）來分擔(dān)負(fù)載。

3、對(duì)事務(wù)性的支持不同
SQL數(shù)據(jù)庫如果數(shù)據(jù)操作需要高事務(wù)性或者復(fù)雜數(shù)據(jù)查詢需要控制執(zhí)行計(jì)劃，那么傳統(tǒng)的SQL數(shù)據(jù)庫從性能和穩(wěn)定性方面考慮是最佳選擇。SQL，數(shù)據(jù)庫支持對(duì)事務(wù)原子性細(xì)粒度控制，并且易于回滾事務(wù)。

NoSQL數(shù)據(jù)庫雖然NoSQL數(shù)據(jù)庫也可以使用事務(wù)操作，但穩(wěn)定性方面沒法和關(guān)系型數(shù)據(jù)庫比較，所以它們真正閃亮的價(jià)值是在操作的擴(kuò)展性和大數(shù)據(jù)量處理方面。

? 關(guān)系型: 特別適合高事務(wù)性要求和需要控制執(zhí)行計(jì)劃的任務(wù)

? 非關(guān)系型: 此處會(huì)稍顯弱勢(shì)，其價(jià)值點(diǎn)在于高擴(kuò)展性和大數(shù)據(jù)量處理方面

4、非關(guān)系型數(shù)據(jù)庫產(chǎn)生背景
可用于應(yīng)對(duì) Web2.0 純動(dòng)態(tài)網(wǎng)站類型的三高問題。

（1）Highperformance——對(duì)數(shù)據(jù)庫高并發(fā)讀寫需求

（2）Huge Storage——對(duì)海量數(shù)據(jù)高效存儲(chǔ)與訪問需求

（3）High Scalability && High Availability——對(duì)數(shù)據(jù)庫高可擴(kuò)展性與高可用性需求

關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫都有各自的特點(diǎn)與應(yīng)用場(chǎng)景，兩者的緊密結(jié)合將會(huì)給web2.0的數(shù)據(jù)庫發(fā)展帶來新的思略。讓關(guān)系數(shù)據(jù)庫關(guān)注在關(guān)系上，非關(guān)系型數(shù)據(jù)庫關(guān)注在存儲(chǔ)上。

例如，在讀寫分離的MySQL數(shù)據(jù)庫環(huán)境中，可以把經(jīng)常訪問的數(shù)據(jù)存儲(chǔ)在非關(guān)系型數(shù)據(jù)庫中，提升訪問速度。

5、總結(jié)--SQL和NoSQL數(shù)據(jù)的存儲(chǔ)過程
關(guān)系型數(shù)據(jù)庫
實(shí)例-->數(shù)據(jù)庫-->表（table）-->記錄行（row）、數(shù)據(jù)字段（column）

非關(guān)系型數(shù)據(jù)庫
實(shí)例-->數(shù)據(jù)庫-->集合（collection）-->鍵值對(duì)（key-value）、文檔、圖結(jié)構(gòu)
非關(guān)系型數(shù)據(jù)庫不需要手動(dòng)建數(shù)據(jù)庫和集合（表）。

Redis數(shù)據(jù)庫

Redis數(shù)據(jù)庫的概述
Redis（遠(yuǎn)程字典服務(wù)器）是一個(gè)開源的、使用C語言編寫的NoSQL數(shù)據(jù)庫

Redis 基于內(nèi)存運(yùn)行并支持持久化，采用key-value（鍵值對(duì)）的存儲(chǔ)形式，是目前分布式架構(gòu)中不可或缺的一環(huán)。

Redis服務(wù)器程序是單進(jìn)程模型，也就是在一臺(tái)服務(wù)器上可以同時(shí)啟動(dòng)多個(gè)Redis進(jìn)程，Redis的實(shí)際處理速度則是完全依靠于主進(jìn)程的執(zhí)行效率。

若在服務(wù)器上只運(yùn)行一個(gè)Redis進(jìn)程，當(dāng)多個(gè)客戶端同時(shí)訪問時(shí)，服務(wù)器的處理能力是會(huì)有一定程度的下降; 若在同一臺(tái)服務(wù)器上開啟多個(gè)Redis進(jìn)程，Redis在提高并發(fā)處理能力的同時(shí)會(huì)給服務(wù)器的CPU造成很大壓力。
在實(shí)際生產(chǎn)環(huán)境中，需要根據(jù)實(shí)際的需求來決定開啟多少個(gè)Redis進(jìn)程。若對(duì)高并發(fā)要求更高一些，可能會(huì)考慮在同一臺(tái)服務(wù)器上開啟多個(gè)進(jìn)程。若CPU資源比較緊張，采用單進(jìn)程即可。

*Redis6.0之前都是單線程，6.0版本之后支持多線程，但一般只針對(duì)網(wǎng)絡(luò)，讀寫方面還是使用單線程

2、Redis具有以下結(jié)果優(yōu)點(diǎn)：
（1）具有極高的數(shù)據(jù)讀寫速度∶數(shù)據(jù)讀取的速度最高可達(dá)到 110000 次/s，數(shù)據(jù)寫入速度最高可達(dá)到 81000 次/s。

（2）支持豐富的數(shù)據(jù)類型∶使用key-value存儲(chǔ)模式，Strings、Lists、Hashes、Sets 及 Sorted Sets 等數(shù)據(jù)類型操作。

（3）支持?jǐn)?shù)據(jù)的持久化∶可以將內(nèi)存中的數(shù)據(jù)保存在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使用。

（4）原子性∶Redis所有操作都是原子性的。

（5）支持?jǐn)?shù)據(jù)備份∶即 master-salve 模式的數(shù)據(jù)備份。

Redis作為基于內(nèi)存運(yùn)行的數(shù)據(jù)庫，緩存是其最常應(yīng)用的場(chǎng)景之一。
除此之外， Redis常見應(yīng)用場(chǎng)景還包括獲取最新N個(gè)數(shù)據(jù)的操作、排行榜類應(yīng)用、計(jì)數(shù)器應(yīng)用、存儲(chǔ)關(guān)系、實(shí)時(shí)分析系統(tǒng)、日志記錄（根據(jù)不同的數(shù)據(jù)類型實(shí)現(xiàn)不同場(chǎng)景的支持）。

3、Redis五種數(shù)據(jù)類型
3.1 String數(shù)據(jù)類型
概述：String是redis最基本的類型，最大能存儲(chǔ)512MB的數(shù)據(jù)，String類型是二進(jìn)制安全的，即可以存儲(chǔ)任何數(shù)據(jù)、比如數(shù)字、圖片、序列化對(duì)象等

3.2 List數(shù)據(jù)類型
概述：列表的元素類型為string，按照插入順序排序，在列表的頭部或尾部添加元素

3.3 Hash數(shù)據(jù)類型（散列類型）
概述：hash用于存儲(chǔ)對(duì)象?？梢圆捎眠@樣的命名方式：對(duì)象類別和ID構(gòu)成鍵名，使用字段表示對(duì)象的屬性，而字段值則存儲(chǔ)屬性值。如：存儲(chǔ)ID為2的汽車對(duì)象。

如果Hash中包含很少的字段，那么該類型的數(shù)據(jù)也將僅占用很少的磁盤空間。每一個(gè)Hash可以存儲(chǔ)4294967295個(gè)鍵值對(duì)。

3.4 Set數(shù)據(jù)類型（無序集合）
概述：無序集合，元素類型為String類型，元素具有唯一性，不允許存在重復(fù)的成員。多個(gè)集合類型之間可以進(jìn)行并集、交集和差集運(yùn)算。

應(yīng)用范圍：

1.可以使用Redis的Set數(shù)據(jù)類型跟蹤一些唯一性數(shù)據(jù)，比如訪問某一博客的唯一IP地址信息。對(duì)于此場(chǎng)景，我們僅需在每次訪問該博客時(shí)將訪問者的IP存入Redis中，Set數(shù)據(jù)類型會(huì)自動(dòng)保證IP地址的唯一性。

2.充分利用Set類型的服務(wù)端聚合操作方便、高效的特性，可以用于維護(hù)數(shù)據(jù)對(duì)象之間的關(guān)聯(lián)關(guān)系。比如所有購買某一電子設(shè)備的客戶ID被存儲(chǔ)在一個(gè)指定的Set中，而購買另外一種電子產(chǎn)品的客戶ID被存儲(chǔ)在另外一個(gè)Set中，如果此時(shí)我們想獲取有哪些客戶同時(shí)購買了這兩種商品時(shí)，Set的intersections命令就可以充分發(fā)揮它的方便和效率的優(yōu)勢(shì)了。

3.5 Sorted Set數(shù)據(jù)類型（zset、有序集合）
概述：有序集合，元素類型為Sting，元素具有唯一性，不能重復(fù)。

每個(gè)元素都會(huì)關(guān)聯(lián)一個(gè)double類型的分?jǐn)?shù)score(表示權(quán)重)，可以通過權(quán)重的大小排序，元素的score可以相同。

應(yīng)用范圍：

1)可以用于一個(gè)大型在線游戲的積分排行榜。每當(dāng)玩家的分?jǐn)?shù)發(fā)生變化時(shí)，可以執(zhí)行ZADD命令更新玩家的分?jǐn)?shù)，此后再通過ZRANGE命令獲取積分TOP10的用戶信息。當(dāng)然我們也可以利用ZRANK命令通過username來獲取玩家的排行信息。最后我們將組合使用ZRANGE和ZRANK命令快速的獲取和某個(gè)玩家積分相近的其他用戶的信息。

2)Sorted-Set類型還可用于構(gòu)建索引數(shù)據(jù)。

4、Redis效率快的原因
（1）Redis 是一款純內(nèi)存結(jié)構(gòu)，避免了磁盤I/O等耗時(shí)操作。

（2）Redis 命令處理的核心模塊為單線程，減少了鎖競(jìng)爭(zhēng)，以及頻繁創(chuàng)建線程和銷毀線程的代價(jià)，減少了線程上下文切換的消耗。

（3）采用了 I/O 多路復(fù)用機(jī)制，大大提升了并發(fā)效率。

I/O多路復(fù)用程序雖然會(huì)同時(shí)監(jiān)聽多個(gè) Socket 連接，但是其會(huì)將監(jiān)聽的 Socket 都放到一個(gè)隊(duì)列里面，然后通過這個(gè)隊(duì)列有序的，同步的將每個(gè) Socket 對(duì)應(yīng)的事件傳送給文件事件分派器，再由文件事件分派器分派給對(duì)應(yīng)的事件處理器進(jìn)行處理，只有當(dāng)一個(gè) Socket 所對(duì)應(yīng)的事件被處理完畢之后，I/O多路復(fù)用程序才會(huì)繼續(xù)向文件事件分派器傳送下一個(gè) Socket所對(duì)應(yīng)的事件，這也可以驗(yàn)證上面的結(jié)論，處理客戶端的命令請(qǐng)求是單線程的方式逐個(gè)處理，但是事件處理器內(nèi)并不是只有一個(gè)線程。

Redis 部署以及相關(guān)命令

關(guān)閉防火墻和SElinux
安裝gcc gcc-c++ 編譯器

systemctl stop firewalld
setenforce 0
yum install -y gcc gcc-c++ make

將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文件，所以在解壓完軟件包后，不用先執(zhí)行./configure進(jìn)行配置，可直接執(zhí)行make與make install命令進(jìn)行安裝

執(zhí)行軟件包提供的installserver.sh腳本文件設(shè)置Redis服務(wù)所需要的相關(guān)配置文件

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
#需要手動(dòng)修改為/usr/local/redis/bin/redis-server 注意要一次性正確輸

把redis的可執(zhí)行程序文件放入路徑環(huán)境變量的目錄中便于系統(tǒng)識(shí)別

ln -s /usr/local/redis/bin/* /usr/local/bin/
 
#當(dāng)install_server.sh 腳本運(yùn)行完畢，Redis 服務(wù)就已經(jīng)啟動(dòng)，默認(rèn)偵聽端口為6379
netstat -natp | grep redis

Redis服務(wù)控制

/etc/init.d/redis_6379 stop       #停止
/etc/init.d/redis_6379 start      #啟動(dòng)
/etc/init.d/redis_6379 restart    #重啟
/etc/init.d/redis_6379 status     #狀態(tài)　　

chmod +x /etc/init.d/redis_6379
chkconfig --add /etc/init.d/redis_6379
systemctl start redis_6379.service

修改配置/etc/redis/6379.conf參數(shù)

vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.247.10      #70行，添加監(jiān)聽的主機(jī)地址
port 6379                          #93行，Redis默認(rèn)的監(jiān)聽端口
daemonize yes                      #137行，啟用守護(hù)進(jìn)程
pidfile /var/run/redis_6379.pid    #159行，指定PID文件
loglevel notice                    #167行，日志級(jí)別
logfile /var/log/redis_6379.log    #172行，指定日志文件
 
/etc/init.d/redis_6379 restart

Redis命令工具

redis-server 用于啟動(dòng) Redis 的工具
redis-benchmark 用于檢測(cè) Redis 在本機(jī)的運(yùn)行效率
redis-check-aof 修復(fù) AOF 持久化文件
redis-check-rdb 修復(fù) RDB 持久化文件
redis-cli Redis命令行工具
rdb和aof是redis服務(wù)中持久化功能的兩種形式RDB AOF
redis-cli 常用于登陸至redis數(shù)據(jù)庫

redis-cli命令行工具（遠(yuǎn)程登錄）

語法: redis-cli -h host -p port -a password
選項(xiàng)：
    -h :指定遠(yuǎn)程主機(jī)
    -p :指定Redis 服務(wù)的端口號(hào)
    -a :指定密碼，未設(shè)置數(shù)據(jù)庫密碼可以省略-a選項(xiàng)
若不添加任何選項(xiàng)表示，則使用127.0.0.1:6379 連接本機(jī)上的 Redis 數(shù)據(jù)庫

redis-benchmark 測(cè)試工具

redis-benchmark 是官方自帶的 Redis 性能測(cè)試工具，可以有效的測(cè)試 Redis 服務(wù)的性能。

-h：指定服務(wù)器主機(jī)名
-p：指定服務(wù)器端口
-s：指定服務(wù)器 socket
-c：指定并發(fā)連接數(shù)
-n：指定請(qǐng)求數(shù)
-d：以字節(jié)的形式指定 SET/GET 值的數(shù)據(jù)大小
-k：1=keep alive 0=reconnect
-r: SET/GET/INCR 使用隨機(jī) key, SADD 使用隨機(jī)值
-P：通過管道傳輸<numred>請(qǐng)求
-q：強(qiáng)制退出 redis。僅顯示 query/sec 值
–csv：以 CSV 格式輸出
-l：生成循環(huán)，永久執(zhí)行測(cè)試
-t：僅運(yùn)行以逗號(hào)分隔的測(cè)試命令列表
-I：Idle 模式。僅打開 N 個(gè) idle 連接并等待
 
 
#向 IP 地址為 192.168.247.10、端口為 6379 的 Redis 服務(wù)器發(fā)送 100 個(gè)并發(fā)連接與 100000 個(gè)請(qǐng)求測(cè)試性能
redis-benchmark -h 192.168.247.10 -p 6379 -c 100 -n 100000
 
#測(cè)試存取大小為 100 字節(jié)的數(shù)據(jù)包的性能
redis-benchmark -h 192.168.247.10 -p 6379 -q -d 100
 
#測(cè)試本機(jī)上 Redis 服務(wù)在進(jìn)行 set 與 lpush 操作時(shí)的性能
redis-benchmark -t set,lpush -n 100000 -q

Redis數(shù)據(jù)庫常用命令

set: 存放數(shù)據(jù)，命令格式為 set key value
get: 獲取數(shù)據(jù)，命令格式為 get key

命令	解釋
set [key] [value]	存放數(shù)據(jù)
get [key]	獲取某個(gè)key的數(shù)據(jù)
keys [*/?]	查找符合的鍵值列表，可搭配（*）、（？）使用
exists key [key...]	判斷鍵值是否存在，返回0為不存在，1為存在
del key [key ...]	刪除指定的key
type [key]	查看key對(duì)應(yīng)的value值類型
rename 源key 目標(biāo)key	對(duì)已有的key進(jìn)行重命名，改名后會(huì)覆蓋同名的key的值
renamenx源key目標(biāo)key	對(duì)已有的key進(jìn)行重命名，但會(huì)判斷新名字是否存在，存在則不執(zhí)行
dbszie	查看當(dāng)前數(shù)據(jù)庫key的數(shù)目
config set requirepass [密碼]	設(shè)置密碼
auth [密碼]	設(shè)置密碼后需要驗(yàn)證否則無法進(jìn)行任何操作

keys 命令可以取符合規(guī)則的鍵值列表，通常情況可以結(jié)合*、?等選項(xiàng)來使用。

keys *   #查看當(dāng)前數(shù)據(jù)庫中所有的鍵
keys z*   #查看當(dāng)前數(shù)據(jù)中以z開頭的所有數(shù)據(jù)
keys z?   #查看當(dāng)前數(shù)據(jù)中以z開頭，z開頭后面包含任意一位的數(shù)據(jù)
keys z??  #查看當(dāng)前數(shù)據(jù)中以z開頭，z開頭后面包含任意兩位的數(shù)據(jù)

exists 命令

可以判斷鍵值是否存在

del 命令

可以刪除當(dāng)前數(shù)據(jù)庫的指定key　　

type 命令

可以獲取key對(duì)應(yīng)的 value 值類型

rename 命令

是對(duì)已有key進(jìn)行重命名。 (覆蓋)

命令格式: rename 源key 目標(biāo)key

使用rename命令進(jìn)行重命名時(shí)，無論目標(biāo)key是否存在都進(jìn)行重命名，且源key的值會(huì)覆蓋目標(biāo)key的值。

在實(shí)際使用過程中，建議先用 exists命令查看目標(biāo)key是否存在，然后再?zèng)Q定是否執(zhí)行rename命令，以避免覆蓋重要數(shù)據(jù)。

renamenx 命令

作用是對(duì)已有key進(jìn)行重命名，并檢測(cè)新名是否存在
如果目標(biāo)key存在則不進(jìn)行重命名。 (不覆蓋)
命令格式: renamenx 源key 目標(biāo)key

dbsize命令

作用是查看當(dāng)前數(shù)據(jù)庫中key的數(shù)目。

使用config set requirepass 命令設(shè)置密碼

使用config get requirepass 命令查看密碼
刪除密碼

Redis 多數(shù)據(jù)庫常用命令

Redis支持多數(shù)據(jù)庫，Redis 默認(rèn)情況下包含16個(gè)數(shù)據(jù)庫，數(shù)據(jù)庫名稱是用數(shù)字0-15 來依次命名的
多數(shù)據(jù)庫相互獨(dú)立，互不干擾

多數(shù)據(jù)庫間切換

命令格式: select 序號(hào)
使用 redis-cli 連接Redis數(shù)據(jù)庫后，默認(rèn)使用的是序號(hào)為 0 的數(shù)據(jù)庫。

清除數(shù)據(jù)庫內(nèi)數(shù)據(jù)
FLUSHDB :清空當(dāng)前數(shù)據(jù)庫數(shù)據(jù)
FLUSHALL :清空所有數(shù)據(jù)庫的數(shù)據(jù)，慎用!!! 　

Redis 高可用

在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時(shí)間，衡量的標(biāo)準(zhǔn)是在多長(zhǎng)時(shí)間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999%等等)。

但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)(如主從分離、快速容災(zāi)技術(shù))，還需要考慮數(shù)據(jù)容量的擴(kuò)展，數(shù)據(jù)安全不會(huì)丟失等。

在Redis中，實(shí)現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和集群，作用如下：
持久化 :持久化是最簡(jiǎn)單的高可用方法(有時(shí)甚至不被歸為高可用的手段)，主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲(chǔ)在硬盤，保證數(shù)據(jù)不會(huì)因進(jìn)程退出而丟失。

主從復(fù)制 :主從復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在主從復(fù)制基礎(chǔ)上實(shí)現(xiàn)高可用的。主從復(fù)制主要實(shí)現(xiàn)了數(shù)據(jù)的多機(jī)備份，以及對(duì)于讀操作的負(fù)載均衡和簡(jiǎn)單的故障恢復(fù)。

缺陷:故障恢復(fù)無法自動(dòng)化;寫操作無法負(fù)載均衡;存儲(chǔ)能力受到單機(jī)的限制。

哨兵哨兵 :在主從復(fù)制的基礎(chǔ)上，哨兵實(shí)現(xiàn)了自動(dòng)化的故障恢復(fù)。缺陷 :寫操作無法負(fù)載均衡;存儲(chǔ)能力受到單機(jī)的限制。

集群 : 通過集群， Redis解決了寫操作無法負(fù)載均衡，以及存儲(chǔ)能力受到單機(jī)限制的問題，實(shí)現(xiàn)了較為完善的高可用方案。

Redis持久化

1、持久化的功能 :
Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中，為了避免服務(wù)器斷電等原因?qū)е翿edis進(jìn)程異常退出后數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式( 數(shù)據(jù)或命令)從內(nèi)存保存到硬盤;當(dāng)下次Redis重啟時(shí)，利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。

除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個(gè)遠(yuǎn)程位置（NFS）

2、Redis提供兩種方式持久化：
? RDB持久化 : 原理是將Reids在內(nèi)存中的數(shù)據(jù)庫記錄定時(shí)保存到磁盤上
? AOF持久化(append only file) : 原理是將Reids的操作日志以追加的方式寫入文件，類似于MySQL的binlog

由于AOF持久化的實(shí)時(shí)性更好，即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地

RDB持久化

RDB持久化是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中當(dāng)前進(jìn)程中的數(shù)據(jù)生成快照保存到硬盤(因此也稱作快照持久化)，用二進(jìn)制壓縮存儲(chǔ)，保存的文件后綴是rdb；當(dāng)Redis重新啟動(dòng)時(shí)，可以讀取快照文件恢復(fù)數(shù)據(jù)

觸發(fā)條件
RDB持久化的觸發(fā)分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)兩種

手動(dòng)觸發(fā)
? save命令和bgsave命令都可以生成RDB文件
? save命令會(huì)阻塞Redis服務(wù)器進(jìn)程，直到RDB文件創(chuàng)建完畢為止，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請(qǐng)求
?而bgsave命令會(huì)創(chuàng)建一個(gè)子進(jìn)程，由子進(jìn)程來負(fù)責(zé)創(chuàng)建RDB文件，父進(jìn)程 (即Redis主進(jìn)程) 則繼續(xù)處理請(qǐng)求
? bgsave命令執(zhí)行過程中，只有fork 子進(jìn)程時(shí)會(huì)阻塞服務(wù)器，而對(duì)于save命令，整個(gè)過程都會(huì)阻塞服務(wù)器，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用?。?！

往往生產(chǎn)環(huán)境 bgsave 依然不允許輕易使用

自動(dòng)觸發(fā)
? 在自動(dòng)觸發(fā)RDB持久化時(shí)，Redis也會(huì)選擇bgsave而不是save來進(jìn)行持久化

save m n
? 自動(dòng)觸發(fā)最常見的情況是在配置文件中通過save m n，指定當(dāng)m秒內(nèi)發(fā)生n次變化時(shí)，會(huì)觸發(fā)bgsave

vim /etc/redis/6379.conf
--219行--以下三個(gè)save條件滿足任意一個(gè)時(shí)，都會(huì)引起bgsave的調(diào)用
save 900 1 :當(dāng)時(shí)間到900秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave
save 300 10 :當(dāng)時(shí)間到300秒時(shí)， 如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsave
save 60 10000 :當(dāng)時(shí)間到60秒時(shí)，如果redis數(shù)據(jù)發(fā)生了至少10000次變化， 則執(zhí)行bgsave
--242行--是否開啟RDB文件壓縮
rdbcompression yes
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目錄
dir /var/lib/redis/6379

其他自動(dòng)觸發(fā)機(jī)制
除了 save m n 以外，還有一些其他情況會(huì)觸發(fā)bgsave:

? 在主從復(fù)制場(chǎng)景下，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，則主節(jié)點(diǎn)會(huì)執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點(diǎn)
? 執(zhí)行shutdown命令時(shí)，自動(dòng)執(zhí)行rdb持久化

執(zhí)行流程
(1) Redis父進(jìn)程首先判斷 :當(dāng)前是否在執(zhí)行save，或bgsave/bgrewriteaof的子進(jìn)程，如果在執(zhí)行，則bgsave命令直接返回bgsave/bgrewriteaof 的子進(jìn)程不能同時(shí)執(zhí)行，主要是基于性能方面的考慮:兩個(gè)并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤寫操作，可能引起嚴(yán)重的性能問題

(2) 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過程中父進(jìn)程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令

(3) 父進(jìn)程fork后，bgsave 命令返回”Background saving started" 信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令

(4) 子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存快照生成臨時(shí)快照文件，完成后對(duì)原有文件進(jìn)行原子替換

(5) 子進(jìn)程發(fā)送信號(hào)給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計(jì)信息

啟動(dòng)時(shí)加載
? RDB文件的載入工作是在服務(wù)器啟動(dòng)時(shí)自動(dòng)執(zhí)行的，并沒有專門的命令。但是由于A0F的優(yōu)先級(jí)更高，因此當(dāng)AOF開啟時(shí)，Redis會(huì)優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù);只有當(dāng)A0F關(guān)閉時(shí)，才會(huì)在Redis服務(wù)器啟動(dòng)時(shí)檢測(cè)RDB文件，并自動(dòng)載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止
? Redis載入RDB文件時(shí)，會(huì)對(duì)RDB文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗

AOF持久化

? RDB持久化是將進(jìn)程數(shù)據(jù)寫入文件，而AOF持久化，則是將Redis執(zhí)行的每次寫、刪除命令記錄到單獨(dú)的日志文件中，查詢操作不會(huì)記錄; 當(dāng)Redis重啟時(shí)再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。
? 與RDB相比，AOF的實(shí)時(shí)性更好，因此已成為主流的持久化方案

開啟AOF
Redis服務(wù)器默認(rèn)開啟RDB，關(guān)閉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

執(zhí)行流程
由于需要記錄Redis的每條寫命令，因此A0F不需要觸發(fā)，AOF的執(zhí)行流程如下：

AOF的執(zhí)行流程包括:
? 命令追加(append): 將Redis的寫命令追加到緩沖區(qū)aof_ buf;

? 文件寫入(write)和文件同步(sync):根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤;

? 文件重寫(rewrite): 定期重寫AOF文件，達(dá)到壓縮的目的。

① 命令追加 (append)

Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導(dǎo)致硬盤IO成為Redis負(fù)載的瓶頸。

命令追加的格式是Redis命令請(qǐng)求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強(qiáng)、容易處理、操作簡(jiǎn)單避免二次開銷等優(yōu)點(diǎn)。在A0F文件中，除了用于指定數(shù)據(jù)庫的select命令 (如select0為選中0號(hào)數(shù)據(jù)庫) 是由Redis添加的，其他都是客戶端發(fā)送來的寫命令

② 文件寫入(write) 和文件同步 (sync)

Redis 提供了多種AOF緩存區(qū)的同步文件策略，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)，說明如下:

為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當(dāng)用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時(shí)，操作系統(tǒng)通常會(huì)將數(shù)據(jù)暫存到一個(gè)內(nèi)存緩沖區(qū)里，當(dāng)緩沖區(qū)被填滿或超過了指定時(shí)限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。這樣的操作雖然提高了效率，但也帶來了安全問題:如果計(jì)算機(jī)停機(jī)，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會(huì)丟失;因此系統(tǒng)同時(shí)提供了fsync、fdatasync等同步函數(shù)，可以強(qiáng)制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里，從而確保數(shù)據(jù)的安全性

AOF緩存區(qū)的同步文件策略存在三種同步方式，它們分別是：

vim /etc/redis/6379.conf
---729---
● appendfsync always:
命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件，fsync完成后線程返回。
這種情況下，每次有寫命令都要同步到AOF文件，硬盤IO成為性能瓶頸，
Redis只能支持大約幾百TPS寫入，嚴(yán)重降低了Redis的性能；
即便是使用固態(tài)硬盤(SSD)，每秒大約也只能處理幾萬個(gè)命令，而且會(huì)大大降低SSD的壽命。
 
● appendfsync no:
命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對(duì)AOF文件做fsync同步;同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為30秒。
這種情況下，文件同步的時(shí)間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會(huì)很多，數(shù)據(jù)安全性無法保證。
 
● appendfsynceverysec:
命令寫入aof_buf后調(diào)用系統(tǒng)write操作，write完成后線程返回; fsync同步文件操作由專門的線程每秒調(diào)用一次。
everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是Redis的默認(rèn)配置，也是我們推薦的配置。

③ 文件重寫 (rewrite)

? 隨著時(shí)間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多，AOF文件也會(huì)越來越大：過大的AOF文件不僅會(huì)影響服務(wù)器的正常運(yùn)行，也會(huì)導(dǎo)致數(shù)據(jù)恢復(fù)需要的時(shí)間過長(zhǎng)。

? 文件重寫是指定期重寫AOF文件，減小AOF文件的體積。需要注意的是，AOF重寫是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令，同步到新的AOF文件；不會(huì)對(duì)舊的AOF文件進(jìn)行任何讀取、寫入操作!

? 關(guān)于文件重寫需要注意的另一點(diǎn)是：對(duì)于AOF持久化來說，文件重寫雖然是強(qiáng)烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動(dòng)的時(shí)候?qū)耄阂虼嗽谝恍?shí)現(xiàn)中，會(huì)關(guān)閉自動(dòng)的文件重寫，然后通過定時(shí)任務(wù)在每天的某一時(shí)刻定時(shí)執(zhí)行

文件重寫之所以能夠壓縮AOF文件，原因在于：

? 過期的數(shù)據(jù)不再寫入文件
? 無效的命令不再寫入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值(set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset) 等。
? 多條命令可以合并為一個(gè)：如sadd myset v1, sadd myset v2， sadd myset v3可以合并為sadd myset v1 v2 v3。

通過上述內(nèi)容可以看出，由于重寫后AOF執(zhí)行的命令減少了，文件重寫既可以減少文件占用的空間，也可以加快恢復(fù)速度

? 手動(dòng)觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時(shí)阻塞

? 自動(dòng)觸發(fā)：通過設(shè)置auto-aof - rewrite-min-size選項(xiàng)和auto- aof - rewrite- percentage選項(xiàng)來自動(dòng)執(zhí)行BGREWRITEAOF

只有當(dāng)auto-aof- rewrite- -min-size和auto-aof -rewrite-percentage兩個(gè)選項(xiàng)同時(shí)滿足時(shí)，才會(huì)自動(dòng)觸發(fā)AOF重寫，即bgrewriteaof操作

vim /etc/redis/ 6379. conf
----729----
auto-aof- rewrite-percentage 100
當(dāng)前AOF文件大小(即aof_current_size)是上次日志重寫時(shí)AOF文件大小(aof_base_size)兩倍時(shí)，發(fā)生BGREWRITEAOF操作
auto-aof - rewrite-min-size 64mb
當(dāng)前A0F文件執(zhí)行BGREWRITEAOF命令的最小值，避免剛開始啟動(dòng)Reids時(shí)由于文件尺寸較小導(dǎo)致頻繁的BGREWRITEAOF

關(guān)于文件重寫的流程，有兩點(diǎn)需要特別注意：

? 重寫由父進(jìn)程fork子進(jìn)程進(jìn)行;
? 重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_ rewrite_buf緩存

文件重寫的流程如下：

(1) Redis父進(jìn)程首先判斷當(dāng)前是否存在正在執(zhí)行bgsave/bgrewriteaof的子進(jìn)程，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行

(2) 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個(gè)過程中父進(jìn)程是阻塞的

(3.1) 父進(jìn)程fork后，bgrewriteaof 命令返回"Background append only file rewrite started" 信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū)，并根據(jù)appendfsync策略同步到硬盤，保證原有A0F機(jī)制的正確

(3.2) 由于fork操作使用寫時(shí)復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時(shí)的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然在響應(yīng)命令，因此Redis使用AOF重寫緩沖區(qū)(aof_ rewrite_buf) 保存這部分?jǐn)?shù)據(jù)，防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。也就是說，bgrewriteaof執(zhí)行期間，Redis的寫命令同時(shí)追加到aof_ buf和aof_ rewirte_ buf兩個(gè)緩沖區(qū)

(4) 子進(jìn)程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新的AOF文件

(5.1) 子進(jìn)程寫完新的AOF文件后，向父進(jìn)程發(fā)信號(hào)，父進(jìn)程更新統(tǒng)計(jì)信息，具體可以通過info persistence查看

(5.2) 父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致

(5.3) 使用新的AOF文件替換老文件，完成AOF重寫

啟動(dòng)時(shí)加載
? 當(dāng)AOF開啟時(shí)，Redis啟動(dòng)時(shí)會(huì)優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù);只有當(dāng)AOF關(guān)閉時(shí)，才會(huì)載入RDB文件恢復(fù)數(shù)據(jù)

? 當(dāng)AOF開啟，但AOF文件不存在時(shí)，即使RDB文件存在也不會(huì)加載

? Redis載入AOF文件時(shí)，會(huì)對(duì)AOF文件進(jìn)行校驗(yàn)，如果文件損壞，則日志中會(huì)打印錯(cuò)誤，Redis啟動(dòng)失敗。但如果是AOF文件結(jié)尾不完整 (機(jī)器突然宕機(jī)等容易導(dǎo)致文件尾部不完整)，且aof-load- truncated參數(shù)開啟，則日志中會(huì)輸出警告，Redis 忽略掉AOF文件的尾部，啟動(dòng)成功

? aof-load-truncated參數(shù)默認(rèn)是開啟的

RDB和AOF的優(yōu)缺點(diǎn)

1.RDB持久化
優(yōu)點(diǎn)：
?vRDB文件緊湊，體積小，網(wǎng)絡(luò)傳輸快，適合全量復(fù)制;恢復(fù)速度比AOF快很多。當(dāng)然，與AOF相比， RDB最重要的優(yōu)點(diǎn)之一是對(duì)性能的影響相對(duì)較小

缺點(diǎn)：
? RDB文件的致命缺點(diǎn)在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實(shí)時(shí)持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時(shí)候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)

? 對(duì)于RDB持久化，一方面是bgsave在進(jìn)行fork操作時(shí)Redis主進(jìn)程會(huì)阻塞，另一方面，子進(jìn)程向硬盤寫數(shù)據(jù)也會(huì)帶來IO壓力

2.AOF持久化
? 與RDB持久化相對(duì)應(yīng)，AOF的優(yōu)點(diǎn)在于支持秒級(jí)持久化、兼容性好，缺點(diǎn)是文件大、恢復(fù)速度慢、對(duì)性能影響大

? 對(duì)于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高(everysec策略下為秒級(jí))，IO壓力更大，甚至可能造成AOF追加阻塞問題

? AOF文件的重寫與RDB的bgsave類似，會(huì)有fork時(shí)的阻塞和子進(jìn)程的I0壓力問題。相對(duì)來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對(duì)Redis主進(jìn)程性能的影響會(huì)更大

RDB和AOF持久化的區(qū)別##

RDB 把reids內(nèi)存中的數(shù)據(jù) 打快照定時(shí)的保存到磁盤當(dāng)中保存的文件名 .rdb
AOF 以日志的形式追加寫入到日志文件中保存的文件名.aof

Redis性能管理

查看Redis內(nèi)存使用 info memory

內(nèi)存碎片率
操作系統(tǒng)分配的內(nèi)存值used_ memory_ rss除以Redis使用的內(nèi)存值used_ memory計(jì)算得出內(nèi)存碎片是由

操作系統(tǒng)低效的分配/回收物理內(nèi)存導(dǎo)致的 (不連續(xù)的物理內(nèi)存分配)

跟蹤內(nèi)存碎片率對(duì)理解Redis實(shí)例的資源性能是非常重要的:
? 內(nèi)存碎片率稍大于1是合理的，這個(gè)值表示內(nèi)存碎片率比較低
? 內(nèi)存碎片率超過1.5，說明Redis消耗了實(shí)際需要物理內(nèi)存的150號(hào)，其中50號(hào)是內(nèi)存碎片率。需要在redis-cli工具.上輸入shutdown save命令，并重啟Redis 服務(wù)器
? 內(nèi)存碎片率低于1的，說明Redis內(nèi)存分配超出了物理內(nèi)存，操作系統(tǒng)正在進(jìn)行內(nèi)存交換。需要增加可用物理內(nèi)存或減少Redis內(nèi)存占用

內(nèi)存使用率
redis實(shí)例的內(nèi)存使用率超過可用最大內(nèi)存，操作系統(tǒng)將開始進(jìn)行內(nèi)存與swap空間交換

避免內(nèi)存交換發(fā)生的方法：
? 針對(duì)緩存數(shù)據(jù)大小選擇安裝Redis 實(shí)例
? 盡可能的使用Hash數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)
? 設(shè)置key的過期時(shí)間

內(nèi)回收key
? 保證合理分配redis有限的內(nèi)存資源

? 當(dāng)達(dá)到設(shè)置的最大閥值時(shí)，需選擇一種key的回收策略，默認(rèn)情況下回收策略是禁止刪除

配置文件中修改maxmemory- policy屬性值

vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
volatile-lru :使用LRU算法從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中淘汰數(shù)據(jù)
volatile-ttl :從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰
volatile-random :從已設(shè)置過期時(shí)間的數(shù)據(jù)集合中隨機(jī)挑選數(shù)據(jù)淘汰
allkeys-lru :使用LRU算法從所有數(shù)據(jù)集合中淘汰數(shù)據(jù)
allkeys-random :從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰
noenviction :禁止淘汰數(shù)據(jù)

總結(jié)

1.redis 是一種非關(guān)數(shù)據(jù)庫(內(nèi)存/緩存)

redis相比于其他非關(guān)數(shù)據(jù)庫優(yōu)勢(shì)的地方主要在于:

①數(shù)據(jù)類型豐富

②持久化(可以將內(nèi)存種的數(shù)據(jù)保存在磁盤中)形式為:RDB與AOF

2.redis 集群模式:哨兵、主從、cluster (集群)

redis的集群模式，同時(shí)也可以理解為是redis的高可用模式

主從: 提供了備份冗余，缺點(diǎn):無法針對(duì)故障進(jìn)行自動(dòng)修復(fù)，寫操作無法負(fù)載均衡

哨兵: 以主從為基礎(chǔ)提供了故障自動(dòng)修復(fù)的功能，寫操作無法負(fù)載均衡

集群: 基于主從基礎(chǔ)，解決了故障自動(dòng)修復(fù)、寫操作負(fù)載均衡的問題，同時(shí)對(duì)于資源需求相較于前兩種集群得到了一定的改善

3.高可用中的持久化

RDB和AOF

(1)持久化方式:

① RDB:周期性的快照

② AOF :接近實(shí)時(shí)的持久化(以everysec方式)

(2) redis 啟用的優(yōu)先級(jí)
AOF>RDB,同時(shí)僅當(dāng)AOF功能關(guān)閉的情況下，redis才會(huì)在重新啟動(dòng)時(shí)使用RDB的方式進(jìn)行恢復(fù)

(3)RDB和AOF中持久化模式

①RDB:

由redis主進(jìn)程(周期性) fork 派生出子進(jìn)程對(duì)redis內(nèi)存中的數(shù)據(jù)進(jìn)行持久化，生成到. rdb文件中
②AOF:

根據(jù)持久化策略(alawys、 no、 everysec (默認(rèn)) )，先將redis中的語句保存在緩沖區(qū)中，再從緩沖

區(qū)同步到.aof文件中

4.redis的恢復(fù)策略/優(yōu)勢(shì)

redis與其他常用非關(guān)數(shù)據(jù)庫類似，都是將數(shù)據(jù)保存在內(nèi)存中;

而保存在內(nèi)存中時(shí)，當(dāng)redis 重啟，內(nèi)存數(shù)據(jù)丟失，但redis 通過RDB或AOF的持久化功能可以在redis 進(jìn)行重啟之后，優(yōu)先讀取AOF文件，基于AOF文件進(jìn)行數(shù)據(jù)恢復(fù)這種方式來“持久化保存"數(shù)據(jù)

本文摘自：https://www.cnblogs.com/

Nosql之redis配置與優(yōu)化2021-09-24 09:21:33