當(dāng)前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

NoSQL（2）之 Redis配置与优化

發(fā)布時間：2024/9/3 数据库 40 豆豆

生活随笔收集整理的這篇文章主要介紹了 NoSQL（2）之 Redis配置与优化小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

文章目錄

一、關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫
- 1.1 關(guān)系型數(shù)據(jù)庫
- 1.2 非關(guān)系型數(shù)據(jù)庫
- 1.3 非關(guān)系型數(shù)據(jù)庫的產(chǎn)生背景
- 1.4 關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫區(qū)別
- - 1.數(shù)據(jù)存儲方式不同
  - 2.擴(kuò)展方式不同
  - 3.對事務(wù)性的支持不同
二、Redis介紹
三、Redis安裝部署
- 3.1 Redis安裝部署具體操作步驟（實操）
- - 1 . 關(guān)閉防火墻和SElinux
  - 2 . 安裝gcc gcc-c++ 編譯器
  - 3 . 將redis-5.0.7.tar.gz 壓縮包上傳到/opt目錄中然后解壓
  - 4 . 進(jìn)入目錄然后直接make
  - 5 . 指定redis的目錄
  - 6 . 執(zhí)行install_server.sh腳本
  - 7 . 優(yōu)化路徑并查端口是否打開
  - 8 . 測試服務(wù)控制命令
  - 9 . 修改配置文件，添加監(jiān)聽的主機地址，其他默認(rèn)已經(jīng)開啟
  - 10 . 重啟redis查看監(jiān)聽的地址
- 3.2 Redis命令工具
- 3.3 redis-cli命令行工具（遠(yuǎn)程登錄）
- 3.4 redis-benchmark 測試工具
- - 示例1：向IP地址為192.168.80.40、端口為6379 的Redis 服務(wù)器發(fā)送100個并發(fā)連接與100000 個請求測試性能。
  - 示例2：測試存取大小為100字節(jié)的數(shù)據(jù)包的性能。
  - 示例3：測試本機上Redis 服務(wù)在進(jìn)行set與lpush操作時的性能。
四、Redis數(shù)據(jù)庫常用命令
- 4.1 常用命令
- 4.3 示例
五、Redis多數(shù)據(jù)庫常用命令
六、Redis持久化
- （一）Redis提供兩種方式進(jìn)行持久化:
- 6.1 觸發(fā)條件
- - （一）手動觸發(fā)
  - （二）自動觸發(fā)
  - （三）其他自動觸發(fā)機制
- 6.2 執(zhí)行流程
- 6.3 啟動時加載
七、AOF持久化
- 7.1 開啟AOF
- 7.2 執(zhí)行流程
- - （一）AOF的執(zhí)行流程包括:
  - - (1) 命令追加 (append)
    - (2) 文件寫入(write) 和文件同步 (sync)
    - (3) 文件重寫 (rewrite)
  - （二）文件重寫能壓縮AOF文件的原因
  - （三）文件重寫的觸發(fā)
  - （四）文件重寫的流程
  - （五）重寫流程注意點
- 7.3 啟動時加載
八、RDB和AOF的優(yōu)缺點
- 8.1 RDB持久化的優(yōu)缺點
- 8.2 AOF持久化的優(yōu)缺點
九、Redis性能管理
- 1 . 查看Redis內(nèi)存使用
- 2 . 內(nèi)存碎片率
- 3 . 跟蹤內(nèi)存碎片率
- 4 . 內(nèi)存使用率
- 5 . 內(nèi)回收key
十、總結(jié)
- 1）數(shù)據(jù)庫
- 2）redis測試工具
- 3）redis數(shù)據(jù)庫命令
- 4）Redis多數(shù)據(jù)庫常用命令
- 5）Redis 高可用
- 6 ) 高可用中的持久化:RDB與AOF
- - (1) 持久化方式：
  - （2）redis啟用的優(yōu)先級
  - （3）RDB和AOF中的持久化模式
- 7 ) redis的恢復(fù)策略/優(yōu)勢

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

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

