redis深度剖析: 01 單機版reids(部署,持久化,企業備份方案)

一.單機版redis安裝以及企業級redis啓動方案

安裝:

[root@localhost ~]# tar zxf redis-3.2.3.tar.gz

[root@localhost  ~]# cd redis-3.2.3/

[root@localhost  redis-3.2.3]# make&& make install

[root@localhost  redis-3.2.3]# cd utils/

[root@localhost  utils]# ./install_server.sh

#按照默認位置便可（回車下去就好）

生產環境啓動方案:

要把 redis 做爲一個系統的daemon進程去運行的,每次系統啓動,系統要一塊兒啓動

若是不是用咱們上面的那種 # ./install_server.sh  的方式安裝的就須要作下面的這些操做:

首先咱們爲redis生成一個配置文件 # cd /usr/local/src/redis-3.2.3/utils/ # cp redis_init_script /etc/init.d/ # vim /etc/init.d/redis_init_script 這裏只列出須要修改部分(若是不須要修改就直接默認就能夠) REDISPORT=6379 EXEC=/usr/local/bin/redis-server CLIEXEC=/usr/local/bin/redis-cli PIDFILE=/var/run/redis_${REDISPORT}.pid CONF="/etc/redis/${REDISPORT}.conf" # mv /etc/init.d/redis_init_script /etc/init.d/redis_6379

# 這裏說一下,咱們用 ./install_server.sh 的方式安裝默認這一步已經幫咱們作好了

配置好服務以後測試啓動:

# service redis_6379 start

咱們來配置他隨開機自動啓動:

1.首先咱們配置兩行註釋(開頭位置):

# vim /etc/init.d/redis_6379

#!/bin/sh

# chkconfig: 2345 90 10

# description: Redis is a persistent key-value database

2.執行開機自啓動命令:

# chkconfig redis_6379 on

redis-cli 的使用:

中止redis:

# redis-cli shutdown

鏈接redis:

# redis-cli -h 127.0.0.1 -p 6379 -a PASSWORD

測試redis端口是否正常

# redis-cli ping

建立一個key:

127.0.0.1:6379> set key1 value1

OK

查看一個key:

127.0.0.1:6379> get key1

"value1"

刪除一個key:

127.0.0.1:6379> del key1

(integer) 1

redis的技術,包括4塊:

redis各類數據結構和命令的使用

redis一些特殊的解決方案的使用, pub/sub消息系統,分佈式鎖,輸入的自動完成,等等

redis平常管理的相關命令

redis企業級的集羣部署和架構

二.redis持久化

1.redis持久化對於生成環境中的災難恢復的意義:

redis持久化的意義在於故障恢復

好比說你部署了一個redis,作cache緩存,保存了一些比較重要的東西

若是沒有持久化,redis遇到災難性故障的時候,就會丟失全部的數據

若是經過持久化將數據搞到磁盤上去,而後按期同步備份到雲存儲服務器上去,那麼就能夠保證全部的數據不丟失所有,仍是能夠恢復一部分數據的.

redis的持久化分爲: RDB,AOF 兩種方式

持久化主要是作災難恢復的,數據恢復,也能夠歸類到高可用的一個環節裏面去.

好比你的redis整個掛了,而後redis不用了,你要作的事情就是讓redis變的可用,儘快變得可用

重啓redis,能夠儘快讓它可用,可是若是你redis沒有作持久化,可用了也是沒用的大量的sql會直接把mysql打死

2.redis的RDB和AOF兩種持久化機制的介紹:

RDB持久化機制,對redis中數據執行週期性的持久化

AOF機制對每條數據寫入命令做爲日誌,以append-only的模式寫入一個日誌文件中,在redis重啓的時候,能夠經過回放AOF日誌中寫入的指令來從新構建整個數據集

若是同時使用RDB和AOF兩種持久化機制,那麼在redis重啓的時候,會使用AOF來從新構建數據,由於AOF中的數據更加完整

若是咱們想要redis僅僅做爲純內存的緩存來用,那麼能夠禁止RDB和AOF全部的持久化機制

RDB持久化方式:

能夠理解爲數據快照方式

每隔必定時間,生成redis內存中數據的一份完整快照

AOF持久化方式:

至關於mysql的binlog日誌方式

reids每隔1秒(默認)會強制調用操做系統,寫入到文件中去

AOF文件是會無限的往一個文件裏面寫數據,爲了防止這一現象發生redis會等到AOF文件數據量大到必定程度的時候建立一個新的AOF文件,而後把以前膨脹的AOF文件給刪除掉

