宕机了，Redis数据丢了怎么办？
目錄
前言
什么是AOF？
三種寫(xiě)回策略
日志文件太大怎么辦？
AOF重寫(xiě)會(huì)阻塞主線程嗎？
AOF的缺點(diǎn)
總結(jié)
什么是RDB？
給哪些數(shù)據(jù)做快照？
快照時(shí)能夠修改數(shù)據(jù)嗎？
多久做一次快照？
增量快照
AOF和RDB混合使用
總結(jié)
總結(jié)
前言
Redis作為內(nèi)存型的數(shù)據(jù)庫(kù)，雖然很快，依然有著很大的隱患，一旦「服務(wù)器宕機(jī)」重啟，內(nèi)存中數(shù)據(jù)還會(huì)存在嗎？
很容易想到的一個(gè)方案是從后臺(tái)數(shù)據(jù)恢復(fù)這些數(shù)據(jù)，如果數(shù)據(jù)量很小，這倒是一個(gè)可行的方案。但是如果數(shù)據(jù)量過(guò)大，頻繁的從后臺(tái)數(shù)據(jù)庫(kù)訪問(wèn)數(shù)據(jù)，壓力很大；另外一方面恢復(fù)數(shù)據(jù)的時(shí)間極慢。
對(duì)于Redis來(lái)說(shuō)，實(shí)現(xiàn)數(shù)據(jù)的持久化和快速恢復(fù)是至關(guān)重要。
今天這篇文章就來(lái)介紹一下Redis持久化的兩種機(jī)制AOF日志、RDB快照。
?
什么是 AOF 日志？
AOF(Append Only File)日志稱之為「寫(xiě)后日志」，即是命令先執(zhí)行完成，把數(shù)據(jù)寫(xiě)入內(nèi)存，然后才會(huì)記錄日志。
AOF日志（文本形式）會(huì)將收到每一條的命令且執(zhí)行成功的命令以一定的格式寫(xiě)入到文本中（追加的方式）。
「寫(xiě)后日志有什么好處呢？」 如下：
對(duì)于寫(xiě)前日志無(wú)論命令是否執(zhí)行成功都會(huì)被記錄，但是Redis的寫(xiě)后日志則只有命令執(zhí)行成功才會(huì)被寫(xiě)入日志，避免了日志中存在錯(cuò)誤命令；
同時(shí)由于是命令執(zhí)行成功之后才會(huì)寫(xiě)入日志，因此不會(huì)阻塞當(dāng)前命令的執(zhí)行。
但是AOF日志也有「潛在的風(fēng)險(xiǎn)」，分析如下：
由于是寫(xiě)后日志，如果在命令執(zhí)行成功之后，在日志未寫(xiě)入磁盤(pán)之前服務(wù)器突然宕機(jī)，那重啟恢復(fù)數(shù)據(jù)的時(shí)候，這部分的數(shù)據(jù)肯定在日志文件中不存在了，那么將會(huì)丟失。（無(wú)法通過(guò)后臺(tái)數(shù)據(jù)庫(kù)恢復(fù)的情況下）
雖然不會(huì)阻塞當(dāng)前命令的執(zhí)行，由于記錄日志也是在主線程中（Redis是單線程），如果日志寫(xiě)入磁盤(pán)的時(shí)候突然阻塞了，肯定會(huì)影響下一個(gè)命令的執(zhí)行。
為了解決上面的風(fēng)險(xiǎn)，AOF日志提供了三種回寫(xiě)策略。
三種寫(xiě)回策略
AOF機(jī)制提供了三種回寫(xiě)策略，這些都在appendfsync配置，如下：
Always（同步寫(xiě)回）：命令執(zhí)行完成，立馬同步的將日志寫(xiě)入磁盤(pán)
Everysec（每秒寫(xiě)回）：命令執(zhí)行完成后，先將日志寫(xiě)入 AOF 文件的內(nèi)存緩沖區(qū)，每隔一秒把緩沖區(qū)中內(nèi)容寫(xiě)入磁盤(pán)。
No(操作系統(tǒng)控制的寫(xiě)回)：每個(gè)寫(xiě)命令執(zhí)行完，只是先把日志寫(xiě)到AOF文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時(shí)將緩沖區(qū)內(nèi)容寫(xiě)回磁盤(pán)。
其實(shí)這三中寫(xiě)回策略都無(wú)法解決主線程的阻塞和數(shù)據(jù)丟失的問(wèn)題，分析如下：
同步寫(xiě)回：基本不丟失數(shù)據(jù)，但是每步操作都會(huì)有一個(gè)慢速的落盤(pán)操作，不可避免的影響主線程性能。
每秒寫(xiě)回：采用一秒寫(xiě)一次到 AOF 日志文件中，但是一旦宕機(jī)還是會(huì)丟失一秒的數(shù)據(jù)。
操作系統(tǒng)控制的寫(xiě)回：在寫(xiě)完緩沖區(qū)之后則會(huì)寫(xiě)入磁盤(pán)，但是數(shù)據(jù)始終在緩沖區(qū)的時(shí)間內(nèi)一旦宕機(jī)，數(shù)據(jù)還是會(huì)丟失。
以上三種策略優(yōu)缺點(diǎn)總結(jié)如下表：
日志文件太大怎么辦？
隨著數(shù)據(jù)量的增大，AOF日志文件難免會(huì)很大，這樣將會(huì)導(dǎo)致寫(xiě)入和恢復(fù)數(shù)據(jù)都將變得非常慢。此時(shí)AOF提供了一種「重寫(xiě)機(jī)制」解決這一問(wèn)題。
?重寫(xiě)機(jī)制理解起來(lái)很簡(jiǎn)單，即是Redis會(huì)創(chuàng)建一個(gè)新的AOF日志文件，將每個(gè)鍵值對(duì)最終的值用一條命令寫(xiě)入日志文件中。
比如讀取了鍵值對(duì)key1:value1，重寫(xiě)機(jī)制會(huì)在新的AOF日志文件中記錄如下一條命令：
set key1 value1其實(shí)即是記錄多次修改的最終的值記錄在新的AOF日志文件中，這樣當(dāng)恢復(fù)數(shù)據(jù)時(shí)可直接執(zhí)行該命令。
「為什么重寫(xiě)機(jī)制能夠縮小文件呢？」 當(dāng)一個(gè)鍵值被多次修改后，AOF日志文件中將會(huì)記錄多次修改鍵值的命令，重寫(xiě)機(jī)制是根據(jù)這個(gè)鍵值最新?tīng)顟B(tài)為它生成「寫(xiě)入」命令，這樣舊文件中的「多條」命令在重寫(xiě)后的新日志中變成了「一條」命令。
作者畫(huà)了一張重寫(xiě)流程圖，僅供參考，如下：
重寫(xiě)機(jī)制流程AOF重寫(xiě)會(huì)阻塞主線程嗎？
AOF重寫(xiě)雖然能夠縮減日志文件的大小，達(dá)到減少日志記錄和數(shù)據(jù)恢復(fù)的時(shí)間，但是在數(shù)據(jù)量非常的大情況下把整個(gè)數(shù)據(jù)庫(kù)重寫(xiě)后的日志寫(xiě)入磁盤(pán)是一個(gè)非常耗時(shí)的過(guò)程，難道不會(huì)阻塞主線程嗎？
「答案是：不會(huì)阻塞主線程」；因?yàn)锳OF重寫(xiě)過(guò)程是由后臺(tái)子進(jìn)程bgrewriteaof來(lái)完成的，這也是為了避免阻塞主線程，導(dǎo)致數(shù)據(jù)庫(kù)性能下降。
其實(shí)重寫(xiě)的過(guò)程分為兩個(gè)階段：「一個(gè)拷貝，兩處日志」。
「一個(gè)拷貝」：指每次執(zhí)行重寫(xiě)時(shí)，主線程都fork一個(gè)子線程bgrewriteaof，主線程會(huì)把內(nèi)存數(shù)據(jù)拷貝一份到子線程，此時(shí)子線程中包含了數(shù)據(jù)庫(kù)的最新數(shù)據(jù)。然后子線程就能在不影響主線程的情況下進(jìn)行AOF重寫(xiě)了。
「兩處日志」是什么？如下：
第一處日志：子線程重寫(xiě)并未阻塞主線程，此時(shí)主線程仍然會(huì)處理請(qǐng)求，此時(shí)的AOF日志仍然正在記錄著，這樣即使宕機(jī)了，數(shù)據(jù)也是齊全的。第一處日志即是值主線程正在使用的日志。
第二處日志：指新的AOF重寫(xiě)日志；重寫(xiě)過(guò)程中的操作也會(huì)被寫(xiě)到重寫(xiě)日志緩沖區(qū)，這樣重寫(xiě)日志也不會(huì)丟失最新的操作。等到拷貝數(shù)據(jù)的所有操作記錄重寫(xiě)完成后，重寫(xiě)日志記錄的這些最新操作也會(huì)寫(xiě)入新的 AOF 文件，以保證數(shù)據(jù)庫(kù)最新?tīng)顟B(tài)的記錄。此時(shí)，我們就可以用新的 AOF 文件替代舊文件了。
?「總結(jié)」：Redis在進(jìn)行AOF重寫(xiě)時(shí)，會(huì)fork一個(gè)子線程（不會(huì)阻塞主線程）并進(jìn)行內(nèi)存拷貝用于重寫(xiě)，然后使用兩個(gè)日志保證重寫(xiě)過(guò)程中，新寫(xiě)入的數(shù)據(jù)不會(huì)丟失。
AOF的缺點(diǎn)
雖說(shuō)進(jìn)行了日志重寫(xiě)后，AOF日志文件會(huì)縮減很多，但是在數(shù)據(jù)恢復(fù)過(guò)程中仍然是一條命令一條命令（由于單線程，只能順序執(zhí)行）的執(zhí)行恢復(fù)數(shù)據(jù)，這個(gè)恢復(fù)的過(guò)程非常緩慢。
總結(jié)
AOF這種通過(guò)逐一記錄操作命令的日志方式，提供了三種寫(xiě)回策略保證數(shù)據(jù)的可靠性，分別是Always、Everysec和No，這三種策略在可靠性上是從高到低，而在性能上則是從低到高。
為了避免日志文件過(guò)大，Redis提供了重寫(xiě)的機(jī)制，每次重寫(xiě)都fork一個(gè)子線程，拷貝內(nèi)存數(shù)據(jù)進(jìn)行重寫(xiě)，將多條命令縮減成一條生成鍵值對(duì)的命令，最終重寫(xiě)的日志作為新的日志。
什么是RDB？
RDB(Redis DataBase)是另外一種持久化方式：內(nèi)存快照。
?RDB記錄的是「某一個(gè)時(shí)刻」的內(nèi)存數(shù)據(jù)，并不是操作命令。
這種方式類似于拍照，只保留某一時(shí)刻的形象。內(nèi)存快照是將某一時(shí)刻的狀態(tài)以文件的形式寫(xiě)入磁盤(pán)。這樣即使宕機(jī)了，數(shù)據(jù)也不會(huì)丟失，這個(gè)快照文件就稱為RDB文件。
?由于記錄的是某個(gè)時(shí)刻的內(nèi)存數(shù)據(jù)，數(shù)據(jù)恢復(fù)非常快的，不需要像AOF日志逐一執(zhí)行記錄的命令。
給哪些數(shù)據(jù)做快照？
為了保證數(shù)據(jù)的可靠性，Redis執(zhí)行的「全量快照」，也就是把內(nèi)存中的所有數(shù)據(jù)都寫(xiě)到磁盤(pán)中。
隨著數(shù)據(jù)量的增大，一次性把全部數(shù)據(jù)都寫(xiě)到磁盤(pán)中勢(shì)必會(huì)造成線程阻塞，這就關(guān)系到Redis的性能了。
針對(duì)線程阻塞的問(wèn)題Redis提供了兩個(gè)命令，如下：
save：在主線程中執(zhí)行，會(huì)導(dǎo)致主線程阻塞。
bgsave：fork一個(gè)子進(jìn)程，專門(mén)用于寫(xiě)入RDB文件，避免了主線程的阻塞，這是Redis的默認(rèn)配置。
這樣就可以使用bgsave命令執(zhí)行全量快照，既可以保證數(shù)據(jù)的可靠性也避免了主線程的阻塞。
快照時(shí)能夠修改數(shù)據(jù)嗎？
子線程執(zhí)行全量快照的同時(shí)，主線程仍然在接受著請(qǐng)求，讀數(shù)據(jù)肯定沒(méi)有問(wèn)題，但是如果個(gè)修改了數(shù)據(jù)，如何能夠保證快照的完整性呢？
「舉個(gè)栗子」：我在T時(shí)刻進(jìn)行全量快照，假設(shè)數(shù)據(jù)量有8G，寫(xiě)入磁盤(pán)的過(guò)程至少需要20S，在這20S的時(shí)間內(nèi)，一旦內(nèi)存中的數(shù)據(jù)發(fā)生了修改，則快照的完整性就破壞了。
但是如果在快照時(shí)不能修改數(shù)據(jù)，則對(duì)Redis的性能有巨大的影響，對(duì)于這個(gè)問(wèn)題，Redis是如何解決的呢？
?Redis借助操作系統(tǒng)提供的寫(xiě)時(shí)復(fù)制技術(shù)（Copy-On-Write, COW），在執(zhí)行快照的同時(shí)，正常處理寫(xiě)操作。
其實(shí)很簡(jiǎn)單，bgsave命令會(huì)fork一個(gè)子線程，這個(gè)子線程共享所有內(nèi)存的數(shù)據(jù)，子線程會(huì)讀取主線程內(nèi)存中的數(shù)據(jù)，將他們寫(xiě)入RDB文件。
寫(xiě)時(shí)復(fù)制保證數(shù)據(jù)可修改如上圖，對(duì)于鍵值對(duì)A的讀取并不會(huì)影響子線程，但是如果主線程一旦修改內(nèi)存中一塊數(shù)據(jù)（例如鍵值對(duì)D），這塊數(shù)據(jù)將會(huì)被復(fù)制一個(gè)副本，然后bgsave子線程會(huì)將其寫(xiě)入RDB文件。
多久做一次快照？
快照只是記錄某一時(shí)刻的數(shù)據(jù)，一旦時(shí)間隔離很久，則服務(wù)器一旦宕機(jī)，則會(huì)丟失那段時(shí)間的數(shù)據(jù)。
比如在T1時(shí)間做了一次快照，在T1+t時(shí)又做了一次快照，如果在t這個(gè)時(shí)間段內(nèi)服務(wù)器突然宕機(jī)了，則快照中只保存了T1時(shí)刻的快照，在t時(shí)間段內(nèi)的數(shù)據(jù)修改未被記錄（丟失）。如下圖：
t時(shí)刻宕機(jī)，未執(zhí)行快照從上圖明顯可以看出，「RDB并不是一個(gè)完美的日志記錄方案」，只有讓t時(shí)間逐漸縮小，才能保證丟失的數(shù)據(jù)縮小。
「那么問(wèn)題來(lái)了，時(shí)間能夠縮短1秒嗎？」 即是每秒執(zhí)行一次快照。
?全量快照是記錄某一個(gè)時(shí)刻的「全部」內(nèi)存數(shù)據(jù)，每秒執(zhí)行一次的對(duì)Redis性能影響巨大，于是「增量快照」就出來(lái)了。
增量快照
「增量快照是指做了一次全量快照之后，后續(xù)的快照只對(duì)修改的數(shù)據(jù)進(jìn)行快照記錄」，這樣可以避免每次都全量快照的開(kāi)銷。
增量快照的前提是Redis能夠記住修改的數(shù)據(jù)，這個(gè)功能其實(shí)開(kāi)銷也是巨大的，需要保存完整的鍵值對(duì)，這對(duì)內(nèi)存的消耗是巨大的。
?為了解決這個(gè)問(wèn)題，Redis使用了AOF和RDB混合使用的方式。
AOF和RDB混合使用
這個(gè)概念是在Redis4.0提出的，簡(jiǎn)單的說(shuō)就是「內(nèi)存快照以一定的頻率執(zhí)行，比如1小時(shí)一次，在兩次快照之間，使用AOF日志記錄這期間的所有命令操作。」
?混合使用的方式使得內(nèi)存快照不必頻繁的執(zhí)行，并且AOF記錄的也不是全部的操作命令，而是兩次快照之間的操作命令，不會(huì)出現(xiàn)AOF日志文件過(guò)大的情況了，避免了AOF重寫(xiě)的開(kāi)銷了。
這個(gè)方案既能夠用到的RDB的快速恢復(fù)的好處，又能享受都只記錄操作命令的簡(jiǎn)單優(yōu)勢(shì)，強(qiáng)烈建議使用。
總結(jié)
RDB內(nèi)存快照記錄的是某一個(gè)時(shí)刻的內(nèi)存數(shù)據(jù)，因此能夠快速恢復(fù)；AOF和RDB混合使用能夠使得宕機(jī)后數(shù)據(jù)快速恢復(fù)，又能夠避免AOF日志文件過(guò)大。
?
總結(jié)
本文介紹了兩種數(shù)據(jù)恢復(fù)和持久化的方案，分別是AOF和RDB。
AOF介紹了什么？如下：
AOF是寫(xiě)后日志，通過(guò)記錄操作命令持久化數(shù)據(jù)。
由于AOF是在命令執(zhí)行之后記錄日志，如果在寫(xiě)入磁盤(pán)之前服務(wù)器宕機(jī)，則會(huì)丟失數(shù)據(jù)；如果寫(xiě)入磁盤(pán)的時(shí)候突然阻塞，則會(huì)阻塞主線程；為了解決以上問(wèn)題，AOF機(jī)制提供了三種寫(xiě)回的策略，每種策略都有不同的優(yōu)缺點(diǎn)。
AOF日志文件過(guò)大怎么辦？AOF通過(guò)fork一個(gè)子線程重寫(xiě)一個(gè)新的日志文件（共享主線程的內(nèi)存，記錄最新數(shù)據(jù)的寫(xiě)入命令），同時(shí)子線程重寫(xiě)，避免阻塞主線程。
RDB介紹了什么？如下：
RDB是內(nèi)存快照，記錄某一個(gè)時(shí)刻的內(nèi)存數(shù)據(jù)，而不是操作命令。
Redis提供了兩個(gè)命令，分別是save、bgsave來(lái)執(zhí)行全量快照，這兩個(gè)命令的區(qū)別則是save是在主線程執(zhí)行，勢(shì)必會(huì)阻塞主線程，bgsave是在fork一個(gè)子線程，共享內(nèi)存。
RDB通過(guò)操作系統(tǒng)的「寫(xiě)時(shí)復(fù)制技術(shù)」，能夠保證在執(zhí)行快照的同時(shí)主線程能夠修改快照。
由于兩次快照之間是存在間隔的，一旦服務(wù)器宕機(jī)，則會(huì)丟失兩次間隔時(shí)刻的數(shù)據(jù)，Redis4.0開(kāi)始使用AOF日志記錄兩次快照之間執(zhí)行的命令（AOF和RDB混合使用）。
有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)
歡迎大家關(guān)注Java之道公眾號(hào)
好文章，我在看??
新人創(chuàng)作打卡挑戰(zhàn)賽發(fā)博客就能抽獎(jiǎng)！定制產(chǎn)品紅包拿不停！總結(jié)
以上是生活随笔為你收集整理的宕机了，Redis数据丢了怎么办？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： js判断是微信、QQ内置浏览器打开页面
- 下一篇： 4.29python