一個結(jié)構(gòu)化的數(shù)據(jù)庫，創(chuàng)建在關(guān)系模型基礎(chǔ)上
一般面向于記錄
包括：Oracle、MySQL、SQL Server、Microsoft Access、DB2等

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

除了主流的關(guān)系型數(shù)據(jù)庫外的數(shù)據(jù)庫，都認(rèn)為是非關(guān)系型
包括：Redis、MongBD、Hbase、CouhDB等

1.3 非關(guān)系型數(shù)據(jù)庫的產(chǎn)生背景

High performance——對數(shù)據(jù)庫高并發(fā)讀寫需求
Huge Storage——對海量數(shù)據(jù)高效存儲與訪問需求
High Scalability && High Availability——對數(shù)據(jù)庫高可擴(kuò)展性與高可用性需求

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

1.數(shù)據(jù)存儲方式不同

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

關(guān)系型數(shù)據(jù)天然就是表格式的，因此存儲在數(shù)據(jù)表的行和列中。數(shù)據(jù)表可以彼此關(guān)聯(lián)協(xié)作存儲，也很容易提取數(shù)據(jù)。
非關(guān)系型與其相反，數(shù)據(jù)不適合存儲在數(shù)據(jù)表的行和列中，而是大塊組合在一起。非關(guān)系型數(shù)據(jù)通常存儲在數(shù)據(jù)集中，就像文檔、鍵值對或者圖結(jié)構(gòu)。你的數(shù)據(jù)及其特性是選擇數(shù)據(jù)存儲和提取方式的首要影響因素。

2.擴(kuò)展方式不同

SQL和NoSQL數(shù)據(jù)庫最大的差別可能是在擴(kuò)展方式上，要支持日益增長的需求當(dāng)然要擴(kuò)展。

要支持更多并發(fā)量，SQL數(shù)據(jù)庫是縱向擴(kuò)展，也就是說提高處理能力，使用速度更快速的計算機，這樣處理相同的數(shù)據(jù)集就更快了。因為數(shù)據(jù)存儲在關(guān)系表中，操作的性能瓶頸可能涉及很多個表，這都需要通過提高計算機性能來客服。雖然SQL數(shù)據(jù)庫有很大擴(kuò)展空間，但最終肯定會達(dá)到縱向擴(kuò)展的上限。

而NoSQL數(shù)據(jù)庫是橫向擴(kuò)展的。因為非關(guān)系型數(shù)據(jù)存儲天然就是分布式的，NoSQL數(shù)據(jù)庫的擴(kuò)展可以通過給資源池添加更多普通的數(shù)據(jù)庫服務(wù)器(節(jié)點) 來分擔(dān)負(fù)載。

3.對事務(wù)性的支持不同

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

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

二、Redis介紹

官方網(wǎng)址：https://redis.io/

Redis是一個開源的、使用C語言編寫的NoSOL數(shù)據(jù)庫，Redis服務(wù)器程序是單進(jìn)程模型。

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

Redis服務(wù)在一臺服務(wù)器上可以同時啟動多個Redis進(jìn)程，Redis的實際處理速度則是完全依靠于主進(jìn)程的執(zhí)行效率。
若在服務(wù)器上只運行一個Redis進(jìn)程，當(dāng)多個客戶端同時訪問時，服務(wù)器的處理能力是會有一定程度的下降;
若在同一臺服務(wù)器上開啟多個Redis進(jìn)程， Redis在提高并發(fā)處理能力的同時會給服務(wù)器的CPU造成很大壓力。即在實際生產(chǎn)環(huán)境中，需要根據(jù)實際的需求來決定開啟多少個Redis進(jìn)程。
（一般建議開啟2個，用作備份和抗高并發(fā)）

若對高并發(fā)要求更高一些，可能會考慮在同一臺服務(wù)器上開啟多個進(jìn)程。若CPU資源比較緊張，采用單進(jìn)程即可。

三、Redis安裝部署

3.1 Redis安裝部署具體操作步驟（實操）

1 . 關(guān)閉防火墻和SElinux

