自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Redis怎么防止數(shù)據(jù)丟失?可能真是面試必問了!

運(yùn)維 數(shù)據(jù)庫(kù)運(yùn)維 Redis
這篇文章我們就來分析Redis的數(shù)據(jù)持久化是如何實(shí)現(xiàn)的?我們經(jīng)常聽的RDB和AOF有什么區(qū)別?以及它們不同的使用場(chǎng)景。

[[347577]]

Redis要想實(shí)現(xiàn)高可用,主要有以下方面來保證:

  •  數(shù)據(jù)持久化
  •  主從復(fù)制
  •  自動(dòng)故障恢復(fù)
  •  集群化

這篇文章我們先介紹Redis的高可用保障的基礎(chǔ):數(shù)據(jù)持久化。

因?yàn)镽edis的主從復(fù)制和自動(dòng)故障恢復(fù),都需要依賴Redis持久化相關(guān)的東西。同時(shí),Redis的數(shù)據(jù)持久化也可以用來做數(shù)據(jù)備份,用來保障數(shù)據(jù)的安全性。

Redis是一個(gè)內(nèi)存數(shù)據(jù)庫(kù),它的數(shù)據(jù)都保存在內(nèi)存中,如果實(shí)例宕機(jī),那么數(shù)據(jù)則全部丟失。如何保證數(shù)據(jù)的完整性和安全性也是提高服務(wù)高可用的重要機(jī)制之一。

Redis提供了完善的持久化機(jī)制,可以把內(nèi)存中的數(shù)據(jù)持久化到磁盤上,方便我們進(jìn)行備份數(shù)據(jù)和快速恢復(fù)數(shù)據(jù)。

這篇文章我們就來分析Redis的數(shù)據(jù)持久化是如何實(shí)現(xiàn)的?我們經(jīng)常聽的RDB和AOF有什么區(qū)別?以及它們不同的使用場(chǎng)景。

持久化方式

Redis提供的數(shù)據(jù)持久化方式主要有2種:

  •  RDB:產(chǎn)生一個(gè)數(shù)據(jù)快照文件
  •  AOF:實(shí)時(shí)追加命令的日志文件

它們分別對(duì)應(yīng)了不同的使用場(chǎng)景,下面我們就來依次分析。

RDB

介紹

RDB全稱Redis Database Backup file(Redis數(shù)據(jù)備份文件),也被叫做Redis數(shù)據(jù)快照。

我們可以通過執(zhí)行save或bgsave命令讓Redis在本地生成RDB快照文件,這個(gè)RDB文件包含了整個(gè)實(shí)例接近完整的數(shù)據(jù)內(nèi)容。

它的優(yōu)點(diǎn)如下:

  •  RDB文件數(shù)據(jù)是被壓縮寫入的,因此RDB文件的體積要比整個(gè)實(shí)例內(nèi)存要小
  •  當(dāng)實(shí)例宕機(jī)恢復(fù)時(shí),加載RDB文件的速度很快,能夠在很短時(shí)間內(nèi)迅速恢復(fù)文件中的數(shù)據(jù)

它的缺點(diǎn)也很明顯:

  •  由于是某一時(shí)刻的數(shù)據(jù)快照,因此它的數(shù)據(jù)并不全
  •  生成RDB文件的代價(jià)是比較大的,它會(huì)消耗大量的CPU和內(nèi)存資源

因此RDB比較適用于以下場(chǎng)景:

  •  主從全量同步數(shù)據(jù)
  •  數(shù)據(jù)庫(kù)備份
  •  對(duì)于丟失數(shù)據(jù)不敏感的業(yè)務(wù)場(chǎng)景,實(shí)例宕機(jī)后快速恢復(fù)數(shù)據(jù)

Redis主從全量同步數(shù)據(jù)就是使用RDB文件進(jìn)行的。

由此可以看出,RDB非常適合做數(shù)據(jù)備份,我們可以定時(shí)讓Redis生成RDB文件,然后備份這個(gè)快照文件即可。

定時(shí)生成RDB

Redis也提供了定時(shí)觸發(fā)生成RDB文件的配置項(xiàng):

Copy On Write

在Redis上執(zhí)行save和bgsave命令都可以生成RDB文件,但前者是在前臺(tái)執(zhí)行的,也就是說在生成RDB文件時(shí),會(huì)阻塞整個(gè)實(shí)例,在RDB未生成之前,任何請(qǐng)求都是無法處理的,對(duì)于內(nèi)存很大的實(shí)例,生成RDB文件非常耗時(shí),顯然這是我們不能接受的。

