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

面試常問(wèn),工作常用的Redis持久化機(jī)制

開(kāi)發(fā) 前端 Redis
redis是一個(gè)內(nèi)存數(shù)據(jù)庫(kù),數(shù)據(jù)保存在內(nèi)存中,但是我們都知道內(nèi)存的數(shù)據(jù)變化是很快的,也容易發(fā)生丟失。幸好Redis還為我們提供了持久化的機(jī)制,分別是RDB(Redis DataBase)和AOF(Append Only File)。

[[387814]]

redis是一個(gè)內(nèi)存數(shù)據(jù)庫(kù),數(shù)據(jù)保存在內(nèi)存中,但是我們都知道內(nèi)存的數(shù)據(jù)變化是很快的,也容易發(fā)生丟失。幸好Redis還為我們提供了持久化的機(jī)制,分別是RDB(Redis DataBase)和AOF(Append Only File)。

在這里假設(shè)你已經(jīng)了解了redis的基礎(chǔ)語(yǔ)法,某字母網(wǎng)站都有很好的教程,可以去看?;臼褂玫奈恼戮筒粚?xiě)了,都是一些常用的命令。

下面針對(duì)這兩種方式來(lái)介紹一下。由淺入深。

一、持久化流程

既然redis的數(shù)據(jù)可以保存在磁盤上,那么這個(gè)流程是什么樣的呢?

要有下面五個(gè)過(guò)程:

(1)客戶端向服務(wù)端發(fā)送寫(xiě)操作(數(shù)據(jù)在客戶端的內(nèi)存中)。

(2)數(shù)據(jù)庫(kù)服務(wù)端接收到寫(xiě)請(qǐng)求的數(shù)據(jù)(數(shù)據(jù)在服務(wù)端的內(nèi)存中)。

(3)服務(wù)端調(diào)用write這個(gè)系統(tǒng)調(diào)用,將數(shù)據(jù)往磁盤上寫(xiě)(數(shù)據(jù)在系統(tǒng)內(nèi)存的緩沖區(qū)中)。

(4)操作系統(tǒng)將緩沖區(qū)中的數(shù)據(jù)轉(zhuǎn)移到磁盤控制器上(數(shù)據(jù)在磁盤緩存中)。

(5)磁盤控制器將數(shù)據(jù)寫(xiě)到磁盤的物理介質(zhì)中(數(shù)據(jù)真正落到磁盤上)。

這5個(gè)過(guò)程是在理想條件下一個(gè)正常的保存流程,但是在大多數(shù)情況下,我們的機(jī)器等等都會(huì)有各種各樣的故障,這里劃分了兩種情況:

(1)Redis數(shù)據(jù)庫(kù)發(fā)生故障,只要在上面的第三步執(zhí)行完畢,那么就可以持久化保存,剩下的兩步由操作系統(tǒng)替我們完成。

(2)操作系統(tǒng)發(fā)生故障,必須上面5步都完成才可以。

在這里只考慮了保存的過(guò)程可能發(fā)生的故障,其實(shí)保存的數(shù)據(jù)也有可能發(fā)生損壞,需要一定的恢復(fù)機(jī)制,不過(guò)在這里就不再延伸了?,F(xiàn)在主要考慮的是redis如何來(lái)實(shí)現(xiàn)上面5個(gè)保存磁盤的步驟。它提供了兩種策略機(jī)制,也就是RDB和AOF。

二、RDB機(jī)制

RDB其實(shí)就是把數(shù)據(jù)以快照的形式保存在磁盤上。什么是快照呢,你可以理解成把當(dāng)前時(shí)刻的數(shù)據(jù)拍成一張照片保存下來(lái)。

RDB持久化是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤。也是默認(rèn)的持久化方式,這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫(xiě)入到二進(jìn)制文件中,默認(rèn)的文件名為dump.rdb。

在我們安裝了redis之后,所有的配置都是在redis.conf文件中,里面保存了RDB和AOF兩種持久化機(jī)制的各種配置。

既然RDB機(jī)制是通過(guò)把某個(gè)時(shí)刻的所有數(shù)據(jù)生成一個(gè)快照來(lái)保存,那么就應(yīng)該有一種觸發(fā)機(jī)制,是實(shí)現(xiàn)這個(gè)過(guò)程。對(duì)于RDB來(lái)說(shuō),提供了三種機(jī)制:save、bgsave、自動(dòng)化。我們分別來(lái)看一下

1、save觸發(fā)方式

該命令會(huì)阻塞當(dāng)前Redis服務(wù)器,執(zhí)行save命令期間,Redis不能處理其他命令,直到RDB過(guò)程完成為止。具體流程如下:

執(zhí)行完成時(shí)候如果存在老的RDB文件,就把新的替代掉舊的。我們的客戶端可能都是幾萬(wàn)或者是幾十萬(wàn),這種方式顯然不可取。