2 . 安裝gcc gcc-c++ 編譯器

3 . 將redis-5.0.7.tar.gz 壓縮包上傳到/opt目錄中然后解壓

4 . 進(jìn)入目錄然后直接make

5 . 指定redis的目錄

6 . 執(zhí)行install_server.sh腳本

7 . 優(yōu)化路徑并查端口是否打開

8 . 測試服務(wù)控制命令

9 . 修改配置文件，添加監(jiān)聽的主機地址，其他默認(rèn)已經(jīng)開啟

10 . 重啟redis查看監(jiān)聽的地址

3.2 Redis命令工具

redis-server: 用于啟動Redis 的工具
redis-benchmark: 用于檢測Redis在本機的運行效率
redis-check-aof: 修復(fù)AOF持久化文件
redis-check-rdb: 修復(fù)RDB 持久化文件
redis-cli: Redis 命令行工具

rdb 和 aof 是redis服務(wù)中持久化功能的兩種形式！

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

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

redis-cli -h 192.168.80.40 -p 6379

3.4 redis-benchmark 測試工具

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

基本的測試語法: redis-benchmark [選項] [選項值]
-h :指定服務(wù)器主機名。
-p :指定服務(wù)器端口。
-s :指定服務(wù)器socket（套接字）
-c :指定并發(fā)連接數(shù)。
-n :指定請求數(shù)。
-d :以字節(jié)的形式指定 SET/GET 值的數(shù)據(jù)大小。
-k : 1=keep alive 0=reconnect
-r : SET/GET/INCR 使用隨機key, SADD使用隨機值。
-P :通過管道傳輸請求。
-q :強制退出redis。僅顯示query/sec 值。
–csv :以CSV格式輸出。
-l :生成循環(huán)，永久執(zhí)行測試。
-t :僅運行以逗號分隔的測試命令列表。
-I : Idle模式。僅打開 N 個idle連接并等待。

示例1：向IP地址為192.168.80.40、端口為6379 的Redis 服務(wù)器發(fā)送100個并發(fā)連接與100000 個請求測試性能。

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

示例2：測試存取大小為100字節(jié)的數(shù)據(jù)包的性能。

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

示例3：測試本機上Redis 服務(wù)在進(jìn)行set與lpush操作時的性能。

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

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

4.1 常用命令

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

命令（紅色命令）解釋
set 存放數(shù)據(jù)
get 獲取數(shù)據(jù)
keys s * 獲取所有的key
keys s* 以s開頭的數(shù)據(jù)
keys s？以s開頭后面包含任意一位的數(shù)據(jù)
exists aaa 判斷aaa 是否存在（存在：1，不存在：0）
del key 刪除當(dāng)前數(shù)據(jù)庫的key
type key 獲取key對應(yīng)的 value 值類型
rename key1 key2 將key1修改為key2
renamenx key1 key2 將key1修改為key2之前判斷key2是否存在，不存在則重命名
dbsize 查看當(dāng)前數(shù)據(jù)庫中key的數(shù)目

4.3 示例

# rename 命令是對已有key進(jìn)行重命名。 (覆蓋)
命令格式: rename 源key 目標(biāo)key
使用rename命令進(jìn)行重命名時，無論目標(biāo)key是否存在都進(jìn)行重命名，且源key的值會覆蓋目標(biāo)key的值。在實際使用過程中，建議先用 exists命令查看目標(biāo)key是否存在，然后再決定是否執(zhí)行rename命令，以避免覆蓋重要數(shù)據(jù)。

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

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

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

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

#多數(shù)據(jù)庫間切換
命令格式: select 序號
使用 redis-cli 連接Redis數(shù)據(jù)庫后，默認(rèn)使用的是序號為 0 的數(shù)據(jù)庫。
127.0.0.1:6379> select 10 #切換至序號為10的數(shù)據(jù)庫

127.0.0.1:6379[10]> select 15 #切換至序號為15的數(shù)據(jù)庫

127.0.0.1:6379[15]> select 0 #切換至序號為0的數(shù)據(jù)庫

示例：

