目? ?錄
CONFIG動態修改配置
慢查詢
持久化
在上一篇主要對redis的了解入門，安裝，以及基礎配置，多實例的實現：redis的安裝看我上一篇：
Redis安裝部署與使用,多實例
redis是擋在MySQL前面的，運行在內存中的，速度就快，單線程的。
redis的一些基礎配置：
在上一篇redis介紹中，介紹了bind配置，使得遠端主機能夠登錄本機redis。密碼requirepass的設置，以及多實例基于端口號port的配置，pid文件pidfile，日志文件logfile，工作目錄dbfilename配置。
bind 0.0.0.0 #監聽地址，可以用空格隔開后多個監聽IP
port 6379 #監聽端口,默認6379/tcp
tcp-keepalive 300 #tcp 會話保持時間300s
daemonize no #默認no,即直接運行redis-server程序時,不作為守護進程運行，而是以前臺方式運行，如果想在后臺運行需改成yes,當redis作為守護進程運行的時候，它會寫一個 pid 到/var/run/redis.pid 文件
pidfile /var/run/redis_6379.pid #pid文件路徑,可以修改為/apps/redis/run/redis_6379.pid
loglevel notice #日志級別
logfile "/path/redis.log" #日志路徑,示例:logfile "/apps/redis/log/redis_6379.log"databases 16 #設置數據庫數量，默認：0-15，共16個庫save 900 1 #在900秒內有1個key內容發生更改,就執行快照機制
save 300 10 #在300秒內有10個key內容發生更改,就執行快照機制
save 60 ?10000 ?#60秒內如果有10000個key以上的變化，就自動快照備份rdbcompression yes #持久化到RDB文件時，是否壓縮，"yes"為壓縮，"no"則反之
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路徑，示例：dir "/apps/redis/data"
maxclients 10000 #Redis最大連接客戶端
appendfilename "appendonly.aof" #文本文件AOF的文件名，存放在dir指令指定的目錄中
appendfsync everysec
#aof持久化策略的配置
#no表示由操作系統保證數據同步到磁盤,Linux的默認fsync策略是30秒，最多會丟失30s的數據
#always表示每次寫入都執行fsync，以保證數據同步到磁盤,安全性高,性能較差
#everysec表示每秒執行一次fsync，可能會導致丟失這1s數據,此為默認值,也生產建議值auto-aof-rewrite-min-size 64mb #觸發aof rewrite的最小文件大小
cluster-enabled yes #是否開啟集群模式，默認不開啟,即單機模式
CONFIG動態修改配置
config命令用于查看當前redis配置、以及不重啟redis服務實現動態更改redis配置等
注意：不是所有配置都可以動態修改，且此方式無法持久保存
CONFIG SET <parameter> <value>
config set 參數 值
config set 參數值。時間復雜度是O(1)。CONFIG SET 命令可以動態調整redis服務器的配置(confuiguration)而無須重啟。
也可以使用它修改配置參數，或者改變redis的持久化（persistence）方式
CONFIG SET 可以修改的配置命令可以使用命令CONFIG GET * 來列出來，所有被CONFIG SET 修改的配置參數都會立即生效。
CONFIG GET 命令用于取得運行中的redis服務器的配置參數(configuration parameters)，在redis2.4版本中，有部分參數沒有辦法用config get訪問，但是在最新的Redis2.6版本中，所有配置參數都已經可以用config get訪問了。
config get 接受單個參數parameter作為搜索關鍵字，查找到所有匹配的配置參數，其中參數和值以鍵值對的方式排列。
比如執行config get s* 命令，服務器會返回所有以s開頭的配置參數及參數值的。
案例：
登錄redis：
[root@Node1 ~]#:redis-cli
?使用動態方式查看日志文件路徑：
查看以lo開頭的配置項：
顯示出了有日志文件路徑，和日志級別。
相當于：Python中以字典的形式存儲
{logfile:"/apps/redis/log/redis.log",loglevel:"notice"}config設置密碼：
127.0.0.1:6379> config set requirepass 12321
OK
?可以看到，必須使用密碼登錄，-a選項
設置空密碼：
慢查詢
執行命令，有發送命令，排隊等待命令的執行，執行命令，返回結果。
慢查詢發生在第3階段，客戶端超時不一定慢查詢，但是慢查詢時客戶端超時的一個可能因素。
范例：slowlog。修改兩條配置：
slowlog-log-slower-than 1 ???#指定為超過1us即為慢的指令
slowlog-max-len 1024 ????????#指定保存1024條慢記錄
?指定為超過1微妙即為慢的指令
指定保存1024條慢記錄
?查看慢查詢具體情況，看前兩條
發現記錄了我們輸入命令查詢的語句。
如果get后面不加數字，就是查看全部：
數據庫：切換使用select 0,select 1。。。 當前默認是0，
進入數據庫使用select 1
在當前設置鍵值：
切換到數據庫1：
獲取不到在0上的name。再切換回去就有了
在1上也設置一個name：
使用flushdb命令可以清空當前的數據庫
flushall清空所有的數據庫
這里清空之后我們再重新設置一個name，叫python。去0上查看name為linux。執行flushall命令清空所有，再回來1上，查看name=python是否被清空。
flushdb清空當前數據庫，flushall清空所有數據庫。
持久化
redis雖然是一個內存級別的緩存程序，也就是redis是使用內存進行數據的緩存的，但是其可以將內存的數據按照一定的策略保存到硬盤上，從而實現數據持久保存的目的，目前支持redis支持兩種不同的方式的數據持久化保存機制，分別是RDB和AOF。
持久化的功能：redis是內存數據庫，所有數據都是保存在內存中，為了避免服務器斷點等原因導致redis進程異常退出后數據永久丟失，需要定期將redis中的數據以某種形式(數據或者命令)從內存中保存到硬盤上，當下次redis重啟時，利用持久化文件實現數據恢復，除此之外為了進行災難備份，可以持久化將文件拷貝到一個遠程位置(如備份服務器)。
redis提供兩種方式進行持久化：
RDB持久化：原理是將redis在內存中的數據庫記錄，定時保存到磁盤上，類似于快照。
AOF持久化：原理是將redis的操作日志以追加的方式寫入文件，類似于mysql的binlog
由于AOF持久性實時性更好，即發生特殊情況導致數據丟失時，丟失的數據更少，因此是目前主流的持久化方式，不過RDB持久化仍然具有可用性。
保存持久化：
當一個鍵設置了多個值，那么get獲取鍵時對應的值就是最近一次的修改。
127.0.0.1:6379> set name linux
OK
127.0.0.1:6379> set name linux1
OK
127.0.0.1:6379> set name linux2
OK
127.0.0.1:6379> get name
"linux2"
127.0.0.1:6379>那么前面設置的兩個值就會殘留。占用空間。使用save可以保存持久化。還有一個是bgsave，它不會影響操作，后臺執行，不影響操作。重寫機制會把最近的記錄下載，也就是記錄linux3。
建議使用bgsave
持久化中：
dir ./ #快照文件保存路徑，示例：dir "/apps/redis/data"。如果不指定，在登錄redis時，save會出現錯誤
dbfilename dump.rdb #快照文件名
appendfilename "appendonly.aof" 和rdb文件共用dir aof保存文件的名字兩個保存文件共用dir中指定的目錄
AOF默認是關閉的，在配置文件中開啟appendonly
RDB模式：基于時間快照，其默認只保留當前最新的一次快照，特點是執行速度比較快，缺點是可能會丟失從上次快照到當前時間點之間未做快照的數據。
RDB bgsave實現快照的具體過程：
Redis從master主進程先fork出一個子進程，使用寫時復制機制，子進程將內存的數據保存為一個臨時文件，比如:tmp-.rdb，當數據保存完成之后再將上一次保存的RDB文件替換掉，然后關閉子進程，這樣可以保證每一次做RDB快照保存的數據都是完整的因為直接替換RDB文件的時候,可能會出現突然斷電等問題,而導致RDB文件還沒有保存完整就因為突然關機停止保存,而導致數據丟失的情況.后續可以手動將每次生成的RDB文件進行備份，這樣可以最大化保存歷史數據
RDB持久化觸發條件分為手動觸發和自動觸發兩種：
手動觸發：save命令和bgsave命令都可以生成RDB文件。
save命令會阻塞redis服務器進程，直到RDB文件創建完畢為止，在redis服務器阻塞期間，服務器不能處理任何命令請求。
而bgsave命令會創建一個子進程，由子進程來負責創建RDB文件，父進程(即redis主進程)則繼續處理請求。
bgsave命令執行過程中，只有fork子進程時會阻塞服務器，而對于save命令，整個過程都會阻塞服務器，因此save已基本被廢棄，線上環境要杜絕save的使用。往往生產環境bgsave依然不允許輕易使用。
自動觸發：
在自動觸發RDB持久化時，redis也會選擇bgsave而不是save來進行持久化。
save m n
自動觸發最常見的情況是在配置文件中通過save m n，指定當m秒內發生n次變化時，會觸發bgsave。
自動觸發：兩個條件都要滿足在60秒內，觸發兩次數據變化才會啟動保存。
相關配置：
save 900 1 ????????#900s內修改了1個key即觸發保存RDB
save 300 10 ???????#300s內修改了10個key即觸發保存RDB
save 60 10000 ?????#60s內修改了10000個key即觸發保存RDBdbfilename dump.rdb
dir ./ ????????#編澤編譯安裝,默認RDB文件存放在啟動redis的工作目錄,建議明確指定存入目錄stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
備份操作，執行save的時候注意配置文件，dir指定為/apps/redis/data/下。
可以同時執行保存命令和查看進程，可以看到如圖所示；
自動觸發：
修改配置文件
#save 900 1
#save 300 10
#save 60 10000
save 60 2bgsave 在后臺備份的時候不知道什么時候完成
[root@Node1 redis]#:redis-cli bgsave ;redis-cli info Persistence |grep rdb_bgsave_in_progress
Background saving started
rdb_bgsave_in_progress:1
[root@Node1 redis]#:
[root@Node1 redis]#:redis-cli info Persistence |grep rdb_bgsave_in_progress
rdb_bgsave_in_progress:0
RDB的優缺點：
優點：
1.RDB快照保存了某個時間點的數據，可以通過腳本執行redis指令bgsave(非阻塞，后臺執行)或者save(會阻塞寫操作,不推薦)命令自定義時間點備份，可以保留多個備份，當出現問題可以恢復到不同時間點的版本,很適合備份,并且此文件格式也支持有不少第三方工具可以進行后續的數據分析比如: 可以在最近的24小時內，每小時備份一次RDB文件，并且在每個月的每一天，也備份一個RDB文件。這樣的話，即使遇上問題，也可以隨時將數據集還原到不同的版本。
缺點：
2.RDB可以最大化Redis的性能，父進程在保存 RDB文件時唯一要做的就是fork出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤 I/O 操作。
3.RDB在大量數據,比如幾個G的數據，恢復的速度比AOF的快
1.不能實時保存數據，可能會丟失自上一次執行RDB備份到當前的內存數據如果你需要盡量避免在服務器故障時丟失數據，那么RDB并不適合。雖然Redis允許設置不同的保存點（save point）來控制保存RDB文件的頻率，但是，因為RDB文件需要保存整個數據集的狀態，所以它并不是一個輕松快速的操作。因此一般會超過5分鐘以上才保存一次RDB文件。在這種情況下，一旦發生故障停機，你就可能會丟失好幾分鐘的數據。
2.當數據量非常大的時候，從父進程fork子進程進行保存至RDB文件時需要一點時間，可能是毫秒或者秒，取決于磁盤IO性能在數據集比較龐大時，fork()可能會非常耗時，造成服務器在一定時間內停止處理客戶端﹔如果數據集非常巨大，并且CPU時間非常緊張的話，那么這種停止時間甚至可能會長達整整一秒或更久。雖然 AOF重寫也需要進行fork()，但無論AOF重寫的執行間隔有多長，數據的持久性都不會有任何損失。
AOF模式：
AOF：按照操作順序依次將操作追加到指定的日志文件末尾。
AOF和RDB一樣使用了寫時復制機制，AOF默認為每秒鐘fsync一次，即將執行的命令保存到AOF文件當中，這樣即使redis服務器發生故障最多只丟失1秒中之內的數據，也可以設置不同的fsync策略always，即設置每次執行命令的時候執行fsync，fsync會在后臺執行線程，所以主線程可以繼續處理用戶的正常請求而不受到寫入AOF文件的影響。
同時啟用RDB和AOF，進行恢復時，默認AOF文件優先級高于RDB文件，即會使用AOF文件進行恢復。
注意：AOF模式默認是關閉的，第一次開啟AOF后，并重啟服務生效后，會因為AOF的優先級高于RDB，而先恢復AOF文件
AOF默認沒有數據文件存在，從而導致所有數據丟失。
是否開啟AOF
appendonly no #是否開啟AOF日志記錄，默認redis使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了，但是redis如果中途宕機，會導致可能有幾分鐘的數據丟失(取決于dump數據的間隔時間)，根據save來策略進行持久化，Append Only File是另一種持久化方式，可以提供更好的持久化特性，Redis會把每次寫入的數據在接收后都寫入 appendonly.aof 文件，每次啟動時Redis都會先把這個文件的數據讀入內存里，先忽略RDB文件。默認不啟用此功能
開啟后重啟，默認是與RDB在一個路徑下：
數據發生修改后，會自動記錄：
保存規則：
everysec表示每秒執行一次fsync，可能會導致丟失這1s數據，此為默認值，也生產建議值。
重寫規則，rewrite相關。
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100?
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
當如果同時開啟了AOF和RDB是如何正確恢復：
AOF優先級比RDB要高。
同時開啟只會同步AOF文件。
AOF重寫機制
將一些重復的,可以合并的,過期的數據重新寫入一個新的AOF文件,從而節約AOF備份占用的硬盤空間,也能加速恢復過程
可以手動執行 bgrewriteaof 觸發AOF,第一次開啟AOF功能,或定義自動 rewrite 策略
---end---