2、bgsave觸發(fā)方式

執(zhí)行該命令時(shí),Redis會(huì)在后臺(tái)異步進(jìn)行快照操作,快照同時(shí)還可以響應(yīng)客戶端請(qǐng)求。具體流程如下:

具體操作是Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程,RDB持久化過(guò)程由子進(jìn)程負(fù)責(zé),完成后自動(dòng)結(jié)束。阻塞只發(fā)生在fork階段,一般時(shí)間很短?;旧? Redis 內(nèi)部所有的RDB操作都是采用 bgsave 命令。

3、自動(dòng)觸發(fā)

自動(dòng)觸發(fā)是由我們的配置文件來(lái)完成的。在redis.conf配置文件中,里面有如下配置,我們可以去設(shè)置:

①save:這里是用來(lái)配置觸發(fā) Redis的 RDB 持久化條件,也就是什么時(shí)候?qū)?nèi)存中的數(shù)據(jù)保存到硬盤。比如“save m n”。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時(shí),自動(dòng)觸發(fā)bgsave。

默認(rèn)如下配置:

  1. #表示900 秒內(nèi)如果至少有 1 個(gè) key 的值變化,則保存 
  2. save 900 1 
  3. #表示300 秒內(nèi)如果至少有 10 個(gè) key 的值變化,則保存 
  4. save 300 10 
  5. 表示60 秒內(nèi)如果至少有 10000 個(gè) key 的值變化,則保存 
  6. save 60 10000 

不需要持久化,那么你可以注釋掉所有的 save 行來(lái)停用保存功能。

②stop-writes-on-bgsave-error :默認(rèn)值為yes。當(dāng)啟用了RDB且最后一次后臺(tái)保存數(shù)據(jù)失敗,Redis是否停止接收數(shù)據(jù)。這會(huì)讓用戶意識(shí)到數(shù)據(jù)沒(méi)有正確持久化到磁盤上,否則沒(méi)有人會(huì)注意到災(zāi)難(disaster)發(fā)生了。如果Redis重啟了,那么又可以重新開(kāi)始接收數(shù)據(jù)了

③rdbcompression ;默認(rèn)值是yes。對(duì)于存儲(chǔ)到磁盤中的快照,可以設(shè)置是否進(jìn)行壓縮存儲(chǔ)。

④rdbchecksum :默認(rèn)值是yes。在存儲(chǔ)快照后,我們還可以讓redis使用CRC64算法來(lái)進(jìn)行數(shù)據(jù)校驗(yàn),但是這樣做會(huì)增加大約10%的性能消耗,如果希望獲取到最大的性能提升,可以關(guān)閉此功能。

⑤dbfilename :設(shè)置快照的文件名,默認(rèn)是 dump.rdb

⑥dir:設(shè)置快照文件的存放路徑,這個(gè)配置項(xiàng)一定是個(gè)目錄,而不能是文件名。

我們可以修改這些配置來(lái)實(shí)現(xiàn)我們想要的效果。因?yàn)榈谌N方式是配置的,所以我們對(duì)前兩種進(jìn)行一個(gè)對(duì)比:

4、RDB 的優(yōu)勢(shì)和劣勢(shì)

①、優(yōu)勢(shì)

(1)RDB文件緊湊,全量備份,非常適合用于進(jìn)行備份和災(zāi)難恢復(fù)。

(2)生成RDB文件的時(shí)候,redis主進(jìn)程會(huì)fork()一個(gè)子進(jìn)程來(lái)處理所有保存工作,主進(jìn)程不需要進(jìn)行任何磁盤IO操作。

(3)RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快。

②、劣勢(shì)

RDB快照是一次全量備份,存儲(chǔ)的是內(nèi)存數(shù)據(jù)的二進(jìn)制序列化形式,存儲(chǔ)上非常緊湊。當(dāng)進(jìn)行快照持久化時(shí),會(huì)開(kāi)啟一個(gè)子進(jìn)程專門負(fù)責(zé)快照持久化,子進(jìn)程會(huì)擁有父進(jìn)程的內(nèi)存數(shù)據(jù),父進(jìn)程修改內(nèi)存子進(jìn)程不會(huì)反應(yīng)出來(lái),所以在快照持久化期間修改的數(shù)據(jù)不會(huì)被保存,可能丟失數(shù)據(jù)。

三、AOF機(jī)制

全量備份總是耗時(shí)的,有時(shí)候我們提供一種更加高效的方式AOF,工作機(jī)制很簡(jiǎn)單,redis會(huì)將每一個(gè)收到的寫(xiě)命令都通過(guò)write函數(shù)追加到文件中。通俗的理解就是日志記錄。

1、持久化原理

他的原理看下面這張圖:

每當(dāng)有一個(gè)寫(xiě)命令過(guò)來(lái)時(shí),就直接保存在我們的AOF文件中。

2、文件重寫(xiě)原理

AOF的方式也同時(shí)帶來(lái)了另一個(gè)問(wèn)題。持久化文件會(huì)變的越來(lái)越大。為了壓縮aof的持久化文件。redis提供了bgrewriteaof命令。將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時(shí)文件中,同時(shí)會(huì)fork出一條新進(jìn)程來(lái)將文件重寫(xiě)。

重寫(xiě)aof文件的操作,并沒(méi)有讀取舊的aof文件,而是將整個(gè)內(nèi)存中的數(shù)據(jù)庫(kù)內(nèi)容用命令的方式重寫(xiě)了一個(gè)新的aof文件,這點(diǎn)和快照有點(diǎn)類似。

3、AOF也有三種觸發(fā)機(jī)制

(1)每修改同步always:同步持久化 每次發(fā)生數(shù)據(jù)變更會(huì)被立即記錄到磁盤 性能較差但數(shù)據(jù)完整性比較好

(2)每秒同步everysec:異步操作,每秒記錄 如果一秒內(nèi)宕機(jī),有數(shù)據(jù)丟失

(3)不同no:從不同步

4、優(yōu)點(diǎn)

(1)AOF可以更好的保護(hù)數(shù)據(jù)不丟失,一般AOF會(huì)每隔1秒,通過(guò)一個(gè)后臺(tái)線程執(zhí)行一次fsync操作,最多丟失1秒鐘的數(shù)據(jù)。

(2)AOF日志文件沒(méi)有任何磁盤尋址的開(kāi)銷,寫(xiě)入性能非常高,文件不容易破損。

(3)AOF日志文件即使過(guò)大的時(shí)候,出現(xiàn)后臺(tái)重寫(xiě)操作,也不會(huì)影響客戶端的讀寫(xiě)。

(4)AOF日志文件的命令通過(guò)非??勺x的方式進(jìn)行記錄,這個(gè)特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。比如某人不小心用flushall命令清空了所有數(shù)據(jù),只要這個(gè)時(shí)候后臺(tái)rewrite還沒(méi)有發(fā)生,那么就可以立即拷貝AOF文件,將最后一條flushall命令給刪了,然后再將該AOF文件放回去,就可以通過(guò)恢復(fù)機(jī)制,自動(dòng)恢復(fù)所有數(shù)據(jù)

5、缺點(diǎn)

(1)對(duì)于同一份數(shù)據(jù)來(lái)說(shuō),AOF日志文件通常比RDB數(shù)據(jù)快照文件更大

(2)AOF開(kāi)啟后,支持的寫(xiě)QPS會(huì)比RDB支持的寫(xiě)QPS低,因?yàn)锳OF一般會(huì)配置成每秒fsync一次日志文件,當(dāng)然,每秒一次fsync,性能也還是很高的

(3)以前AOF發(fā)生過(guò)bug,就是通過(guò)AOF記錄的日志,進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候,沒(méi)有恢復(fù)一模一樣的數(shù)據(jù)出來(lái)。

四、RDB和AOF到底該如何選擇

選擇的話,兩者加一起才更好。因?yàn)閮蓚€(gè)持久化機(jī)制你明白了,剩下的就是看自己的需求了,需求不同選擇的也不一定,但是通常都是結(jié)合使用。有一張圖可供總結(jié):

對(duì)比了這幾個(gè)特性,剩下的就是看自己了。

本文轉(zhuǎn)載自微信公眾號(hào)「愚公要移山」,可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系愚公要移山公眾號(hào)。

 

責(zé)任編輯:武曉燕 來(lái)源: 愚公要移山
相關(guān)推薦

2018-03-08 19:30:04

Python面試題

2019-05-17 08:55:49

RedisRDBAOF

2024-09-12 08:49:53

2020-03-16 17:40:32

面試Linux命令

2024-09-06 17:49:46

2019-11-12 14:15:07

Redis內(nèi)存持久化

2020-12-29 10:06:35

Redis

2022-08-17 08:17:01

SPI機(jī)制接口

2021-02-03 15:30:10

面試垃圾回收器前端

2020-09-24 10:30:29

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

2024-12-20 12:15:06

RedisRDB持久化

2020-01-06 14:54:31

RDBAOFRedis

2023-09-12 10:49:44

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

2024-01-22 10:07:48

Redis持久化功能緩存擊穿

2023-10-12 13:01:29

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

2020-03-03 14:15:49

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

2022-03-21 14:09:19

面試C語(yǔ)言代碼

2024-03-26 00:03:08

Redis數(shù)據(jù)RDB

2020-02-18 16:14:33

RedisRDBAOF

2021-10-04 21:11:18

Redis混合持久化
點(diǎn)贊
收藏

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