#多數(shù)據(jù)庫間移動數(shù)據(jù)
格式: move 鍵值序號

127.0.0.1:6379> set tete1 100
OK
127.0.0.1:6379> get tete1
“100”
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> get tete1
(nil)
127.0.0.1:6379[1]> select 0 #切換至目標(biāo)數(shù)據(jù)庫0
OK
127.0.0.1:6379> get tete1 #查看目標(biāo)數(shù)據(jù)是否存在
“100”
127.0.0.1:6379> move tete1 1 #將數(shù)據(jù)庫0中tete1移動到數(shù)據(jù)庫1中
(integer) 1
127.0.0.1:6379> select 1 #切換至目標(biāo)數(shù)據(jù)庫1
OK
127.0.0.1:6379[1]> get tete1 #查看被移動數(shù)據(jù)
“100”
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> get tete1 #在數(shù)據(jù)庫0中無法查看到tete1的值
(nil)

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

在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時間，衡量的標(biāo)準(zhǔn)是在多長時間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999%等等)。但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(wù)(如主從分離、快速容災(zāi)技術(shù))，還需要考慮數(shù)據(jù)容量的擴(kuò)展，數(shù)據(jù)安全不會丟失等。

在Redis中，實現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和集群，作用如下：

持久化 :持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲在硬盤，保證數(shù)據(jù)不會因進(jìn)程退出而丟失。
主從復(fù)制 :主從復(fù)制是高可用Redis的基礎(chǔ)，哨兵和集群都是在主從復(fù)制基礎(chǔ)上實現(xiàn)高可用的。主從復(fù)制主要實現(xiàn)了數(shù)據(jù)的多機備份，以及對于讀操作的負(fù)載均衡和簡單的故障恢復(fù)。缺陷:故障恢復(fù)無法自動化;寫操作無法負(fù)載均衡;存儲能力受到單機的限制。
哨兵 :在主從復(fù)制的基礎(chǔ)上，哨兵實現(xiàn)了自動化的故障恢復(fù)。缺陷 :寫操作無法負(fù)載均衡;存儲能力受到單機的限制。
集群 : 通過集群， Redis解決了寫操作無法負(fù)載均衡，以及存儲能力受到單機限制的問題，實現(xiàn)了較為完善的高可用方案。

六、Redis持久化

持久化的功能 :
Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中，為了避免服務(wù)器斷電等原因?qū)е翿edis進(jìn)程異常退出后數(shù)據(jù)的永久丟失，需要定期將Redis中的數(shù)據(jù)以某種形式(數(shù)據(jù)或命令)從內(nèi)存保存到硬盤;當(dāng)下次Redis重啟時，利用持久化文件實現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個遠(yuǎn)程位置。

（一）Redis提供兩種方式進(jìn)行持久化:

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

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

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

6.1 觸發(fā)條件

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

（一）手動觸發(fā)

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

（二）自動觸發(fā)

在自動觸發(fā)RDB持久化時，Redis也會選擇bgsave而不是save來進(jìn)行持久化。

save m n #通過配置設(shè)置觸發(fā)

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

vim /etc/redis/6379.conf

-----219行–以下三個save條件滿足任意一個時，都會引起bgsave的調(diào)用
save 900 1 :當(dāng)時間到900秒時，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave
save 300 10 :當(dāng)時間到300秒時，如果redis數(shù)據(jù)發(fā)生了至少10次變化，則執(zhí)行bgsave
save 60 10000 :當(dāng)時間到60秒時，如果redis數(shù)據(jù)發(fā)生了至少10000次變化，則執(zhí)行bgsave

-----242行–是否開啟RDB文件壓縮
rdbcompression yes

-----254行–指定RDB文件名
dbfilename dump.rdb

-----264行–指定RDB文件和AOF文件所在目錄
dir /var/lib/redis/6379

（三）其他自動觸發(fā)機制

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

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

6.2 執(zhí)行流程

