redis 安裝配置

1，下載編譯安裝redis

http://www.redis.cn/download.html

下載完成，使用rz命令上傳至linux 服務器
tar -xvf redis-5.0.5.tar.gz            #解壓源碼包
mv redis-5.0.5 /usr/local/redis #將源碼包移動到/usr/local/目錄下，重命名爲redis
cd /usr/local/redis/                      #cd 到源碼目錄裏

make #編譯
中間有兩個報錯，解決

#沒有安裝gcc 包，yum install gcc -y 解決

#加個環境變量一起編譯　　　　make MALLOC=libc　用這句命令能正常編譯

make install #安裝編譯完成的程序，也可以不用安裝,cd 到src目錄 執行也行
cd /usr/local/bin/ #這個目錄是安裝完成後 生成的腳本，打開關閉 客戶端工具都在裏面

2.配置 配置文件，啓動 關閉 redis

vim /usr/local/redis/redis.conf  #配置 redis 配置文件，修改以下選項
bind 0.0.0.0 #監聽IP 0.0.0.0 表示此計算機所有IP都監聽
daemonize  yes  #是否後臺啓動redis，打開
protected-mode no # redis的安全機制，打開可能會報錯
#requirepass 123456 #設置密碼，默認註釋狀態。

redis-server /usr/local/redis/redis.conf  #指定配置文件啓動 redis

netstat -nltp|grep 6379 #檢查6379 是否被監聽了，這個端口是redis默認端口

redis-cli #登陸客戶端，輸入幾個值，查看以下

redis-cli shutdown #關閉redis服務

3.RDB持久化

RDB持久化方式是通過快照(snapshotting)完成的，當符合一定條件時，redis會自動將內存中所有數據以二進制方式生成一份副本並存儲在硬盤上。當redis重啓時，並且AOF持久化未開啓時，redis會讀取RDB持久化生成的二進制文件(默認名稱dump.rdb，可通過設置dbfilename修改)進行數據恢復，對於持久化信息可以用過命令“info Persistence”查看。

快照觸發條件

RDB生成快照可自動促發，也可以使用命令手動觸發，以下是redis觸發執行快照條件，後續會對每個條件詳細說明：

客戶端執行命令save和bgsave會生成快照；
根據配置文件save m n規則進行自動快照；
主從複製時，從庫全量複製同步主庫數據，此時主庫會執行bgsave命令進行快照；
客戶端執行數據庫清空命令FLUSHALL時候，觸發快照；
客戶端執行shutdown關閉redis時，觸發快照；

save命令觸發和shutdown觸發

客戶端執行save命令，該命令強制redis執行快照，這時候redis處於阻塞狀態，不會響應任何其他客戶端發來的請求，直到RDB快照文件執行完畢，所以請慎用。
 首先使用redis-cli info Persistence 查看最近一次持久化時間：

 #可以看到數據是一組時間戳看的 不方便看，我們可以用AWK 配合date命令轉換下
 date "+%Y-%m-%d %H:%M:%S" -d @`redis-cli info Persistence|awk -F":" 'NR==5{print$2}'`

#可以看到運行了 redis-cli save 命令，最後一次的保存時間已經發生了改變

shutdown觸發

#注意只有正常關閉纔會觸發保存，直接kill是無法觸發的

bgsave命令觸發

basave 命令執行之後立即返回 OK ，然後 Redis fork 出一個新子進程（在此期間父進程不響應請求），原來的 Redis 進程(父進程)繼續處理客戶端請求，而子進程則負責將數據保存到磁盤，然後退出。

#用法和save 差不多，但是阻塞時間比save 大大減少了

save m n規則觸發

這個配置在配置文件裏
默認
save 900 1          #表示900秒內有1個鍵發生修改，觸發bgsave
save 300 10        #表示300秒內有10個鍵發生修改，觸發bgsave
save 60 10000    #表示60秒內有10000個鍵發生修改，觸發bgsave
#上面關係式或的意思，滿足一個即可觸發bgsave

