宕機了，Redis數(shù)據(jù)丟了怎么辦？
前言 什么是AOF？ 三種寫回策略 日志文件太大怎么辦？ AOF重寫會阻塞主線程嗎？ AOF的缺點 總結(jié) 什么是RDB？ 給哪些數(shù)據(jù)做快照？ 快照時能夠修改數(shù)據(jù)嗎？ 多久做一次快照？ 增量快照 AOF和RDB混合使用 總結(jié) 總結(jié)
前言
Redis作為內(nèi)存型的數(shù)據(jù)庫，雖然很快，依然有著很大的隱患，一旦「服務(wù)器宕機」重啟，內(nèi)存中數(shù)據(jù)還會存在嗎？Redis來說，實現(xiàn)數(shù)據(jù)的持久化和快速恢復(fù)是至關(guān)重要。Redis持久化的兩種機制AOF日志、RDB快照。?
什么是 AOF 日志？
AOF(Append Only File)日志稱之為「寫后日志」，即是命令先執(zhí)行完成，把數(shù)據(jù)寫入內(nèi)存，然后才會記錄日志。AOF日志（文本形式）會將收到每一條的命令且執(zhí)行成功的命令以一定的格式寫入到文本中（追加的方式）。對于寫前日志無論命令是否執(zhí)行成功都會被記錄，但是 Redis的寫后日志則只有命令執(zhí)行成功才會被寫入日志，避免了日志中存在錯誤命令；同時由于是命令執(zhí)行成功之后才會寫入日志，因此不會阻塞當(dāng)前命令的執(zhí)行。
AOF日志也有「潛在的風(fēng)險」，分析如下：由于是寫后日志，如果在命令執(zhí)行成功之后，在日志未寫入磁盤之前服務(wù)器突然宕機，那重啟恢復(fù)數(shù)據(jù)的時候，這部分的數(shù)據(jù)肯定在日志文件中不存在了，那么將會丟失。（無法通過后臺數(shù)據(jù)庫恢復(fù)的情況下） 雖然不會阻塞當(dāng)前命令的執(zhí)行，由于記錄日志也是在主線程中（ Redis是單線程），如果日志寫入磁盤的時候突然阻塞了，肯定會影響下一個命令的執(zhí)行。
AOF日志提供了三種回寫策略。三種寫回策略
AOF機制提供了三種回寫策略，這些都在appendfsync配置，如下：Always（同步寫回）：命令執(zhí)行完成，立馬同步的將日志寫入磁盤Everysec（每秒寫回）：命令執(zhí)行完成后，先將日志寫入 AOF 文件的內(nèi)存緩沖區(qū)，每隔一秒把緩沖區(qū)中內(nèi)容寫入磁盤。No(操作系統(tǒng)控制的寫回)：每個寫命令執(zhí)行完，只是先把日志寫到AOF文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回磁盤。
同步寫回：基本不丟失數(shù)據(jù)，但是每步操作都會有一個慢速的落盤操作，不可避免的影響主線程性能。每秒寫回：采用一秒寫一次到 AOF 日志文件中，但是一旦宕機還是會丟失一秒的數(shù)據(jù)。操作系統(tǒng)控制的寫回：在寫完緩沖區(qū)之后則會寫入磁盤，但是數(shù)據(jù)始終在緩沖區(qū)的時間內(nèi)一旦宕機，數(shù)據(jù)還是會丟失。
日志文件太大怎么辦？
Redis會創(chuàng)建一個新的AOF日志文件，將每個鍵值對最終的值用一條命令寫入日志文件中。set key1 value1AOF日志文件中將會記錄多次修改鍵值的命令，重寫機制是根據(jù)這個鍵值最新狀態(tài)為它生成「寫入」命令，這樣舊文件中的「多條」命令在重寫后的新日志中變成了「一條」命令。
AOF重寫會阻塞主線程嗎？
bgrewriteaof來完成的，這也是為了避免阻塞主線程，導(dǎo)致數(shù)據(jù)庫性能下降。fork一個子線程bgrewriteaof，主線程會把內(nèi)存數(shù)據(jù)拷貝一份到子線程，此時子線程中包含了數(shù)據(jù)庫的最新數(shù)據(jù)。然后子線程就能在不影響主線程的情況下進行AOF重寫了。第一處日志：子線程重寫并未阻塞主線程，此時主線程仍然會處理請求，此時的AOF日志仍然正在記錄著，這樣即使宕機了，數(shù)據(jù)也是齊全的。第一處日志即是值主線程正在使用的日志。第二處日志：指新的AOF重寫日志；重寫過程中的操作也會被寫到重寫日志緩沖區(qū)，這樣重寫日志也不會丟失最新的操作。等到拷貝數(shù)據(jù)的所有操作記錄重寫完成后，重寫日志記錄的這些最新操作也會寫入新的 AOF 文件，以保證數(shù)據(jù)庫最新狀態(tài)的記錄。此時，我們就可以用新的 AOF 文件替代舊文件了。
Redis在進行AOF重寫時，會fork一個子線程（不會阻塞主線程）并進行內(nèi)存拷貝用于重寫，然后使用兩個日志保證重寫過程中，新寫入的數(shù)據(jù)不會丟失。AOF的缺點
總結(jié)
Always、Everysec和No，這三種策略在可靠性上是從高到低，而在性能上則是從低到高。什么是RDB？
RDB(Redis DataBase)是另外一種持久化方式：內(nèi)存快照。RDB記錄的是「某一個時刻」的內(nèi)存數(shù)據(jù)，并不是操作命令。RDB文件。給哪些數(shù)據(jù)做快照？
save：在主線程中執(zhí)行，會導(dǎo)致主線程阻塞。bgsave：fork一個子進程，專門用于寫入RDB文件，避免了主線程的阻塞，這是Redis的默認(rèn)配置。
bgsave命令執(zhí)行全量快照，既可以保證數(shù)據(jù)的可靠性也避免了主線程的阻塞。快照時能夠修改數(shù)據(jù)嗎？
T時刻進行全量快照，假設(shè)數(shù)據(jù)量有8G，寫入磁盤的過程至少需要20S，在這20S的時間內(nèi)，一旦內(nèi)存中的數(shù)據(jù)發(fā)生了修改，則快照的完整性就破壞了。Redis借助操作系統(tǒng)提供的寫時復(fù)制技術(shù)（Copy-On-Write, COW），在執(zhí)行快照的同時，正常處理寫操作。bgsave命令會fork一個子線程，這個子線程共享所有內(nèi)存的數(shù)據(jù)，子線程會讀取主線程內(nèi)存中的數(shù)據(jù)，將他們寫入RDB文件。
鍵值對A的讀取并不會影響子線程，但是如果主線程一旦修改內(nèi)存中一塊數(shù)據(jù)（例如鍵值對D），這塊數(shù)據(jù)將會被復(fù)制一個副本，然后bgsave子線程會將其寫入RDB文件。多久做一次快照？
T1時間做了一次快照，在T1+t時又做了一次快照，如果在t這個時間段內(nèi)服務(wù)器突然宕機了，則快照中只保存了T1時刻的快照，在t時間段內(nèi)的數(shù)據(jù)修改未被記錄（丟失）。如下圖：
RDB并不是一個完美的日志記錄方案」，只有讓t時間逐漸縮小，才能保證丟失的數(shù)據(jù)縮小。1秒嗎？」 即是每秒執(zhí)行一次快照。增量快照
AOF和RDB混合使用的方式。AOF和RDB混合使用
Redis4.0提出的，簡單的說就是「內(nèi)存快照以一定的頻率執(zhí)行，比如1小時一次，在兩次快照之間，使用AOF日志記錄這期間的所有命令操作。」總結(jié)
RDB內(nèi)存快照記錄的是某一個時刻的內(nèi)存數(shù)據(jù)，因此能夠快速恢復(fù)；AOF和RDB混合使用能夠使得宕機后數(shù)據(jù)快速恢復(fù)，又能夠避免AOF日志文件過大。?
總結(jié)
AOF和RDB。AOF介紹了什么？如下：AOF是寫后日志，通過記錄操作命令持久化數(shù)據(jù)。由于 AOF是在命令執(zhí)行之后記錄日志，如果在寫入磁盤之前服務(wù)器宕機，則會丟失數(shù)據(jù)；如果寫入磁盤的時候突然阻塞，則會阻塞主線程；為了解決以上問題，AOF機制提供了三種寫回的策略，每種策略都有不同的優(yōu)缺點。AOF日志文件過大怎么辦？AOF通過fork一個子線程重寫一個新的日志文件（共享主線程的內(nèi)存，記錄最新數(shù)據(jù)的寫入命令），同時子線程重寫，避免阻塞主線程。
RDB介紹了什么？如下：RDB是內(nèi)存快照，記錄某一個時刻的內(nèi)存數(shù)據(jù)，而不是操作命令。Redis提供了兩個命令，分別是save、bgsave來執(zhí)行全量快照，這兩個命令的區(qū)別則是save是在主線程執(zhí)行，勢必會阻塞主線程，bgsave是在fork一個子線程，共享內(nèi)存。RDB通過操作系統(tǒng)的「寫時復(fù)制技術(shù)」，能夠保證在執(zhí)行快照的同時主線程能夠修改快照。 由于兩次快照之間是存在間隔的，一旦服務(wù)器宕機，則會丟失兩次間隔時刻的數(shù)據(jù)， Redis4.0開始使用AOF日志記錄兩次快照之間執(zhí)行的命令（AOF和RDB混合使用）。
有道無術(shù)，術(shù)可成；有術(shù)無道，止于術(shù)
歡迎大家關(guān)注Java之道公眾號
好文章，我在看??
評論
圖片
表情