Redis父進(jìn)程首先判斷 :當(dāng)前是否在執(zhí)行save，或bgsave/bgrewriteaof的子進(jìn)程，如果在執(zhí)行則bgsave命令直接返回。bgsave/bgrewriteaof 的子進(jìn)程不能同時執(zhí)行，主要是基于性能方面的考慮:兩個并發(fā)的子進(jìn)程同時執(zhí)行大量的磁盤寫操作，可能引起嚴(yán)重的性能問題。
父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，這個過程中父進(jìn)程是阻塞的，Redis不能執(zhí)行來自客戶端的任何命令
父進(jìn)程fork后，bgsave 命令返回”Background saving started" 信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令
子進(jìn)程創(chuàng)建RDB文件，根據(jù)父進(jìn)程內(nèi)存快照生成臨時快照文件，完成后對原有文件進(jìn)行原子替換
子進(jìn)程發(fā)送信號給父進(jìn)程表示完成，父進(jìn)程更新統(tǒng)計信息

6.3 啟動時加載

RDB文件的載入工作是在服務(wù)器啟動時自動執(zhí)行的，并沒有專門的命令。但是由于A0F的優(yōu)先級更高，因此當(dāng)AOF開啟時，Redis會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù);只有當(dāng)A0F關(guān)閉時，才會在Redis服務(wù)器啟動時檢測RDB文件，并自動載入。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。

Redis載入RDB文件時，會對RDB文件進(jìn)行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。

七、AOF持久化

? RDB持久化是將進(jìn)程數(shù)據(jù)寫入文件，而AOF持久化，則是將Redis執(zhí)行的每次寫、刪除命令記錄到單獨的日志文件中，查詢操作不會記錄; 當(dāng)Redis重啟時再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。

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

7.1 開啟AOF

Redis服務(wù)器默認(rèn)開啟RDB，關(guān)閉AOF的，要開啟AOF，需要在/etc/ redis/6379.conf配置文件中配置。

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 #重啟redis

7.2 執(zhí)行流程

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

（一）AOF的執(zhí)行流程包括:

● 命令追加(append): 將Redis的寫命令追加到緩沖區(qū)aof_ buf;
● 文件寫入(write)和文件同步(sync):根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤;
● 文件重寫(rewrite): 定期重寫AOF文件，達(dá)到壓縮的目的。

(1) 命令追加 (append)

Redis先將寫命令追加到緩沖區(qū)，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤，導(dǎo)致硬盤IO成為Redis負(fù)載的瓶頸。
命令追加的格式是Redis命令請求的協(xié)議格式，它是一種純文本格式，具有兼容性好、可讀性強、容易處理、操作簡單避免二次開銷等優(yōu)點。在A0F文件中，除了用于指定數(shù)據(jù)庫的select命令 (如select0為選中0號數(shù)據(jù)庫) 是由Redis添加的，其他都是客戶端發(fā)送來的寫命令。

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

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

為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中，當(dāng)用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時，操作系統(tǒng)通常會將數(shù)據(jù)暫存到一個內(nèi)存緩沖區(qū)里，當(dāng)緩沖區(qū)被填滿或超過了指定時限后，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里。這樣的操作雖然提高了效率，但也帶來了安全問題:如果計算機停機，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會丟失;因此系統(tǒng)同時提供了fsync、fdatasync等同步函數(shù)，可以強制操作系統(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)，每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。

● appendfsync no:
解釋：命令寫入aof_ buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步;
同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為30秒。這種情況下，文件同步的時間不可控，
且緩沖區(qū)中堆積的數(shù)據(jù)會很多，數(shù)據(jù)安全性無法保證。

● appendfsynceverysec:
解釋：命令寫入aof_ buf后調(diào)用系統(tǒng)write操作，write完成后線程返回;
fsync同步文件操作由專門的線程每秒調(diào)用一次。
everysec是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，
因此是Redis的默認(rèn)配置，也是我們推薦的配置。

(3) 文件重寫 (rewrite)

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

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

