柚子快報激活碼778899分享：數(shù)據(jù)庫 【Redis】持久化

http://yzkb.51969.com/

對于Redis中間件來說，一般是作為內存型數(shù)據(jù)庫或者緩存出現(xiàn)的。但是由于其數(shù)據(jù)是在內存中，因此當Redis所在的主機宕機之后，數(shù)據(jù)就會消失，再次重啟之后，沒有任何數(shù)據(jù)。這對于生產環(huán)境來說，是屬于P0級別的災難了。

因此，對于Redis來說，不僅要將數(shù)據(jù)存在內存中，還要將數(shù)據(jù)持久化到硬盤上。這樣當Redis重啟之后，可以通過硬盤中的數(shù)據(jù)來恢復內存中的數(shù)據(jù)。如果Redis是作為內存數(shù)據(jù)庫的話，那么客戶端就可以繼續(xù)進行訪問得到數(shù)據(jù)；如果Redis是作為緩存的話，那么就可以減少MySQL的壓力，從而避免MySQL宕機。

Redis有兩種持久化方式：RDB和AOF。

?RDB

RDB是定期備份的持久化方式，即Redis定期會把內存中的數(shù)據(jù)進行備份，生成一個快照，保存在硬盤中。這樣，當Redis重啟的時候，就可以讀取RDB文件來恢復內存數(shù)據(jù)。

觸發(fā)方式

手動觸發(fā)

程序猿在客戶端輸入特定的命令，來觸發(fā)Redis服務器快照的生成。

save：通過save命令，可以使Redis服務器觸發(fā)快照行為，進行備份

bgsave：通過bgsave命令，同樣可以使Redis觸發(fā)快照行為，進行備份。

對于save和bgsave兩個命令來說，最大的區(qū)別就是save會和其他客戶端命令一樣，在同一個進程中執(zhí)行，因此就會影響其他客戶端命令的執(zhí)行；而對于bgsave命令來說，并不會在當前進程中執(zhí)行，而是fork一個子進程，在子進程中執(zhí)行，這樣就不會影響其他客戶端的請求。

?bgsave的執(zhí)行流程

1.? 客戶端發(fā)送bgsave命令之后，Redis服務器會判斷是否已經(jīng)正在執(zhí)行該命令。如果正在執(zhí)行，那么就會直接進行返回。

2. 如果沒有執(zhí)行，那么Redis服務器就會通過fork命令，來創(chuàng)建出一個子進程。

fork命令是Linux系統(tǒng)提供的一個創(chuàng)建子進程的API。簡單來說，fork命令就是將原來的進程給簡單粗暴的復制一份。復制完成之后，兩個進程之間就沒有任何的關系，各自會執(zhí)行各自的內容，不過由于后續(xù)的進程，即子進程是父進程復制而來，因此兩個進程中的數(shù)據(jù)是完成相同的。這樣，讓子進程生成一份快照，就相當于讓父進程生成一份快照。

對于fork命令來說，是不是有比較大的性能開銷？不會，執(zhí)行fork命令進行內存拷貝的時候，并不是在內存空間中把所有的數(shù)據(jù)全部復制一份，而是采用寫時拷貝的方式來完成。

所謂寫時拷貝，當父子進程的數(shù)據(jù)是完成相同時，兩者指向的內存空間還是同樣的位置。但是當任一進程發(fā)生改變時，才會開辟一個新的內存空間來記錄變化的數(shù)據(jù)。

綜上所述，使用fork命令生成父子進程時，并不會產生較大的性能開銷。畢竟Redis改變的數(shù)據(jù)并不是大多數(shù)，而是一小部分，因此對于寫時拷貝來說消耗并不是很大，整體來說較快。

3. 父進程繼續(xù)執(zhí)行客戶端的其他命令請求，而子進程則是來生成快照，進行備份。

4. 子進程持久化完成之后，就會來通知父進程。父進程再更新一些統(tǒng)計信息之后，子進程就可以銷毀了。

自動觸發(fā)

1. 在Redis的配置文件中可以進行配置，以來達到自動觸發(fā)定期快照的操作；

2. 在主從模式中，給主節(jié)點加從節(jié)點時，主節(jié)點會主動生成快照，發(fā)送給從節(jié)點；

3. 當客戶端發(fā)送shutdown命令，進程關閉服務器時，會觸發(fā)快照的生成，但是如果是意外宕機，例如掉電或者kill，那么此時就不會生成快照。

RDB文件

1. RDB文件的存放位置，是可以通過Redis的配置信息來設置的，默認是放在/var/lib/redis中。

2. Redis文件是一個二進制的文件。即把內存中的數(shù)據(jù)通過壓縮的形式，保存到這個二進制文件中。通過壓縮，可以節(jié)省空間，但是進行操作時就會消耗一定的CPU資源。