爲防止AOF持續膨脹,redis的AOF重寫機制:

首先咱們在redis規定了redis只能佔用1G的內存來存放緩存數據,

大概存了100w數據的時候這1G的數據粘滿了,

這時候redis會根據本身的LRU算法清楚一些不經常使用的數據,

這時候redis內存中的數據爲50w條,AOF文件中的數據爲100w條,

redis又持續新增數據,當redis內存中的數據又達到100w條的時候,AOF文件中有150w條數據,

這時候redis會出手重寫這個持續膨脹的AOF文件,

首先會建立一個新的AOF 文件出來, 把當前redis內存中的100w條數據寫入到新的AOF文件中去,

寫入完成以後會刪除掉以前的那個膨脹的AOF文件

redis的AOF重寫機制,保證AOF文件不會持續膨脹,當AOF文件膨脹到必定程度的時候,redis就會出手重寫

3.redis的RDB和AOF兩種持久化機制的優劣對比:

RDB的優勢:

(1)RDB會生成多個數據文件,每一個數據文件都表明了某一時刻中redis的數據,這種多個數據文件方式,很是適合作冷備份.

由redis去控制固定時長去生成快照文件

RDB數據最冷備,在最壞的狀況下,提供數據恢復的時候,速度比AOF快

(2)RDB對redis對外提供讀寫服務,影響很是小,可讓redis保持高性能,由於redis主進程只須要fork一個子進程,讓子進程執行磁盤的IO操做來進行RDB持久化便可

(3)相對於AOF持久化機制來講,直接基於RDB數據文件來重啓和恢復redis進程,更加快速

AOF是存放的指令,須要回放

RDB,就是一份數據文件,恢復的時候直接加載到內存中便可

RDB的缺點:

(1)RDB在發生故障的時候,丟失的數據會比AOF多,由於RDB是定時快照文件,AOF是實時備份數據

這個問題,也是RDB最大的缺點,不適合作第一優先恢復的方案.

(2)RDB在作快照的時候,若是數據量特別大,可能會致使客戶端提供的服務暫停數毫秒,甚至數秒

通常不要讓RDB的快照間隔時間太長,不然每次生成的RDB文件太大了,對redis自己的性能可能會

有影響

AOF的優勢:

(1)AOF能夠更好的保護數據不丟失,通常AOF會每一個一秒,經過後臺線程執行一次fsync操做,最多丟失1秒的數據

(2)AOF日誌文件以append-only模式寫入,因此沒有任何磁盤尋址開銷,寫入性能很是高,並且文件不容易破損

(3)AOF日誌文件即便過大的時候,出現後臺重寫操做,也不會影響客戶端的讀寫.由於在rewrite log的時候會對其中的指導進行壓縮,建立出一份須要恢復數據的最小日誌出來.在建立新日誌文件的時候,老的日誌文件仍是照常寫入.當新的日誌文件建立成功以後,再交換老的日誌文件便可.

(4)AOF經過命令的方式進行記錄,很是適合作災難性的誤刪除的緊急恢復.只要尚未進行rewrite操做就能夠即時恢復數據

最大的優勢就是: 更好的保護數據

AOF的缺點:

(1)對於同一份數據來講,AOF日誌文件一般比RDB數據快照文件更大

(2)AOF開啓後,支持redis寫的QPS會下降

(3)之前AOF發生過bug,如今經過rewrite的方式會健壯一些

(4)惟一比較大的缺點,作恢復的時候,會比較慢, 不太適合作冷備

RDB和AOF到底該如何選擇:

建議RDB和AOF同時開啓:

(1)不要僅僅使用RDB,由於會致使你丟失不少的數據

(2)也不要僅僅使用AOF, 由於,AOF不適合作冷備,也沒有RDB恢復速度快,AOF是發生過bug的

(3)綜合使用AOF和RDB兩種持久化機制

AOF儘量大的保證數據安全

RDB用來作冷備份,在AOF文件損壞不可用的時候,還可使用RDB來進程快速的數據恢復

4.配置redis的RDB持久化

配置RDB持久化:

# vim /etc/redis/6379.conf

save 60 1000

# 每隔60秒去檢測一下,若是有超過1000個key發生了變動就去生成一個新的 dump.rdb文件,

這個dump.rdb文件就是redis內存中完整的數據快照,這個操做也被稱之爲snapshotting,快照,也能夠手動調用save或者bgsave命令,同步或異步執行rdb快照生成

#save能夠設置多個,同時生效

dbfilename dump.rdb