關(guān)于文件重寫需要注意的另一點是：對于AOF持久化來說，文件重寫雖然是強烈推薦的，但并不是必須的；即使沒有文件重寫，數(shù)據(jù)也可以被持久化并在Redis啟動的時候?qū)?#xff1a;因此在一些實現(xiàn)中，會關(guān)閉自動的文件重寫，然后通過定時任務(wù)在每天的某一時刻定時執(zhí)行。

（二）文件重寫能壓縮AOF文件的原因

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

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

（三）文件重寫的觸發(fā)

文件重寫的觸發(fā)，分為手動觸發(fā)和自動觸發(fā)

手動觸發(fā)：直接調(diào)用bgrewriteaof命令，該命令的執(zhí)行與bgsave有些類似：都是fork子進(jìn)程進(jìn)行具體的工作，且都只有在fork時阻塞。
自動觸發(fā)：通過設(shè)置auto-aof - rewrite-min-size選項和auto- aof - rewrite- percentage選項來自動執(zhí)行BGREWRITEAOF
只有當(dāng)auto-aof- rewrite- -min-size和auto-aof -rewrite-percentage兩個選項同時滿足時，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作。

vim /etc/redis/ 6379. conf

----729----
● auto-aof- rewrite-percentage 100
當(dāng)前AOF文件大小(即aof_current_size)是上次日志重寫時AOF文件大小(aof_base_size)兩倍時，
發(fā)生BGREWRITEAOF操作

● auto-aof - rewrite-min-size 64mb
當(dāng)前A0F文件執(zhí)行BGREWRITEAOF命令的最小值，避免剛開始啟動Reids時由于文件尺寸較小導(dǎo)致頻繁的BGREWRITEAOF

（四）文件重寫的流程

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

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

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

由于fork操作使用寫時復(fù)制技術(shù)，子進(jìn)程只能共享fork操作時的內(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的寫命令同時追加到aof_ buf和aof_ rewirte_ buf兩個緩沖區(qū)。

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

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

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

使用新的AOF文件替換老文件，完成AOF重寫。

（五）重寫流程注意點

(1) 重寫由父進(jìn)程fork子進(jìn)程進(jìn)行;

(2) 重寫期間Redis執(zhí)行的寫命令，需要追加到新的AOF文件中，為此Redis引入了aof_ rewrite_buf緩存。

7.3 啟動時加載

當(dāng)AOF開啟時，Redis啟動時會優(yōu)先載入AOF文件來恢復(fù)數(shù)據(jù);只有當(dāng)AOF關(guān)閉時，才會載入RDB文件恢復(fù)數(shù)據(jù)。
當(dāng)AOF開啟，但AOF文件不存在時，即使RDB文件存在也不會加載。
Redis載入AOF文件時，會對AOF文件進(jìn)行校驗，如果文件損壞，則日志中會打印錯誤，Redis啟動失敗。但如果是AOF文件結(jié)尾不完整 (機器突然宕機等容易導(dǎo)致文件尾部不完整)，且aof-load- truncated參數(shù)開啟，則日志中會輸出警告，Redis 忽略掉AOF文件的尾部，啟動成功。
aof-load-truncated參數(shù)默認(rèn)是開啟的。

八、RDB和AOF的優(yōu)缺點

8.1 RDB持久化的優(yōu)缺點

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

缺點：RDB文件的致命缺點在于其數(shù)據(jù)快照的持久化方式?jīng)Q定了必然做不到實時持久化，而在數(shù)據(jù)越來越重要的今天，數(shù)據(jù)的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB文件需要滿足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。
對于RDB持久化，一方面是bgsave在進(jìn)行fork操作時Redis主進(jìn)程會阻塞，另一方面，子進(jìn)程向硬盤寫數(shù)據(jù)也會帶來IO壓力。

8.2 AOF持久化的優(yōu)缺點

與RDB持久化相對應(yīng)，AOF的優(yōu)點在于支持秒級持久化、兼容性好，缺點是文件大、恢復(fù)速度慢、對性能影響大。
對于AOF持久化，向硬盤寫數(shù)據(jù)的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題。
AOF文件的重寫與RDB的bgsave類似，會有fork時的阻塞和子進(jìn)程的I0壓力問題。相對來說，由于AOF向硬盤中寫數(shù)據(jù)的頻率更高，因此對Redis主進(jìn)程性能的影響會更大。

