溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“Redis的持久化和主從復制詳細講解”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
Redis作為一個鍵值對內存數據庫(NoSQL)，數據都存儲在內存當中，在處理客戶端請求時，所有操作都在內存當中進行，如下所示：
這樣做有什么問題呢？
其實，只要稍微有點計算機基礎知識的人都知道，存儲在內存當中的數據，只要服務器關機(各種原因引起的)，內存中的數據就會消失了，不僅服務器關機會造成數據消失，Redis服務器守護進程退出，內存中的數據也一樣會消失。
對于只把Redis當緩存來用的項目來說，數據消失或許問題不大，重新從數據源把數據加載進來就可以了，但如果直接把用戶提交的業務數據存儲在Redis當中，把Redis作為數據庫來使用，在其放存儲重要業務數據，那么Redis的內存數據丟失所造成的影響也許是毀滅性。為了避免內存中數據丟失，Redis提供了對持久化的支持，我們可以選擇不同的方式將數據從內存中保存到硬盤當中，使數據可以持久化保存。
Redis提供了RDB和AOF兩種不同的數據持久化方式，下面我們就來詳細介紹一下這種不同的持久化方式吧。
RDB是一種快照存儲持久化方式，具體就是將Redis某一時刻的內存數據保存到硬盤的文件當中，默認保存的文件名為dump.rdb，而在Redis服務器啟動時，會重新加載dump.rdb文件的數據到內存當中恢復數據。
開啟RDB持久化方式很簡單，客戶端可以通過向Redis服務器發送save或bgsave命令讓服務器生成rdb文件，或者通過服務器配置文件指定觸發RDB條件。
save命令是一個同步操作。
# 異步保存數據集到磁盤上> bgsave
當客戶端發服務發出bgsave命令時，Redis服務器主進程會forks一個子進程來數據同步問題，在將數據保存到rdb文件之后，子進程會退出。
所以，與save命令相比，Redis服務器在處理bgsave采用子線程進行IO寫入，而主進程仍然可以接收其他請求，但forks子進程是同步的，所以forks子進程時，一樣不能接收其他請求，這意味著，如果forks一個子進程花費的時間太久(一般是很快的)，bgsave命令仍然有阻塞其他客戶的請求的情況發生。
除了通過客戶端發送命令外，還有一種方式，就是在Redis配置文件中的save指定到達觸發RDB持久化的條件，比如【多少秒內至少達到多少寫操作】就開啟RDB數據同步。
例如我們可以在配置文件redis.conf指定如下的選項：
# 900s內至少達到一條寫命令 save 900 1# 300s內至少達至10條寫命令 save 300 10# 60s內至少達到10000條寫命令 save 60 10000
之后在啟動服務器時加載配置文件。
# 啟動服務器加載配置文件 redis-server redis.conf
這種通過服務器配置文件觸發RDB的方式，與bgsave命令類似，達到觸發條件時，會forks一個子進程進行數據同步，不過最好不要通過這方式來觸發RDB持久化，因為設置觸發的時間太短，則容易頻繁寫入rdb文件，影響服務器性能，時間設置太長則會造成數據丟失。
前面介紹了三種讓服務器生成rdb文件的方式，無論是由主進程生成還是子進程來生成，其過程如下：
生成臨時rdb文件，并寫入數據。
完成數據寫入，用臨時文代替代正式rdb文件。
刪除原來的db文件。
RDB默認生成的文件名為dump.rdb，當然，我可以通過配置文件進行更加詳細配置，比如在單機下啟動多個redis服務器進程時，可以通過端口號配置不同的rdb名稱，如下所示：
# 是否壓縮rdb文件 rdbcompression yes # rdb文件的名稱 dbfilename redis-6379.rdb # rdb文件保存目錄 dir ~/redis/
與AOF方式相比，通過rdb文件恢復數據比較快。
rdb文件非常緊湊，適合于數據備份。
通過RDB進行數據備，由于使用子進程生成，所以對Redis服務器性能影響較小。
如果服務器宕機的話，采用RDB的方式會造成某個時段內數據的丟失，比如我們設置10分鐘同步一次或5分鐘達到1000次寫入就同步一次，那么如果還沒達到觸發條件服務器就死機了，那么這個時間段的數據會丟失。
使用save命令會造成服務器阻塞，直接數據同步完成才能接收后續請求。
使用bgsave命令在forks子進程時，如果數據量太大，forks的過程也會發生阻塞，另外，forks子進程會耗費內存。
聊完了RDB，來聊聊Redis的另外一個持久化方式：AOF(Append-only file)。
與RDB存儲某個時刻的快照不同，AOF持久化方式會記錄客戶端對服務器的每一次寫操作命令，并將這些寫操作以Redis協議追加保存到以后綴為aof文件末尾，在Redis服務器重啟時，會加載并運行aof文件的命令，以達到恢復數據的目的。
Redis默認不開啟AOF持久化方式，我們可以在配置文件中開啟并進行更加詳細的配置，如下面的redis.conf文件：
# 開啟aof機制 appendonly yes # aof文件名 appendfilename "appendonly.aof"# 寫入策略,always表示每個寫操作都保存到aof文件中,也可以是everysec或no appendfsync always # 默認不重寫aof文件 no-appendfsync-on-rewrite no # 保存目錄 dir ~/redis/
在上面的配置文件中，我們可以通過appendfsync選項指定寫入策略，有三個選項。
#appendfsync always # appendfsync everysec # appendfsync no
客戶端的每一個寫操作都保存到aof文件當，這種策略很安全，但是每個寫請注都有IO操作，所以也很慢。
appendfsync的默認寫入策略，每秒寫入一次aof文件，因此，最多可能會丟失1s的數據。
Redis服務器不負責寫入aof，而是交由操作系統來處理什么時候寫入aof文件。更快，但也是最不安全的選擇，不推薦使用。
AOF將客戶端的每一個寫操作都追加到aof文件末尾，比如對一個key多次執行incr命令，這時候，aof保存每一次命令到aof文件中，aof文件會變得非常大。
incr num 1incr num 2incr num 3incr num 4incr num 5incr num 6... incr num 100000
aof文件太大，加載aof文件恢復數據時，就會非常慢，為了解決這個問題，Redis支持aof文件重寫，通過重寫aof，可以生成一個恢復當前數據的最少命令集，比如上面的例子中那么多條命令，可以重寫為：
set num 100000
aof文件是一個二進制文件，并不是像上面的例子一樣，直接保存每個命令，而使用Redis自己的格式，上面只是方便演示。
通過在redis.conf配置文件中的選項no-appendfsync-on-rewrite可以設置是否開啟重寫，這種方式會在每次fsync時都重寫，影響服務器性以，因此默認值為no，不推薦使用。
# 默認不重寫aof文件 no-appendfsync-on-rewrite no
客戶端向服務器發送bgrewriteaof命令，也可以讓服務器進行AOF重寫。
# 讓服務器異步重寫追加aof文件命令> bgrewriteaof
壓縮aof文件，減少磁盤占用量。
將aof的命令壓縮為最小命令集，加快了數據恢復的速度。
在寫入aof日志文件時，如果Redis服務器宕機，則aof日志文件文件會出格式錯誤，在重啟Redis服務器時，Redis服務器會拒絕載入這個aof文件，可以通過以下步驟修復aof并恢復數據。
備份現在aof文件，以防萬一。
使用redis-check-aof命令修復aof文件，該命令格式如下：
# 修復aof日志文件 $ redis-check-aof -fix file.aof
重啟Redis服務器，加載已經修復的aof文件，恢復數據。
AOF只是追加日志文件，因此對服務器性能影響較小，速度比RDB要快，消耗的內存較少。
AOF方式生成的日志文件太大，即使通過AFO重寫，文件體積仍然很大。
恢復數據的速度比RDB慢。
通過上面的介紹，我們了解了RDB與AOF各自的優點與缺點，到底要如何選擇呢？
通過下面的表示，我們可以從幾個方面對比一下RDB與AOF,在應用時，要根本自己的實際需求，選擇RDB或者AOF，其實，如果想要數據足夠安全，可以兩種方式都開啟，但兩種持久化方式同時進行IO操作，會嚴重影響服務器性能，因此有時候不得不做出選擇。
當RDB與AOF兩種方式都開啟時，Redis會優先使用AOF日志來恢復數據，因為AOF保存的文件比RDB文件更完整。
“Redis的持久化和主從復制詳細講解”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