# RDB持久化的文件名稱(由於名字是用的一個,因此每次快照以後,都會把以前快照的文件給替換掉)

# 意思是dump.rdb 文件只會有一個,新的會覆蓋老的

dir /var/lib/redis/6379

# dump.rdb(rdb快照文件)存儲的位置

改完配置記得重啓:

# redis-cli SHUTDOWN

# service redis_6379 start

RDB持久化機制的工做流程:

(1)redis根據配置本身的嘗試去生成rdb快照文件

(2)fork一個子進程出來

(3)子進程嘗試將數據dump到臨時的rdb快照文件中

(4)完成rdb快照文件的生成以後,就會替換掉以前的舊的快照文件

知識點補充:

經過 redis-cli SHUTDOWN 這種方式去關閉redis,實際上是一種安全的退出方式, redis在退出的時候會將內存中的數據當即的生成一份完整的rdb快照

恢復測試:

(1) 寫入數據 --- 當即經過 redis-cli SHUTDOWN關閉 -- 查看dump.rdb 文件是否生成 -- 啓動redis查看數據是否還在

(2)定義 save 5 1 -- 插入數據,等待5秒 -- kill -9 殺掉redis -- 啓動查看數據是否還在

5.配置redis的AOF持久化

默認是打開RDB持久化方式的,AOF默認是關閉的

AOF持久化配置:

# vim /etc/redis/6379.conf

appendonly yes

#打開AOF持久化,在咱們生成環境中,AOF是必定要打開的,除非說,你丟幾分鐘的數據也無所謂

#AOF持久化策略(三種)

# appendfsync always

#每寫入一條數據,當即將這個數據對應的寫日誌fsync到磁盤上去,性能很是差(大概2000QPS)

appendfsync everysec

#默認的AOF持久化策略(生產環境通常這麼配置)

#每秒將 os cache中的數據fsync到磁盤(QPS能夠到2w)

# appendfsync no

# 僅僅將數據寫入到os cache中就撒手無論了,等待系統自動執行fsync操做,不可控

dir /var/lib/redis/6379

# dir即指定了 RDB快照文件的位置,也指定了 aof 日誌文件的位置

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

# AOF rewrite操做,說一下這兩個參數是什麼意思:

好比說上一次AOF rewrite以後是 128mb,而後就會接着往進去寫,若是發現超過了以前的100%,256mb, 就會去判讀是否超過了 min-size 配置的參數(256>64),若是超過就會重寫

改完以後記得重啓:

# redis-cli SHUTDOWN

# service redis_6379 start

這裏再說一下,RDB 和 AOF同時開啓的狀況下,啓動的時候redis 會加載 AOF中的數據

QPS : 每秒鐘的請求數量

AOF rewrite:

這裏再說一下爲啥要進行AOF rewrite操做:

redis中的數據實際上是有限的,不少數據可能會自動過時,可能會被用戶刪除,可能會被redis自動清理掉

可是AOF文件中仍是保存着這部分數據,時間一長數據就會不斷膨脹

全部redis會經過rewrite操做來控制 aof文件的不斷暴增

咱們這邊仍是用上面的那張圖,來看一下,爲啥要作AOF rewrite:

AOF rewrite工做原理:

(1)redis fork一個子進程

(2)子進程基於當前內存中的數據,構建日誌,開始往一個新的臨時的AOF文件中寫入日誌

(3)redis主進程,接收到client新的寫操做以後,在內存中寫入日誌,同事新的日誌也繼續寫入舊的AOF文件

(4)子進程寫完新的日誌文件以後,主進程將內存職工的新日誌再次追加到新的AOF文件中

(5)用新的日誌文件替換掉舊的日誌文件

AOF文件修復:

若是AOF文件有破損的話,能夠用 redis-check-aof --fix 作修復

# redis-check-aof --fix appendonly.aof

AOF和RDB同時工做:

1.若是RDB在執行快照操做的時候,不會執行AOF的 rewrite操做

反之,若是AOF 在執行rewrite操做的時候,ROD的快照操做也不會執行

總而言之就是,不會同時執行,RDB快照操做 和 AOF rewrite操做

2.若是RDB在執行快照操做,咱們手動的去執行 AOF rewrite操做,呢麼等RDB的快照操做完成以後AOF  

rewrite操做纔會去執行

3.若是同時用RDB和AOF兩種持久化機制,重啓redis的時候,會優先使用AOF進程數據恢復,由於其中的

日誌更完整

知識點補充:

若是RDB中有部分數據,AOF中有部分數據,RDB中的數據不會被加載

三.企業級備份方案