所以通常我們會(huì)選擇執(zhí)行bgsave讓Redis在后臺(tái)生成RDB文件,這樣Redis依舊可以處理客戶端請(qǐng)求,不會(huì)阻塞整個(gè)實(shí)例。

但不是說后臺(tái)生成RDB就是沒有代價(jià)的,Redis為了實(shí)現(xiàn)后臺(tái)把內(nèi)存數(shù)據(jù)的快照寫入文件,采用了操作系統(tǒng)提供的Copy On Write技術(shù),也就是我們熟知的fork系統(tǒng)調(diào)用。

fork系統(tǒng)調(diào)用會(huì)產(chǎn)生一個(gè)子進(jìn)程,它與父進(jìn)程共享相同的內(nèi)存地址空間,這樣子進(jìn)程在這一時(shí)刻就能擁有與父進(jìn)程的相同的內(nèi)存數(shù)據(jù)。

雖然子進(jìn)程與父進(jìn)程共享同一塊內(nèi)存地址空間,但在fork子進(jìn)程時(shí),操作系統(tǒng)需要拷貝父進(jìn)程的內(nèi)存頁(yè)表給子進(jìn)程,如果整個(gè)Redis實(shí)例內(nèi)存占用很大,那么它的內(nèi)存頁(yè)表也會(huì)很大,在拷貝時(shí)就會(huì)比較耗時(shí),同時(shí)這個(gè)過程會(huì)消耗大量的CPU資源。在完成拷貝之前父進(jìn)程也處于阻塞狀態(tài),無法處理客戶端請(qǐng)求。

fork執(zhí)行完之后,子進(jìn)程就可以掃描自身所有的內(nèi)存數(shù)據(jù),然后把全部數(shù)據(jù)寫入到RDB文件中。

之后父進(jìn)程依舊處理客戶端的請(qǐng)求,當(dāng)在處理寫命令時(shí),父進(jìn)程會(huì)重新分配新的內(nèi)存地址空間,從操作系統(tǒng)申請(qǐng)新的內(nèi)存使用,不再與子進(jìn)程共享,這個(gè)過程就是Copy On Write(寫實(shí)復(fù)制)名字的由來。這樣父子進(jìn)程的內(nèi)存就會(huì)逐漸分離,父進(jìn)程申請(qǐng)新的內(nèi)存空間并更改內(nèi)存數(shù)據(jù),子進(jìn)程的內(nèi)存數(shù)據(jù)不受影響。

由此可以看出,在生成RDB文件時(shí),不僅消耗CPU資源,還有需要占用最多一倍的內(nèi)存空間。

我們?cè)赗edis執(zhí)行info命令,可以看到fork子進(jìn)程的耗時(shí),可以通過這個(gè)耗時(shí)來評(píng)估fork時(shí)間是否符合預(yù)期。同時(shí)我們應(yīng)該保證Redis機(jī)器擁有足夠的CPU和內(nèi)存資源,并合理設(shè)置生成RDB的時(shí)機(jī)。

AOF

介紹

AOF全稱為Append Only File(追加日志文件)。它與RDB不同的是,AOF中記錄的是每一個(gè)命令的詳細(xì)信息,包括完整的命令類型、參數(shù)等。只要產(chǎn)生寫命令,就會(huì)實(shí)時(shí)寫入到AOF文件中。

我們可以通過配置文件開啟AOF:

刷盤方式

開啟AOF后,Redis會(huì)把每個(gè)寫操作的命令記錄到文件并持久化到磁盤中,為了保證數(shù)據(jù)文件的安全性,Redis還提供了文件刷盤的時(shí)機(jī):

  •  appendfsync always:每次寫入都刷盤,對(duì)性能影響最大,占用磁盤IO比較高,數(shù)據(jù)安全性最高
  •  appendfsync everysec:1秒刷一次盤,對(duì)性能影響相對(duì)較小,節(jié)點(diǎn)宕機(jī)時(shí)最多丟失1秒的數(shù)據(jù)
  •  appendfsync no:按照操作系統(tǒng)的機(jī)制刷盤,對(duì)性能影響最小,數(shù)據(jù)安全性低,節(jié)點(diǎn)宕機(jī)丟失數(shù)據(jù)取決于操作系統(tǒng)刷盤機(jī)制