FLUSHALL觸發和主從觸發

flushall命令用於清空數據庫，請慎用，當我們使用了則表明我們需要對數據進行清空，那redis當然需要對快照文件也進行清空，所以會觸發bgsave。
在redis主從複製中，從節點執行全量複製操作，主節點會執行bgsave命令，並將rdb文件發送給從節點。

RDB持久化配置——配置文件

save m n
#配置快照(rdb)促發規則，格式：save <seconds> <changes>
#save 900 1  900秒內至少有1個key被改變則做一次快照
#save 300 10  300秒內至少有300個key被改變則做一次快照
#save 60 10000  60秒內至少有10000個key被改變則做一次快照
#關閉該規則使用svae “” 

dbfilename  dump.rdb
#rdb持久化存儲數據庫文件名，默認爲dump.rdb

stop-write-on-bgsave-error yes 
#yes代表當使用bgsave命令持久化出錯時候停止寫RDB快照文件,no表明忽略錯誤繼續寫文件。

rdbchecksum yes
#在寫入文件和讀取文件時是否開啓rdb文件檢查，檢查是否有無損壞，如果在啓動是檢查發現損壞，則停止啓動。

dir ./ 
#數據文件存放目錄，rdb快照文件和aof文件都會存放至該目錄，請確保有寫權限，編譯安裝的默認就在當前目錄。

rdbcompression yes
#是否開啓RDB文件壓縮，該功能可以節約磁盤空間

4.AOF持久化

AOF持久化和Mysql的二級制日誌寫入原理一樣，AOF可以將Redis執行的每一條寫命令追加到磁盤文件(appendonly.aof)中,在redis啓動時候優先選擇從AOF文件恢復數據。由於每一次的寫操作，redis都會記錄到文件中，對磁盤I/O有以一定影響，與RDB持久化相比，AOF持久化數據（1秒左右的數據）丟失更少，其消耗內存更少(RDB方式執行bgsve會有內存拷貝)。
開啓AOF

#默認情況下，redis是關閉了AOF持久化，開啓AOF通過配置appendonly爲yes開啓，我們修改配置文件或者在命令行直接使用config set修改，在用config rewrite同步到配置文件。通過客戶端修改好處是不用重啓redis，AOF持久化直接生效。

AOF持久化過程

redisAOF持久化過程可分爲以下階段：

1.追加寫入
redis將每一條寫命令以redis通訊協議添加至緩衝區aof_buf,這樣的好處在於在大量寫請求情況下，採用緩衝區暫存一部分命令隨後根據策略一次性寫入磁盤，這樣可以減少磁盤的I/O次數，提高性能。

2.同步命令到硬盤
當寫命令寫入aof_buf緩衝區後，redis會將緩衝區的命令寫入到文件，redis提供了三種同步策略，由配置參數appendfsync決定，下面是每個策略所對應的含義：

▪ no：不使用fsync方法同步，而是交給操作系統write函數去執行同步操作，在linux操作系統中大約每30秒刷一次緩衝。這種情況下，緩衝區數據同步不可控，並且在大量的寫操作下，aof_buf緩衝區會堆積會越來越嚴重，一旦redis出現故障，數據丟失嚴重。
▪ always：表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由於每次寫命令都寫到了文件中, 雖然數據比較安全，但是因爲每次寫操作都會同步到AOF文件中，所以在性能上會有影響，同時由於頻繁的IO操作，硬盤的使用壽命會降低。
▪ everysec：數據將使用調用操作系統write寫入文件，並使用fsync每秒一次從   內核刷新到磁盤。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。

3.文件重寫(bgrewriteaof)
當開啓的AOF時，隨着時間推移，AOF文件會越來越大,當然redis也對AOF文件進行了優化，即觸發AOF文件重寫條件（後續會說明）時候，redis將使用bgrewriteaof對AOF文件進行重寫。這樣的好處在於減少AOF文件大小，同時有利於數據的恢復。