在企業中,RDB的生成策略,用默認的其實也差很少

若是你但願你的RDB最多丟失一分鐘的數據,呢麼儘可能每一個一分鐘都去生成一個快照

save 60 10000 這個調策略根據本身實際需求去改

AOF必定要打開,用默認設置也差很少:

fsync的策略用 everysec 策略就能夠(每隔一秒redis調用系統強刷一次fsync)

auto-aof-rewrote-min-size: 根據本身的數據量來調整一下就行了

幾臺 redis 承受幾十萬的 QPS,徹底沒有問題

數據備份方案:

(1)寫crontab定時調度備份腳本去作數據備份

(2)每一個小時都copy一份rdb的備份到一個目錄中去,僅僅保留最近48小時的備份

(3)天天都保留一份當日的rdb備份,到一個目錄中去,僅僅保留最近一個月的備份

(4)每次copy備份的時候,都把太舊的備份給刪了

(5)天天晚上將當前服務器上全部的數據備份,發送一份到遠程的雲服務器上去

每小時copy一次備份，刪除48小時前的數據

crontab -e

0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh

#vim /usr/local/redis/copy/redis_rdb_copy_hourly.sh

#!/bin/sh cur_date=`date +%Y%m%d%k` rm -rf /usr/local/redis/snapshotting/$cur_date mkdir -p /usr/local/redis/snapshotting/$cur_date cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date del_date=`date -d -48hour +%Y%m%d%k` rm -rf /usr/local/redis/snapshotting/$del_date

天天copy一次備份

crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh

# vim /usr/local/redis/copy/redis_rdb_copy_daily.sh

#!/bin/sh cur_date=`date +%Y%m%d` rm -rf /usr/local/redis/snapshotting/$cur_date mkdir /usr/local/redis/snapshotting/$cur_date cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date del_date=`date -d -1month +%Y%m%d` rm -rf /usr/local/redis/snapshotting/$del_date

天天一次將全部數據上傳一次到遠程的雲服務器上去

crontab -e

0 0 * * * sh /usr/local/redis/copy/redis_rdb_scp.sh

# vim /usr/local/redis/copy/redis_rdb_scp.sh

#!/bin/sh ssh root@遠程主機 "rm -rf /opt/backup/snapshotting/*" scp /usr/local/redis/snapshotting/* root@遠程主機:opt/backup/snapshotting/

數據恢復方案:

(1)若是是redis進程掛掉，那麼重啓redis進程便可，直接基於AOF日誌文件恢復數據

(2)若是是redis進程所在機器掛掉，那麼重啓機器後，嘗試重啓redis進程，嘗試直接基於AOF日誌文件進行數據恢復

AOF沒有破損，也是能夠直接基於AOF恢復的

AOF append-only，順序寫入，若是AOF文件破損，那麼用redis-check-aof fix

(3)若是redis當前最新的AOF和RDB文件出現了丟失/損壞，那麼能夠嘗試基於該機器上當前的某個最新的RDB數據副本進行數據恢復

當前最新的AOF和RDB文件都出現了丟失/損壞到沒法恢復，通常不是機器的故障，人爲

找到RDB最新的一份備份，小時級的備份能夠了，小時級的確定是最新的，copy到redis裏面去，就能夠恢復到某一個小時的數據(要注意目錄下面不要有 aof 的破損文件,要暫時關閉AOF持久化)

操做:

1.中止redis

2.清除/var/redis/6379/下面的破損文件

3.再配置文件中關閉 AOF持久化

4.把備份的 rdb文件 傳到 /var/redis/6379/ 目錄下面

5.啓動redis,確認數據恢復正常

6.直接在命令行熱修改redis配置打開aof，

打開以後redis就會將內存中的數據對應的日誌，寫入aof文件中

127.0.0.1:6379> config set appendonly yes

7.稍等片刻(等待redis將內存中的數據寫入到剛剛生成的AOF文件),以後再次中止redis

8.在配置文件中開啓 AOF 持久化

9.啓動redis  

(4)若是當前機器上的全部RDB文件所有損壞，那麼從遠程的雲服務上拉取最新的RDB快照回來恢復數據

(5)若是是發現有重大的數據錯誤，好比某個小時上線的程序一會兒將數據所有污染了，數據全錯了，那麼能夠選擇某個更早的時間點，對數據進行恢復

舉個例子，12點上線了代碼，發現代碼有bug，致使代碼生成的全部的緩存數據，寫入redis，所有錯了,找到一份11點的rdb的冷備，而後按照上面的步驟，去恢復到11點的數據，不就能夠了嗎