NoSQL之Redis的配置優化
技術標籤：redis
Redis配置檔案
配置引數(/etclredis/6379.conf)
- bind:監聽的主機地址
- port:埠
- daemonize yes:啟用守護程序
- pidfile:指定PID檔案
- loglevel notice:日誌級別
- logfile:指定日誌檔案
Redis資料庫常用命令
redis-cli命令列工具
- 連線本地資料庫
[[email protected] utils]# /usr/local/redis/bin/redis-cli
127.0.0.1:6379>- 連線遠端資料庫
[[email protected] utils]#t redis-cli -h 192.168 Redis 命令工具
- redis-server:用於啟動Redis的工具
- redis-benchmark:用於檢測Redis在本機的執行效率
- redis-check-aof:修復 AOF持久化檔案
- redis-check-rdb:修復 RDB 持久化檔案
- redis-cli:是Redis命令列工具
- redis-setinel:是哨兵模式啟動的工具
命令列選項
- h:指定伺服器主機名。
- p:指定伺服器埠。
- s:指定伺服器 socket。
- c:指定併發連線數。
- n:指定請求數。
- -d:以位元組的形式指定SET/GET 值的資料大小。
- k: 1=keep alive 0=reconnect 。
- r: SET/GETINCR 使用隨機key,SADD使用隨機值。
- p:通過管道傳輸請求。
- q:強制退出redis。僅顯示query/sec值。
- –csv: 以CSV 格式輸出。
- l:生成迴圈，永久執行測試。
- t:僅執行以逗號分隔的測試命令列表。
- l:idle模式。僅開啟N個idle連線並等待。
[[email protected] ~]# redis-benchmark -h 20.0.0.15 -p 6379 -c 100 -n 100000[[email protected] ~]# redis-benchmark -h 20.0.0.15 -p 6379 -q -d 100[[email protected] key相關命令
- keys:獲取符合規則的鍵值列表
- exists:判斷鍵值是否存在
- del:刪除當前資料庫的指定key
- type:獲取key對應的value值型別
- rename(覆蓋)/ renamenx(不覆蓋):對已有的key進行重新命名
- dbsize:檢視當前資料庫中key的數目
1：檢視以 s 開頭的
20.0.0.15:6379> keys s*
1) "set1"2：檢視關鍵詞是否存在（1代表存在，0代表不存在）
20.0.0.15:6379> exists hash
(integer) 0
20.0.0.15:6379> exists hash1
(integer) 13：刪除關鍵詞
20.0.0.15:6379> del hash1
(integer) 14： 獲取key 對應的 value 值型別
20.0.0.15:6379> set string 55
OK
20.0.0.15:6379> type string
string5：對已有 key 進行重新命名
rename命令進行重新命名時，無論目標key是否存在都進行重新命名，且源key 的值會覆蓋目標key 的值。在實際使用過程中，建議先用exists命令檢視目標 key是否存在，然後再決定是否執行rename命令，以避免覆蓋重要資料
20.0.0.15:6379> set aaa 1 #已存在
OK
20.0.0.15:6379> set bbb 2 #已存在
OK
20.0.0.15:6379> rename aaa bbb #重新命名
OK
20.0.0.15:6379> get bbb
"1"6：對已有 key 進行重新命名
其命令格式與 rename 的命令格式除命令關鍵字不同外基本相同，renamenx源key目標key。使用renamenx命令進行重新命名時，如果目標key 存在則不進行重新命名
20.0.0.15:6379> set aaa 10
OK
20.0.0.15:6379> renamenx aaa bbb
(integer) 0Redis多資料庫操作
1：Redis支援多資料庫，預設支援16個數據庫，0-15命名
2：多資料庫相互獨立,互不干擾
3：多資料庫常用命令
- 多資料庫間切換
- 多資料庫間移動資料
- 清除資料庫內資料
Redis持久化
持久化概述
- Redis是執行在記憶體中，記憶體中的資料斷電丟失
- 為了能夠重用Redis資料，或者防止系統故障，需要將Redis中的資料寫入到磁碟空間中，即持久化
持久化分類
- RDB方式:建立快照的方式獲取某一時刻Redis中所有資料的副本
- AOF方式:將執行的寫命令寫到檔案的末尾，以日誌的方式來記錄資料的變化
二者區別
- RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，實際操作過程是fork一個子程序，先將資料集寫入臨時檔案，寫入成功後，再替換之前的檔案，用二進位制壓縮儲存。
- AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文字的方式記錄，可以開啟檔案看到詳細的操作記錄。
二者優缺點
RDB存在的優勢
-
一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這對於檔案備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的資料，同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
-
對於災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。
-
效能最大化。對於Redis的服務程序而言，在開始持久化時，它唯一需要做的只是fork出子程序，之後再由子程序完成這些持久化的工作，這樣就可以極大的避免服務程序執行IO操作了。
-
相比於AOF機制，如果資料集很大，RDB的啟動效率會更高。
RDB存在的劣勢
- 如果你想保證資料的高可用性，即最大限度的避免資料丟失，那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁碟的資料都將丟失。
- 由於RDB是通過fork子程序來協助完成資料持久化工作的，因此，如果當資料集較大時，可能會導致整個伺服器停止服務幾百毫秒，甚至是1秒鐘。
AOF存在的優勢
-
該機制可以帶來更高的資料安全性，即資料永續性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是非同步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的資料將會丟失。而每修改同步，我們可以將其視為同步持久化，即每次發生的資料變化都會被立即記錄到磁碟中。可以預見，這種方式在效率上是最低的。至於無同步，無需多言，我想大家都能正確的理解它。
-
由於該機制對日誌檔案的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日誌檔案中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決資料一致性的問題。
-
如果日誌過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中，同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。
-
AOF包含一個格式清晰、易於理解的日誌檔案用於記錄所有的修改操作。事實上，我們也可以通過該檔案完成資料的重建。
AOF存在的劣勢
-
對於相同數量的資料集而言，AOF檔案通常要大於RDB檔案。RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。
-
根據同步策略的不同，AOF在執行效率上往往會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。
Redis持久化
持久化概述
- Redis是執行在記憶體中，記憶體中的資料斷電丟失
- 為了能夠重用Redis資料，或者防止系統故障，需要將Redis中的資料寫入到磁碟空間中，即持久化
持久化分類
- RDB方式:建立快照的方式獲取某一時刻Redis中所有資料的副本
- AOF方式:將執行的寫命令寫到檔案的末尾，以日誌的方式來記錄資料的變化
RDB持久化
觸發條件
- 在指定的時間間隔內，執行指定次數的寫操作(配置檔案控制)
- 執行save或者是bgsave (非同步)命令
- 執行flushall命令，清空資料庫所有資料
- 執行shutdown命令，保證伺服器正常關閉且不丟失任何資料
優缺點
- 適合大規模的資料恢復
- 如果業務對資料完整性和一致性要求不高，RDB是很好的選擇
- 資料的完整性和一致性不高
- 備份時佔用記憶體
通過RDB檔案恢復資料
- 將dump.rdb 檔案拷貝到redis的安裝目錄的bin目錄下，重啟redis服務即可
配置檔案選項
vim letc/redis/6379.conf
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis/6379
rdbcompression yes- 900秒之內至少—次寫操作、300秒之內至少發生10次寫操作、60秒之內發生至少10000次寫操作，只要滿足其一都會觸發快照操作，註釋所有的save項表示關閉RDB
AOF持久化
1：Redis預設不開啟
2：彌補RDB的不足（資料的不一致性)
3：採用日誌的形式來記錄每個寫操作,並追加到檔案中
4：Redis重啟會根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作
[[email protected] ~]# vi /etc/redis/6379.conf
appendonly yes #開啟 AOF持久化
appendfsync always
[[email protected] ~]# /etc/init.d/redis_6379 restart
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
[[email protected] ~]# cd /var/lib/redis/6379/
[[email protected] 6379]# ll
總用量 244
-rw-r--r--. 1 root root 0 12月 17 15:12 appendonly.aof
-rw-r--r--. 1 root root 248033 12月 17 15:12 dump.rdb5：AOF的重寫機制
-
AOF的工作原理是將寫操作追加到檔案中，檔案的冗餘內容會越來越多
-
當AOF檔案的大小超過所設定的閾值時，Redis就會對AOF檔案的內容壓縮
6：AOF重寫的原理
- Redis會fork出一條新程序，讀取記憶體中的資料（並沒有讀取舊檔案)，並重新寫到一個臨時檔案中，最後替換舊的aof檔案
Redis效能管理
記憶體碎片率
1：操系統分配的記憶體值used_memory_rss除以Redis使用的記憶體值used_memory計算得出
2：記憶體碎片是由作業系統低效的分配/回收物理記憶體導致的
- 不連續的實體記憶體分配
3：跟蹤記憶體碎片率對理解Redis例項的資源效能是非常重要的
- 記憶體碎片率稍大於1是合理的，這個值表示記憶體碎片率比較低
- 記憶體碎片率超過1.5，說明Redis消耗了實際需要實體記憶體的150%，其中50%是記憶體碎片率
- 記憶體碎片率低於1的，說明Redis記憶體分配超出了實體記憶體，作業系統正在進行記憶體交換
記憶體使用率
1：redis例項的記憶體使用率超過可用最大記憶體，作業系統將開始進行記憶體與swap空間交換
2：避免記憶體交換
- 針對快取資料大小選擇
- 儘可能的使用Hash資料結構
- 設定key的過期時間
回收key
1：保證合理分配redis有限的記憶體資源
2：當達到設定的最大閥值時，需選擇一種key的回收策略
- 預設情況下回收策略是禁止刪除
- redis.conf配置檔案中修改maxmemory-policy屬性值
volatile-lru:使用LRU演算法從已設定過期時間的資料集合中淘汰資料
volatile-ttl:從已設定過期時間的資料集合中挑選即將過期的資料淘汰
volatile-random:從已設定過期時間的資料集合中隨機挑選資料淘汰
allkeys-Iru:使用LRU演算法從所有資料集合中淘汰資料
allkeys-random :從資料集合中任意選擇資料淘汰
no-enviction:禁止淘汰資料
[[email protected] ~]# vi /etc/redis/6379.conf
# maxmemory-policy noeviction #修改
maxmemory-policy volatile-lru
[[email protected] ~]# /etc/init.d/redis_6379 restart