3. Redis重啟時，就會通過RDB文件來恢復內存中的數(shù)據(jù)。但是如果RDB的數(shù)據(jù)內容發(fā)生了變化，那么就有可能重啟失敗，也有可能重啟成功。因此，Redis還專門提供了檢查RDB文件的工具，可以在重啟服務器之前，先檢查RDB文件是否發(fā)生錯誤。

4. 在快照生成RDB文件時，會將生成的這些內容存儲到一個臨時的文件中。當快照生成完畢，就會使用新生成的RDB文件來代替舊的RDB文件，這樣硬盤中自始至終就只有一個文件了。

?5. 在bgsave命令的執(zhí)行流程中，雖然fork子進程的性能消耗并不大，但是RDB文件的生成也有一個較高的性能開銷，因此RDB文件不是實時備份，而是定期備份。正是由于定期備份，因此在一次備份完成之后，Redis宕機，再次重啟時，備份之后操作的數(shù)據(jù)都不復存在。

RDB特點

1. RDB文件是一個二進制格式的文件，因此非常適合用于備份、全量復制等場景。

2. Redis加載RDB恢復數(shù)據(jù)往往比加載AOF恢復數(shù)據(jù)要快。這是因為RDB使用二進制來組織數(shù)據(jù)，而AOF則是使用文本格式來組織數(shù)據(jù)，而計算機天然對二進制好感度高。

3. Redis無法做到實時持久化，畢竟生成一次快照消耗的資源還是較多的，屬于重量級操作，頻繁執(zhí)行成本過高。

4. RDB使用二進制格式保存，但是Redis不同的版本可能二進制格式略有不同，因此可能存在兼容性問題（例如將5版本的RDB放到7版本的RDB文件中，就可能運行不起來）。

AOF

AOF（Append Only File）是實時備份的持久化方式。所謂實時備份，并不是將Redis服務器內存中的數(shù)據(jù)進行持久化，而是把用戶進行的操作當作日志記錄成文件。也就是說，當用戶執(zhí)行某條操作時，Redis就會進行記錄，并且寫入到文件中。這樣，當Redis服務器重新啟動的時候，就回去讀取AOF文件，用來恢復數(shù)據(jù)。

對于RDB方式的持久化來說，最大的問題是不能實時持久化來保存數(shù)據(jù)。這就導致在某些突發(fā)情況發(fā)生后，Redis服務器重啟時，Redis內存中的數(shù)據(jù)可能會存在丟失的情況。

因此，AOF方式的持久化，就是用來解決RDB存在的問題。當開啟AOF方式的持久化之后，Redis服務器重新啟動時，就會讀取AOF文件中的內容來恢復內存數(shù)據(jù)，不會再讀取RDB文件的內容。

?開啟AOF

默認情況下，Redis服務器是使用RDB的方式來進行持久化的。對于AOF來說，默認則是關閉狀態(tài)，要想使用AOF，就要在配置文件中進行開啟：

?當AOF方式的持久化開啟之后，RDB就會失效。并且對于AOF來說，其文件生成的位置和RDB文件生成的位置在同一目錄下。

AOF與Redis性能間的關系

引入AOF之后，既要操作內存（Redis服務器需要對客戶端發(fā)送的請求進行響應），又要操作硬盤（Redis服務器需要把客戶端的操作當成日志寫入文件），這是否對Redis的效率產生了很大的影響？答案是沒有。

AOF雖然是把客戶端的操作給記錄下來，但是并不是直接讓工作線程把數(shù)據(jù)給寫入硬盤。而是先把數(shù)據(jù)寫入到內存中的緩沖區(qū)中，當積累一定數(shù)量之后（通過積累，可以降低寫硬盤的次數(shù)，從而減少性能的消耗），統(tǒng)一寫入硬盤（寫入硬盤時，采用了順序讀取的方式，相對隨機讀取來說還是比較快的一種讀取方式）。

通過上述描述，我相信大家存在一個疑惑：把數(shù)據(jù)寫入緩沖區(qū)，那不還是在內存中，這些數(shù)據(jù)依然有丟失的風險，因此AOF依舊沒解決RDB存在的問題。

其實不然，AOF的確解決了RDB存在的不能實時持久化的問題，這本質上存在一個可靠和性能的矛盾性。當數(shù)據(jù)特別可靠時，其性能一定會有所損耗；當性能非常好時，其數(shù)據(jù)可靠性就會有所下降。例如MySQL中的隔離級別，當隔離級別是可串行化時，其數(shù)據(jù)基本上完全可靠，但是性能低下；當隔離級別是讀未提交時，其讀取到的數(shù)據(jù)不一定可靠，但是其性能一定非常高。