爲什麼重寫？比如先後執行了“set foo bar1 set foo bar2 set foo bar3” 此時AOF文件會記錄三條命令，這顯然不合理，因爲文件中應只保留“set foo bar3”這個最後設置的值，前面的set命令都是多餘的，下面是一些重寫時候策略：

▪ 重複或無效的命令不寫入文件
▪ 過期的數據不再寫入文件
▪ 多條命令合併寫入（當多個命令能合併一條命令時候會對其優化合並作爲一個命令寫入，例如“RPUSH list1 a RPUSH list1 b" 合併爲“RPUSH list1 a b” ）

重寫觸發條件

AOF文件觸發條件可分爲手動觸發和自動觸發：

手動觸發：客戶端執行bgrewriteaof命令。

自動觸發：自動觸發通過以下兩個配置協作生效：

▪ auto-aof-rewrite-min-size: AOF文件最小重寫大小，只有當AOF文件大小大於該值時候纔可能重寫,4.0默認配置64mb。
▪ auto-aof-rewrite-percentage：當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。

redis開啓在AOF功能開啓的情況下，會維持以下三個變量

▪ 記錄當前AOF文件大小的變量aof_current_size。
▪ 記錄最後一次AOF重寫之後，AOF文件大小的變量aof_rewrite_base_size。
▪ 增長百分比變量aof_rewrite_perc。

每次當serverCron（服務器週期性操作函數）函數執行時，它會檢查以下條件是否全部滿足，如果全部滿足的話，就觸發自動的AOF重寫操作：

▪ 沒有bgsave命令（RDB持久化）/AOF持久化在執行；
▪ 沒有bgrewriteaofF在進行；
▪ 當前AOF文件大小要大於server.aof_rewrite_min_size的值；
▪ 當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者大於指定的增長百分比（auto-aof-rewrite-percentage參數）

AOF配置參數--配置文件

auto-aof-rewrite-min-size 64mb
#AOF文件最小重寫大小，只有當AOF文件大小大於該值時候纔可能重寫,4.0默認配置64mb。

auto-aof-rewrite-percentage  100
#當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。

appendfsync everysec
#no：不使用fsync方法同步，而是交給操作系統write函數去執行同步操作，在linux操作系統中大約每30秒刷一次緩衝。這種情況下，緩衝區數據同步不可控，並且在大量的寫操作下，aof_buf緩衝區會堆積會越來越嚴重，一旦redis出現故障，數據
#always：表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。這種情況下由於每次寫命令都寫到了文件中, 雖然數據比較安全，但是因爲每次寫操作都會同步到AOF文件中，所以在性能上會有影響，同時由於頻繁的IO操作，硬盤的使用壽命會降低。
#everysec：數據將使用調用操作系統write寫入文件，並使用fsync每秒一次從內核刷新到磁盤。 這是折中的方案，兼顧性能和數據安全，所以redis默認推薦使用該配置。

aof-load-truncated yes
#當redis突然運行崩潰時，會出現aof文件被截斷的情況，Redis可以在發生這種情況時退出並加載錯誤，以下選項控制此行爲。
#如果aof-load-truncated設置爲yes，則加載截斷的AOF文件，Redis服務器啓動發出日誌以通知用戶該事件。
#如果該選項設置爲no，則服務將中止並顯示錯誤並停止啓動。當該選項設置爲no時，用戶需要在重啓之前使用“redis-check-aof”實用程序修復AOF文件在進行啓動。

appendonly no 
#yes開啓AOF，no關閉AOF

appendfilename appendonly.aof
#指定AOF文件名，4.0無法通過config set 設置，只能通過修改配置文件設置。

dir ./
#RDB文件和AOF文件存放目錄

兩個保存文件檢查

redis-check-aof appendonly.aof  #ＡＯＦ
redis-check-rdb dump.rdb　　　＃ＲＤＢ