九、Redis性能管理

1 . 查看Redis內(nèi)存使用

192.168.9.236: 7001> info memory

2 . 內(nèi)存碎片率

操作系統(tǒng)分配的內(nèi)存值used_ memory_ rss除以Redis使用的內(nèi)存值used_ memory計算得出內(nèi)存碎片是由操作系統(tǒng)低效的分配/回收物理內(nèi)存導(dǎo)致的 (不連續(xù)的物理內(nèi)存分配)

3 . 跟蹤內(nèi)存碎片率

跟蹤內(nèi)存碎片率對理解Redis實例的資源性能是非常重要的:

內(nèi)存碎片率稍大于1是合理的，這個值表示內(nèi)存碎片率比較低
內(nèi)存碎片率超過1.5，說明Redis消耗了實際需要物理內(nèi)存的150號，其中50號是內(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)存占用。

4 . 內(nèi)存使用率

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

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

5 . 內(nèi)回收key

保證合理分配redis有限的內(nèi)存資源。

當(dāng)達(dá)到設(shè)置的最大閥值時，需選擇一種key的回收策略，默認(rèn)情況下回收策略是禁止刪除。
配置文件中修改maxmemory- policy屬性值：

vim /etc/redis/6379.conf

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

十、總結(jié)

1）數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫：實例–>數(shù)據(jù)庫–>表(table)–>記錄行(row)、數(shù)據(jù)字段(column)
非關(guān)系型數(shù)據(jù)庫：實例–>數(shù)據(jù)庫–>集合(collection) -->鍵值對(key-value)
非關(guān)系型數(shù)據(jù)庫不需要手動建數(shù)據(jù)庫和集合(表)

2）redis測試工具

Redis命令工具中的 rdb 和 aof 是redis服務(wù)中持久化功能的兩種形式！
redis-cli命令行工具（遠(yuǎn)程登錄）；
redis-benchmark 測試工具（有效的測試 Redis 服務(wù)的性能）

3）redis數(shù)據(jù)庫命令

set 、get和del ：存放、獲取和刪除數(shù)據(jù)
keys：獲取key，可以結(jié)合通配符 * 和？
exists和type：判斷key是否存在和判斷類型
rename和renamenx：重命名的兩種，后者會進(jìn)行判斷，存在則不改
dbsize：查看當(dāng)前數(shù)據(jù)庫中key的數(shù)目

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

select 序號：切換庫名(16個數(shù)據(jù)庫，數(shù)據(jù)庫名稱是用數(shù)字0-15)
move 鍵值序號：多數(shù)據(jù)庫間移動數(shù)據(jù)
FLUSHDB ：清空當(dāng)前數(shù)據(jù)庫數(shù)據(jù)
FLUSHALL ：清空所有數(shù)據(jù)庫的數(shù)據(jù)，慎用!

5）Redis 高可用

含義：高可用是指服務(wù)器可以正常訪問的時間，衡量的標(biāo)準(zhǔn)是在多長時間內(nèi)可以提供正常服務(wù)。
組成：實現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和集群。

6 ) 高可用中的持久化:RDB與AOF

(1) 持久化方式：

①RDB：周期性的快照
②AOF：接近實時的持久化（以everysec方式）

（2）redis啟用的優(yōu)先級

AOF > RDB 同時僅當(dāng)AOF功能關(guān)閉的情況下，redis才會再重新啟動時使用RDB的方式進(jìn)行恢復(fù)

（3）RDB和AOF中的持久化模式

①RDB：由redis主進(jìn)程（周期性）fork派生出子進(jìn)程對redis內(nèi)存中的數(shù)據(jù)進(jìn)行持久化，生成到.rdb文件中.
②AOF：根據(jù)持久化策略（alawys、no、everysec（默認(rèn)）），先將redis中的語句保存在緩存區(qū)中，再從緩沖區(qū)同步到.aof文件中.