綜上，針對Redis的AOF來說，其官方也給出了不同的措施來解決不同業(yè)務場景下的問題，即程序員根據(jù)對系統(tǒng)的評估來取舍緩存區(qū)的刷新策略。刷新頻率越高，那么其性能影響也就越大，但是其數(shù)據(jù)的可靠性就越高；刷新頻率越低，性能影響就會越小，但是數(shù)據(jù)的可靠性就會降低。

在Redis中，使用appendfsync屬性來配置刷新策略，并且給出了三個配置值。

可配置值說明性能與可靠性always 客戶端進行操作之后，數(shù)據(jù)進入緩存區(qū)之后，直接寫入AOF文件中。 性能最低，可靠性最高。 everysec 客戶端進行操作之后，先寫入緩沖區(qū)，然后每秒寫入一次文件。 性能適中，可靠性適中。 Redis默認此刷新策略。 no 客戶端進行操作之后，先寫入緩存區(qū)，然后根據(jù)操作系統(tǒng)來控制寫入文件。 性能最高，可靠性最低。

重寫機制

在AOF文件中，記錄的是客戶端每次進行的操作。但是在客戶端操作的過程中，可能某個變量會重復被操作，最后被刪除。這些操作如果記錄在AOF文件中，那么在Redis服務器重啟的時候，也會對這個變量進行反復操作，最后刪除，那么就是消耗大量內存但是做了無用的事。

因此Redis就存在一個機制，能夠對AOF文件進行整理操作，這個整理就能夠剔除其中的冗余操作，并且合并一些操作，達到給AOF文件瘦身的效果。這樣，當Reids服務器進行重啟的時候，就不會機械性的做一些無用的操作。

這個機制就被稱為Redis的重寫機制。

觸發(fā)方式

手動觸發(fā)和自動觸發(fā)兩種。

手動觸發(fā)使用bgrewriteaof命令進行操作；

自動觸發(fā)則根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)確定自動觸發(fā)時機，auto-aof-rewrite-min-size表示觸發(fā)重寫時AOF的最小文件大小，默認是64MB，auto-aof-rewrite-percentage代表當前AOF占用大小相比較上次重寫時增加的比例。

重寫流程

① 當Redis接收到了重寫操作時，就會fork一個子進程。如果此時Redis服務器已經(jīng)在重寫，那么就不會再次執(zhí)行命令，直接返回。

?② 父進程仍然接收請求，子進程負責針對AOF文件進行重寫。在重寫的時候，并不關心AOF文件原來有啥內容，只關心此時內存中數(shù)據(jù)的最終狀態(tài)。因此，子進程只需要把當前的數(shù)據(jù)獲取出來，以AOF文件的格式寫入到一個新的AOF文件中。

③ 子進程在重寫AOF文件的同時，父進程還是會不停的接收客戶端的請求，并且把這些請求產生的AOF數(shù)據(jù)寫入到緩沖區(qū)中，再刷新到原來的AOF文件中。在執(zhí)行這些命令的同時，父進程還會準備一個新的緩沖區(qū)，把fork之后產生的AOF數(shù)據(jù)放入其中。

為啥要準備這個新的緩沖區(qū)？

當fork之后，子進程中的內存數(shù)據(jù)是父進程fork之前的，因此對于fork之后的請求對內存造成的修改，子進程是不知道的。所以，當Redis把子進程的內存數(shù)據(jù)整理完畢之后，如果直接代替之前的文件，那么整理文件過程中產生的數(shù)據(jù)會丟失。所以，要準備這個緩沖區(qū)來接收fork之后的一些請求。

④ 子進程整理完畢之后，會通知父進程，父進程把新緩沖區(qū)中的內容加入到新AOF文件之中，就可以用新的文件來代替舊的AOF文件。

當在重寫過程中，發(fā)現(xiàn)Redis正在備份。那么此時，AOF重寫就會停止，等待RDB快照完成，再繼續(xù)進行重寫的操作。

混合持久化

對于RDB來說，是沒法做到實時備份，存在數(shù)據(jù)丟失的風險；對于AOF來說，是使用文本的格式來寫入數(shù)據(jù)，導致后續(xù)加載文件的成本較高。

由于RBD和AOF各有優(yōu)缺點，因此就又有了混合持久化的方式。正所謂，小孩子才做選擇，大人全都要。簡單來說，混合持久化就是對于每一個操作，都會使用AOF的方式來寫入文件；當執(zhí)行重寫操作時，就會把當前內存的狀態(tài)按照RDB的格式寫入到新的AOF文件中。這樣，即可以保證所有數(shù)據(jù)的及時更新，又可以在讀取文件時采用較小的成本。

柚子快報激活碼778899分享：數(shù)據(jù)庫 【Redis】持久化

http://yzkb.51969.com/

好文推薦