以上可以看出AOF相對(duì)于RDB的優(yōu)點(diǎn)是,AOF數(shù)據(jù)文件更新比較及時(shí),比RDB保存更完整的數(shù)據(jù),這樣在數(shù)據(jù)恢復(fù)時(shí)能夠恢復(fù)盡量完整的數(shù)據(jù),降低丟失數(shù)據(jù)的風(fēng)險(xiǎn)。

如果同時(shí)存在RDB文件和AOF文件,Redis會(huì)優(yōu)先使用AOF文件進(jìn)行數(shù)據(jù)恢復(fù)。

但它的缺點(diǎn)也很易見:

  •  隨著時(shí)間增長(zhǎng),AOF文件會(huì)越來越大
  •  AOF文件刷盤會(huì)增加磁盤IO的負(fù)擔(dān),可能影響Redis的性能(開啟每秒刷盤時(shí))

AOF重寫

針對(duì)第一種情況,Redis提供了AOF瘦身的功能,可以設(shè)置在AOF文件很大時(shí),自動(dòng)觸發(fā)AOF重寫,Redis會(huì)掃描整個(gè)實(shí)例的數(shù)據(jù),重新生成一個(gè)AOF文件達(dá)成瘦身的效果。但這個(gè)重寫過程也需要消耗大量的CPU資源。

由于AOF可以最大可能降低丟失數(shù)據(jù)的風(fēng)險(xiǎn),所以它一般適用于對(duì)丟失數(shù)據(jù)很敏感的業(yè)務(wù)場(chǎng)景,例如涉及金錢交易的業(yè)務(wù)。

性能影響

如果AOF的刷盤時(shí)機(jī)設(shè)置為每次寫入都刷盤,那么會(huì)大大降低Redis的寫入性能,因?yàn)槊看螌懨疃夹枰獙懭胛募⑺⒌酱疟P中才會(huì)返回,當(dāng)寫入量很大時(shí),會(huì)增加磁盤IO的負(fù)擔(dān)。

性能與數(shù)據(jù)安全不能兼得,雖然Redis提供了實(shí)時(shí)刷盤的機(jī)制,但是在真正場(chǎng)景中使用的不多。

通常我們會(huì)選擇每秒刷盤這種方式,既能保證良好的寫入性能,在實(shí)例宕機(jī)時(shí)最多丟失1秒的數(shù)據(jù),做到性能和安全的平衡。

總結(jié)

我們對(duì)RDB和AOF的總結(jié)如下表。

我們需要針對(duì)不同的業(yè)務(wù)場(chǎng)景選擇合適的持久化方式,也可以根據(jù)RDB和AOF的優(yōu)點(diǎn)配合使用,保證Redis數(shù)據(jù)的安全性,又可以兼顧它的性能。 

 

責(zé)任編輯:龐桂玉 來源: ITPUB
相關(guān)推薦

2020-03-10 10:37:48

數(shù)據(jù)丟失數(shù)據(jù)泄露網(wǎng)絡(luò)安全

2010-12-21 15:56:43

桌面文件權(quán)限管理防止數(shù)據(jù)丟失

2009-08-26 10:41:21

防止數(shù)據(jù)丟失

2023-04-26 08:18:48

FormPrompt表單更改

2009-03-24 14:29:04

LinuxExt4數(shù)據(jù)丟失

2009-03-25 08:32:33

Windows Ser微軟操作系統(tǒng)

2023-10-23 11:22:06

Redis數(shù)據(jù)持久化

2024-02-26 08:10:00

Redis數(shù)據(jù)數(shù)據(jù)庫(kù)

2024-11-11 07:05:00

Redis哨兵模式主從復(fù)制

2013-01-14 13:39:22

Windows 8Linux

2014-03-27 14:44:58

數(shù)據(jù)丟失防護(hù)DLP數(shù)據(jù)保護(hù)

2014-04-01 11:13:32

數(shù)據(jù)丟失

2023-07-11 15:02:34

數(shù)據(jù)丟失人工智能

2024-02-23 14:53:10

Redis持久化

2021-09-10 18:47:22

Redis淘汰策略

2015-06-15 15:35:54

服務(wù)器宕機(jī)MySQL數(shù)據(jù)丟失

2010-05-18 21:27:19

全盤加密DLP技術(shù)數(shù)據(jù)丟失

2019-08-04 21:15:42

2020-12-31 07:34:04

Redis數(shù)據(jù)宕機(jī)

2022-07-06 08:01:05

數(shù)據(jù)庫(kù)分布式
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)