7 ) redis的恢復(fù)策略/優(yōu)勢

redis與其他常用非關(guān)數(shù)據(jù)庫類似，都是將數(shù)據(jù)保存在內(nèi)存中
而保存在內(nèi)存中時，當(dāng)redis重啟，內(nèi)存數(shù)據(jù)丟失，但redis通過RDB或AOF的持久化功能可以在redis進(jìn)行重啟之后，優(yōu)先讀取AOF文件，基于AOF文件進(jìn)行數(shù)據(jù)恢復(fù)這種方式來“持久化保存”數(shù)據(jù)。

總結(jié)

以上是生活随笔為你收集整理的NoSQL（2）之 Redis配置与优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

Redis
NoSQL

上一篇： NoSQL（1）之 Redis的五大数据
下一篇： NoSQL(3) 之Redis主从复制、

数据库

NoSQL（2）之 Redis配置与优化

文章目錄

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

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

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

1.3 非關(guān)系型數(shù)據(jù)庫的產(chǎn)生背景

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

1.數(shù)據(jù)存儲方式不同

2.擴(kuò)展方式不同

3.對事務(wù)性的支持不同

二、Redis介紹

三、Redis安裝部署

3.1 Redis安裝部署具體操作步驟（實操）

1 . 關(guān)閉防火墻和SElinux

2 . 安裝gcc gcc-c++ 編譯器

3 . 將redis-5.0.7.tar.gz 壓縮包上傳到/opt目錄中然后解壓

4 . 進(jìn)入目錄然后直接make

5 . 指定redis的目錄

6 . 執(zhí)行install_server.sh腳本

7 . 優(yōu)化路徑并查端口是否打開

8 . 測試服務(wù)控制命令

9 . 修改配置文件，添加監(jiān)聽的主機地址，其他默認(rèn)已經(jīng)開啟

10 . 重啟redis查看監(jiān)聽的地址

3.2 Redis命令工具

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

3.4 redis-benchmark 測試工具

示例1：向IP地址為192.168.80.40、 端口為6379 的Redis 服務(wù)器發(fā)送100個并發(fā)連接與100000 個請求測試性能。

示例2：測試存取大小為100字節(jié)的數(shù)據(jù)包的性能。

示例3：測試本機上Redis 服務(wù)在進(jìn)行set與lpush操作時的性能。

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

4.1 常用命令

4.3 示例

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

六、Redis持久化

（一）Redis提供兩種方式進(jìn)行持久化:

6.1 觸發(fā)條件

（一）手動觸發(fā)

（二）自動觸發(fā)

（三）其他自動觸發(fā)機制

6.2 執(zhí)行流程

6.3 啟動時加載

七、AOF持久化

7.1 開啟AOF

7.2 執(zhí)行流程

（一）AOF的執(zhí)行流程包括:

(1) 命令追加 (append)

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

(3) 文件重寫 (rewrite)

（二）文件重寫能壓縮AOF文件的原因

（三）文件重寫的觸發(fā)

（四）文件重寫的流程

（五）重寫流程注意點

7.3 啟動時加載

八、RDB和AOF的優(yōu)缺點

8.1 RDB持久化的優(yōu)缺點

8.2 AOF持久化的優(yōu)缺點

九、Redis性能管理

1 . 查看Redis內(nèi)存使用

2 . 內(nèi)存碎片率

3 . 跟蹤內(nèi)存碎片率

4 . 內(nèi)存使用率

5 . 內(nèi)回收key

十、總結(jié)

1）數(shù)據(jù)庫

2）redis測試工具

3）redis數(shù)據(jù)庫命令

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

5）Redis 高可用

6 ) 高可用中的持久化:RDB與AOF

(1) 持久化方式：

（2）redis啟用的優(yōu)先級

（3）RDB和AOF中的持久化模式

7 ) redis的恢復(fù)策略/優(yōu)勢

總結(jié)

示例1：向IP地址為192.168.80.40、端口為6379 的Redis 服務(wù)器發(fā)送100個并發(fā)連接與100000 個請求測試性能。